[Home]

Summary:ASTERISK-04887: [patch] implement call pickup on Snom phones
Reporter:Frank Sautter (xylome)Labels:
Date Opened:2005-08-24 05:37:40Date Closed:2008-11-03 06:41:19.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) backtrace.txt
( 1) crash-1
( 2) deadlock-festr-2
( 3) draft-anil-sipping-bla-02.txt
( 4) experimental-20050927.patch.txt
( 5) experimental-20051012.patch.txt
( 6) experimental-pickup-20051014.patch.txt
( 7) experimental-pickup-20051117-1_2.patch.txt
( 8) issue5014-1.4.diff
( 9) issue5014-trunk.diff
(10) pf_intercept_monitored.patch
(11) pickup-locks-2005-10-01.patch.txt
(12) pickup-locks-2005-10-02.patch.txt
(13) pickup-locks-2005-10-11.patch.txt
(14) pickup-mgernoth-2006-07-28.patch.txt
(15) pickup-mgernoth-2006-10-03.patch
(16) pkempgen-pickup-60212.patch
(17) simple-pickup-2007-03-31.patch
(18) sip.snom
(19) sip.snom.pu
(20) siptrace-notify.txt
(21) snom-trunk-20060128.gz
Description:this is more or less my current SIP playground, that i want to share with others.
maybe some of these ideas could be the starting point for properly implemented features within asterisk. please feel free to use this for inspiration.
some of the features are highly experimental. so be warned!
Comments:By: Frank Sautter (xylome) 2005-08-24 05:46:50

current features are:
* call pickup hitting the blinking buttons on snom phones
* very experimental record button
* some other small changes

By: Paul Hales (paulh) 2005-08-31 23:38:53

Any changes to make the snom lights work better would be more than welcome!

They currently work resonably well...but working perfectly...

By: xrobau (xrobau) 2005-09-17 22:05:26

Now that app_directed_pickup has been committed to CVS, perhaps this could be reworked to take advantage of that?  It would save re-inventing the wheel as has been done here with pickups?

By: xrobau (xrobau) 2005-09-21 07:43:59

'draft-anil-sipping' is the RFC apparently Snom used for their BLF's (They refer to them, possibly more accurately, as BLA's), and is definately the one Grandstream is using for NOTIFY etc. I haven't found this anywhere else, so I thought it might be useful attaching it to this bug.

By: Olle Johansson (oej) 2005-09-21 08:18:39

We need to rework the subscribe system as well as finding a way to check call status to support this properly. Spent a lot of time at SIPit testing and trying to understand what is needed to do this properly. We might have to divide it into two steps, first supporting the SNOM phone pickup, then doing it properly...

By: Serge Vecher (serge-v) 2005-09-26 11:21:27

xylome, your latest patch includes some changes to terms.c and Makefile. Do these changes belong in this patch?

By: Frank Sautter (xylome) 2005-09-26 11:27:44

vechers: this is the version we are running here and i wanted share the one-touch-blinking-button-pickup-functionality with the community. therefore i submitted a diff between our source and cvs today...
the answer is: no, term.c and Makefile do not have to be changed (this is only for coloring the remote console and for compiling spandsp)

By: Michael Gernoth (mgernoth) 2005-10-01 07:18:16

We had some problems with this patch. Sometimes a pickup would not work and leave a locked channel behind. This resulted in no more calls being successfull and we needed to kill -9 asterisk to get it working again (stop now did not stop). show channels in this situation resulted in:
asterix*CLI> show channels
Channel              Location             State   Application(Data)
0 active channels
1 active call
Oct  1 02:16:54 WARNING[3546]: channel.c:741 channel_find_locked: Avoided initial deadlock for '0x81d9f38', 10 retries!

With the patch I've just uploaded (pickup-locks-2005-10-01.patch.txt) I was not able to reproduce the hang with about 50 test-calls. (Previously I could reproduce the problem with just 5-10 test-calls).

By: Michael Gernoth (mgernoth) 2005-10-01 09:48:38

Another problem: When two phones try to pickup the same call at exactly the same time I get a segfault in asterisk:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1213953104 (LWP 20209)]
0xb7a7528a in handle_request_invite (p=0x81f4448, req=0xb7a477b0, debug=0, ignore=0, seqno=2, sin=0x81e9538, recount=0x81e9538, e=0x81e9538 "\001") at chan_sip.c:10357
10357                                                   if (refer_pvt->owner->_state == AST_STATE_RINGING) {
(gdb) bt
#0  0xb7a7528a in handle_request_invite (p=0x81f4448, req=0xb7a477b0, debug=0, ignore=0, seqno=2, sin=0x81e9538, recount=0x81e9538, e=0x81e9538 "\001") at chan_sip.c:10357
#1  0xb7a6edaa in handle_request (p=0x81f4448, req=0xb7a477b0, sin=0xb7a477a0, recount=0x81e9538, nounlock=0x81e9538) at chan_sip.c:10932
#2  0xb7a6ca10 in sipsock_read (id=0x8191850, fd=15, events=1, ignore=0x0) at chan_sip.c:11068
#3  0x0805514d in ast_io_wait (ioc=0x814b290, howlong=136222008) at io.c:284
#4  0xb7a63011 in do_monitor (data=0x0) at chan_sip.c:11213
ASTERISK-1  0xb7f15b63 in start_thread () from /lib/tls/libpthread.so.0
ASTERISK-2  0xb7e1018a in clone () from /lib/tls/libc.so.6

By: Michael Gernoth (mgernoth) 2005-10-01 17:30:37

The pickup-locks-2005-10-02.patch.txt fixes this segfault and now prints the following warning to the console when two phones try the pickup:
Oct  2 00:27:44 WARNING[11216]: chan_sip.c:10377 handle_request_invite: SIP Call Replacement (pickup) not possible. Call already answered

So it's working as expected now :-)

By: Michael Gernoth (mgernoth) 2005-10-07 04:53:20

If I see this correctly, there still is something wrong with this code.
Souldn't there be an ast_hangup(c) in front of the line:
transmit_response_with_allow(p, "481 Call/Transaction Does Not Exist", req, 0);
I at least have some hanging SIP-channels in down state and just now inserted the ast_hangup in our production-system, so I can tell next week if it's working as expected.

By: Michael Gernoth (mgernoth) 2005-10-11 12:21:27

The ast_hangup seems to have cured the last issues for us. I've uploaded pickup-locks-2005-10-11.patch.txt incorporating this change. Disclaimer is on file with digium, so it's safe for xylome to include my bits, if he wants.

By: Frank Sautter (xylome) 2005-10-12 04:10:34

mgernoth: many thanks for all your debugging work on this!
i just uploaded an updated patch with mgernoth patches incorporated.

By: Michael Gernoth (mgernoth) 2005-10-12 08:40:17

Xylome, thanks for picking up my changes. :-)
After looking at your new patch, it seems there is an ast_mutex_unlock(&refer_pvt->owner->lock); to much in it. The one directly under transmit_response(p, "100 Trying", req); should be removed.

By: xrobau (xrobau) 2005-10-12 15:02:21

Xylome, the OpenPBX.org guys are thinking about merging this into their current build - you want to wander into #openpbx some time?

By: Frank Sautter (xylome) 2005-10-14 03:49:18

updated this to reflect all the recent changes in chan_sip.c
in revision 890 of chan_sip.c 'gettag' has been added. maybe this could replace the 'sip_extract_tag' function in this patch... maybe someone can take a look at this because i can't spend very much time on asterisk the next few weeks.



By: Stefan Kleck (stefkle) 2005-10-31 02:31:24.000-0600

Hello !

My Asterisk crashes about all 2 or 3 days now. Mostly in the night when nobody makes calls. Any idea ?

Oct 31 03:37:32 WARNING[26436]: chan_sip.c:2158 __sip_destroy: Trying to destroy "02f876f45129721d@192.168.80.132", not found in dialog list?!?!
Oct 31 03:37:32 WARNING[26436]: chan_sip.c:2158 __sip_destroy: Trying to destroy "3c26700c668a-2d72p7pt8n9u@snom360", not found in dialog list?!?!
Ouch ... error while writing audio data: : Broken pipe
Warning, flexibel rate not heavily tested!
Ouch ... error while writing audio data: : Broken pipe
Speicherzugriffsfehler

By: ulexus (ulexus) 2005-11-11 00:07:24.000-0600

Just a note:  This patch no longer applies cleanly to the latest CVS or 1.2rc1.

By: Frank Sautter (xylome) 2005-11-17 06:28:06.000-0600

updated this patch so it applies to asterisk v1.2

By: xrobau (xrobau) 2005-11-27 22:52:07.000-0600

I s'pose the next question is, where does this patch go from here? Whilst the 'record' button functionality is, obviously, snom-centric and totally non-configurable, the call pickup works well, and is standardised in the anil-sipping-bla RFC above - IMHO, that should move into 1.2!

By: Olle Johansson (oej) 2005-11-28 03:04:02.000-0600

No new features make it into 1.2. All new features go into development tree to be tested before release.

I'll look into this new version. We need to rewrite the subscription code within Asterisk to scale better, which also may affect this code.

By: Olle Johansson (oej) 2005-11-28 03:15:41.000-0600

Doing the channel walk for every notification does not scale, we need to find another way of handling this.

By: xrobau (xrobau) 2005-12-13 14:23:17.000-0600

I've uploaded crash-1, which looks to be a problem in the replace code, but it's a bit out of my league. It's crashing randomly - I've had one day with 6 crashes, but other days with one or none.

By: jalsot (jalsot) 2005-12-15 08:24:46.000-0600

I tryed the given patch with Grandstream GXP2000 (1.0.1.13).
It seems to be working for it as well :) So not just the SNOM phone.

Note: I had to add a line into extension:
; call pick up used
exten => _**XXX,1,Pickup(${EXTEN:2})

So when I push the blinking button, it dials the **<myextension with 3 digits> which picks up the phone.

Great work! Thanks!

By: Ulrich Peinhardt (upsite) 2005-12-22 13:28:08.000-0600

this patch breaks the indication of the ringing state of chan_sccp2 channels. the led is not blinkig its just lit like busy.

By: mike240se (mike240se) 2006-01-04 01:59:41.000-0600

This looks great, i havent patched yet, but am doing a snom360 install and would love to get this feature going.  We need to be able to easily do call pickup of calls on hold, etc...  What is the status of this patch?  I am running 1.2.1 release...  this patch will let me pickup calls on hold right?  Does it currently enable any other snom features?  the snom 4S does so much with the phones it would  be awesome if asterisk did them as well...  thanks for the good work...

By: E. Versaevel (erikje) 2006-01-25 05:30:17.000-0600

This patch won't apply to the bristuffed asterisk as bristuff is patching chan_sip aswell (and is allso modifying the record button for the snom phone's :))

By: xrobau (xrobau) 2006-01-27 19:32:28.000-0600

Just uploaded snom-trunk-20060128.gz which applies cleanly to trunk rev 8804. No differences at all, just fuzz fixes.

By: E. Versaevel (erikje) 2006-02-03 08:09:33.000-0600

Could someone find the time to modify this patch to apply to version 1.2.4 ? I'm not a C guru so I can't fix it

By: xrobau (xrobau) 2006-02-07 22:32:12.000-0600

erikje - it does apply to 1.2. That's what the '20051117-1_2.patch' is.
However, onto my crash of the other day, I think I've possibly found what's crashing asterisk. At line 6823 of chan_sip, there's a 'sip_call', and the return value of that isn't checked. That would explain how ast_channel_masquerade is all nulls, causing the segv. If someone could clue me up about how to exit from that gracefully, I'd be most appreciative!

By: Dr. W.A. Slaby (was) 2006-02-21 01:14:53.000-0600

We applied patch experimental-pickup-20051117-1_2.patch.txt to asterisk 1.2.4.
Pickup of extensions is working well. But we get the following error message:
ERROR[16922]: chan_sip.c:10994 handle_request_subscribe: Got SUBSCRIBE for extensions without hint. Please add hint to _xxxx_ in context _yyyyyyyy_

Of course, I have defined some functions keys on my Snom360 with destinations
that should not subscribe in order to be picked up in case of ringing.
Therefore, it is our intention  n o t  to add hint to these extensions.

What can be done in order to avoid this error?
Thank you very much in advance for your efforts.

By: E. Versaevel (erikje) 2006-02-21 01:26:03.000-0600

I'm using this patch in a production office envirionment, seems to work OK for me, had to remove a section of the bristuff patches as they both tried to patch the same

By: philipp2 (philipp2) 2006-02-21 12:00:09.000-0600

Also applied experimental-pickup-20051117-1_2.patch.txt on two 1.2.4 boxes, didn't work as expected on either of them, so I cannot recommend this for 1.2.4.

Problem 1 was that the SNOM 360 thought it had the line, while the other side kept ringing, and the SNOM heard nothing. Problem 2 occured once in this short test with a locked Asterisk, not 100% this was related to the patch (but most probably so). - So better test this with trunk (or maybe 1.2.0).

By: Dr. W.A. Slaby (was) 2006-02-23 04:56:07.000-0600

Note on oej's note 08-29-05 (0032437) to patch 3644:
Refusing the subscription if there's no hint is OK. But imagine you have a lot
of Snom360 phones each defining its 11 (or more) free programmable function keys
with destinations, only very few of which are intended to be subscribed.
You then get a lot of error messages like this:
ERROR[24262]: chan_sip.c:10994 handle_request_subscribe: Got SUBSCRIBE for extensions without hint. Please add hint to 1111 in context international

Perhaps subscriptions without a hint can be refused  _without_  an error message.

By: E. Versaevel (erikje) 2006-02-28 03:52:41.000-0600

My asterisk keeps on crashing at random, mostly when we try to transfer people.

By: Olle Johansson (oej) 2006-02-28 05:35:07.000-0600

If you don't want the phone to subscribe, set the subscribecontext to an empty context.

By: Michael Gernoth (mgernoth) 2006-02-28 05:47:06.000-0600

erikje: I've just uploaded pickup-mgernoth-2006-02-28.patch.txt which is a subset of xylomes Patch and only supports call-pickup. The record-button and transfer between servers has been removed, as they were crashing my asterisk very often. I'm running this in production since 3 months and had no crash since then. It also uses gettag instead of its own sip_extract_tag as xylome recommended in message 0034857.

By: E. Versaevel (erikje) 2006-02-28 06:07:55.000-0600

'k i'll try that patch.

By: Dr. W.A. Slaby (was) 2006-03-02 13:42:51.000-0600

[oej (0041771)]:
Specifying an empty subscribecontext is OK if the phone should not at all subscribe to _any_ context. But normally, a phone has some function keys with destinations that should be subscribed and it has other function keys with destinations for which a subscription does not make any sense.

By: Olle Johansson (oej) 2006-03-02 14:00:01.000-0600

Then place only the extensions you want to subscribe to in the subscribecontext and omit the rest

By: Dr. W.A. Slaby (was) 2006-03-03 06:25:33.000-0600

oej, thank you very much for your hints. Now, subscriptions are working perfectly.

By: Alessio Focardi (alessiof) 2006-03-07 05:59:29.000-0600

Hi,

I'm testing the patch in production envirorment, more or less 30 snom 320 and also a Snom 360 with optional DSS: more leds than a christmas tree here!

Asterisk version is 1.2.5

Regarding subscriptions: why a "reload" command clean the whole subscription table ?

I do have to manually reset phones after a config change to have them resubscribe extensions.

This is not the standard behaviour of Asterisk, at least for what I can remember from version 1.2.4 unpatched.

Tnx for the good work!

By: Olle Johansson (oej) 2006-03-07 07:28:37.000-0600

There is another open bug on the reload. Previous to 1.2, subscriptions was still around at reload, but would not get *any* notifications after a reload. The fix was rather complicated, but in most cases mean that if you change the dialplan, asterisk will tell the phone that the subscription was cancelled before actually reloading, so the phone is supposed to re-subscribe automatically. Seems like most phones are not compliant with the standard and wait until *they* think the subscription expires and re-subscribe.

By: Alessio Focardi (alessiof) 2006-03-07 07:43:57.000-0600

Tnx, hope that snom will solve the issue very soon: you can cook an egg and also make coffe with * but for the normal "office user" leds and call pickup are the most important issue by far!

By the way I'm banging my head on another problem, maybe related to this patch, maybe not: in case I beg pardon for posting here.

Here is what is happening:

When a monitored extension is released from a call the subscribing phone shows a message on the display, something like "33512323456 to 200", that's even too much and raises BIG privacy concerns!

I'm using * 1.2.5 with this patch, snom phones are 320's with 5.3 firmware.

Shall I post a sip trace ?

Tnx for any help!

By: Alessio Focardi (alessiof) 2006-03-07 08:56:10.000-0600

Forgive the previous message, I have solved: it was "callpickup_dialoginfo&: off"
setting to enforce in provisioning!

By: mike240se (mike240se) 2006-03-07 14:56:57.000-0600

Oej, I would really like to see this move forward, have you considered adding this to the "test-this" branch?  Also, alesiof, what version of the snom firmware are you running? I am running beta 5.3.6 and subscriptions work very well.  

I am surprised your getting the call pickup dialog, i enabled that on my snom and didnt get anything, did that happen before the patch or only after this patch?

By: Olle Johansson (oej) 2006-03-07 15:05:36.000-0600

As I have stated many times, this patch will *not* make it into svn trunk or test-this-branch. We need to redesign the code quite a lot first. I have a few ideas, but no free time for it right now.

I fully agree that we need the functionality in Asterisk though.

By: Alessio Focardi (alessiof) 2006-03-07 15:59:47.000-0600

mike240se,

this is a snippet a of sip message sent by * that was triggering the dialog (prior of changing phone configuration), Snom firmware is 5.3.

I left the option on for the operator, and it looks very cool: on phone display we have notifications of calls for every subscribed extension.

P.S.

What about monitoring a global var with a led ? Has this been proposed/coded yet ?

Again, tnx for the support!


Received from udp:192.168.100.100:5060 at 7/3/2006 15:06:42:130 (1038 bytes):

NOTIFY sip:117@192.168.100.100 SIP/2.0
Via: SIP/2.0/UDP 192.168.100.100:5060;branch=z9hG4bK2516ef1e;rport
From: <sip:100@192.168.100.100>;tag=as2a32ad46
To: <sip:117@192.168.100.100>;tag=kvw77be3cy
Contact: <sip:100@192.168.100.100>
Call-ID: 3c267009b4aa-urh78a51clyt@snom320-0004132431FC
CSeq: 134 NOTIFY
User-Agent: Asterisk PBX
Max-Forwards: 70
Event: dialog
Content-Type: application/dialog-info+xml
Subscription-State: active
Content-Length: 572

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="32" state="full" entity="sip:100@192.168.100.100">
<dialog id="100" direction="recipient" call-id="080c36372fae9da07620b53e192443de@192.168.100.100" local-tag="as09a3e880" remote-tag="pesn6iax3e">
<state>early</state>
<local><identity display="100">sip:117@192.168.100.100</identity><target uri="sip:117@192.168.100.100"/></local>
<remote><identity display="Stefania Fancelli">sip:100@192.168.100.100</identity><target uri="sip:100@192.168.100.100"/></remote>
</dialog>
</dialog-info>

By: mike240se (mike240se) 2006-03-07 17:48:30.000-0600

Oej, sorry, i havent re-read the whole bug's notes in a while, just reading the most current....

alessiof, did this happen before applying this patch?  If so, do you use bristuff?  Or did this start after you applied this patch?

PS. Oej, has the parkhints bug made it into test-this branch yet?

By: Olle Johansson (oej) 2006-04-06 09:40:45

Working on another architecture for this in a branch.

By: Dr. W.A. Slaby (was) 2006-04-07 01:43:49

There seems to exist a new patch
http://bugs.digium.com/file_download.php?file_id=9459&type=bug
that should address the pickup problem. I would be very pleased if anybody could tell me how this patch is related to the staff discussed here, and whether there is a documentation of the details of this new patch.

By: Denis Smirnov (mithraen) 2006-05-21 10:35:04

Would this patch updated to current trunk and integrated?

By: Serge Vecher (serge-v) 2006-06-07 14:48:48

oej is this [post 1.4] material?

By: xrobau (xrobau) 2006-06-08 07:57:45

oej has said quite a few times that this is the wrong implementation, and he mentioned that he's working on it in another branch - which branch, oej? Especially with 1.4 on the horizon, I'd really like to get this functionality into 1.4, even if it will be another aftermarket patch like this one..

By: Olle Johansson (oej) 2006-06-08 09:14:15

I have a branch called "callpickup". Have had some other priorities and got sidetracked from this, but need to get back on track.

By: Michael Gernoth (mgernoth) 2006-07-28 05:25:40

I have just uploaded pickup-mgernoth-2006-07-28.patch.txt which should fix the problem from bug 7162 and applies to the current 1.2 svn.

By: Serge Vecher (serge-v) 2006-07-28 08:38:53

mgernoth: thanks for the updated 1.2 patch -- please also upload a patch for the latest trunk.

edit: nevermind, I looked at it and saw that it is already against trunk. Thanks ;)



By: Olivier Krief (okrief) 2006-09-12 10:01:52

Link to http://bugs.digium.com/file_download.php?file_id=9459&type=bug [^] is broken

By: bladerunner (bladerunner) 2006-09-13 10:23:21

is this patch obsolete with latest SVN?

if not, could we please get an updated version, I really don't care if the channel_walk is a bad idea, but need the pickup-feature desperately.

also I am no good with C, my attempts to port the patch to latest SVN failed miserably.

By: Dr. W.A. Slaby (was) 2006-10-10 00:46:58

I tried the latest patch pickup-mgernoth-2006-07-28.patch.txt together
with Asterisk 1.2.12.1 with the following effect:
The LEDs for all subscribed destinations are switched on permanently
although they are all reachable and no calls are active.
An update to this patch to overcome this situation would be appreciated very much.
Thank you in advance for your efforts.

By: Michael Gernoth (mgernoth) 2006-10-10 07:44:45

I have uploaded an updated Patch which fixes the indicated CallerID on the subscribed phones.

@was: I have never seen such a behaviour. One thing you could try is to reboot all destination-phones to see if this changes the LED behaviour. And look at the output of show hints in which state the subscribed destinations are.

By: Dr. W.A. Slaby (was) 2006-10-10 09:22:31

@mgernoth:
Rebooting the destination phones does not change the LEDs being permanently on.
"show hints" says "State:InUse" for all subscribed destinations.
"sip show subscriptions" says "Last state : idle" for all subscribed destinations.

11.10.2006:
Meanwhile I have detected that the problem has nothing to do with the patch. The behaviour of asterisk/hint was broken with Snom Firmware 6.3. Using firmware 6.5 beta solves the problem.



By: jmls (jmls) 2006-11-12 02:49:45.000-0600

oej, where do we stand with this right now ?

By: Naftali (naftali5) 2006-11-14 21:37:31.000-0600

I have tried to use directed call pickup feature with
Asterisk 1.2.12.1
Aastra 480i firmware 1.4

Source downloaded from
http://ftp.digium.com/pub/asterisk/old-releases/asterisk-1.2.12.tar.gz
applied pickup-mgernoth-2006-10-03.patch
from http://bugs.digium.com/view.php?id=5014

allowed directed call pickup through web gui
added blf which works fine, and ringing is indicated by bell icon

-pressing the ringing key dials that extension and i get voicemail.

what am I doing wrong



By: Andy Wang (andywang) 2006-11-15 13:19:13.000-0600

To naftali5:

Please try pickup-mgernoth-2006-07-28.patch.txt, it will works well.

By: Naftali (naftali5) 2006-11-15 19:20:16.000-0600

@andywang: Thanks a lot! It works as expected.

@mgernoth: I'd expect a later patch to work better, but pickup-mgernoth-2006-10-03.patch doesn't work for me at all
and pickup-mgernoth-2006-07-28.patch.txt works like a charm.

1.2.12.1

if you want any debug info, I can post...

By: Thomas Gick (u0000064) 2006-12-19 12:57:16.000-0600

Should this patch work with 1.2.14?



By: Serge Vecher (serge-v) 2006-12-19 13:50:06.000-0600

u0000064, naftali5, andywang : as has been mentioned numerous times, this is experimental code and will never be up for consideration for 1.2 or 1.4. The patches that apply to 1.2.x tree are allowed to to stay here as a courtesy and if this courtesy is abused by repeatedly asking for updated 1.2.x patches, all said patches will be removed. There are other resources on the web, like asterisk-backports.org, that are better suited for maintaining patches that are not candidates for Asterisk-tree inclusion and I suggest that all 1.2.x users of this patch migrate there. Please keep this bug for discussion of the code oej is working on, or at the very least the trunk versions of the patch. Thanks for understanding.

By: Andy Wang (andywang) 2006-12-19 14:24:47.000-0600

serge-v: Thanks for the clearly explanation. I thought the intention of being here is to contribution. If my courtesy is thinking as being abused please accept my appologize. It's a great place though...

By: pkempgen (pkempgen) 2007-03-30 22:48:05

I have written a patch ("simple-pickup-...") which makes Asterisk
send a more complete dialog XML to Snom phones. It does not send the
correct original caller-id but pickup works perfectly.

This patch is for the trunk (revision 59605).
As this is hardly 3 lines of code I doubt I have to send a
disclaimer.

Haven't done C in ages and I'm not sure what would be the correct
way to get the caller-id at that point.
I think Olle is working on something bigger but this might be
a temporary fix. (EDIT: This would be compatible to chan_sip in
oej's "callpickup" branch as it just makes the XML dialog more
complete.)



By: jackfritt (jackfritt) 2007-04-04 08:49:55

@pkempgen

I tried your patch, but the only thing that happens is that the display says
callee * but the call is not picked.
I did svn -r59605 co http://svn.digium.com/svn/asterisk/trunk
and applied your patch. Maybe I did something wrong ?

Is it right that this patch is for 1.4 ?

I use Snom360 with firmware 6.58.

By: pkempgen (pkempgen) 2007-04-04 14:08:27

@jackfritt: My "simple-pickup-..." patch is for the trunk but should work
with 1.4.2 as well. It's correct that the display says "caller *" because
I do not send out the correct caller-id of the original caller.

In features.conf I have pickupexten = *8 which is the default and in
extensions.conf you need something like:

exten => _*8.,1,Set(pickup_exten=${EXTEN:2})
exten => _*8.,n,NoOp(Trying to pickup ${pickup_exten})
exten => _*8.,n,Pickup(${pickup_exten}@default)

or simply
exten => _*8.,1,Pickup(${EXTEN:2}@default)

In sip.conf my users have pickupgroup=1, callgroup=1, call-limit=1.

Please report back if this works or doesn't work for you.



By: jackfritt (jackfritt) 2007-04-05 04:40:29

@pkempgen:

exten => _*8.,1,Pickup(${EXTEN:2}@default)

works great ! I applied the patch to 1.4.2 and also to the pickup branch from oej and it works there too.

I work with a lot of Goto.
Then I have the problem that the wrong ${EXTEN} is reported.
Example code:
[default]
5505,1,Goto,test123|s|1
;5505 is an misdn port

[test123]
s,1,dial,SIP/13||

And if I try to pickup SIP/13 this doesn?t work.
Because it tries to pickup EXTEN 13.
I need to pickup s@test123.
If I use this code
exten => _*8.,n,Pickup(s@test123)
even the pickup of the misdn channel works.

I need to rework my dialplan to pickup misdn channels also.

Thx, for your great patch. You made my easterdays feel like christmasdays ;)

By: pkempgen (pkempgen) 2007-04-05 05:09:03

@jackfritt: Thanks :)

Here's my new patch ("pkempgen-pickup-60212.patch") for the trunk,
rev. 60212. It sends the correct caller-id now (*without* channel
walking).

My disclaimer is on it's way (fax).

By: jackfritt (jackfritt) 2007-04-05 06:45:04

@pkempgen
patch apply clean against rev. 60212 but not to 1.4.2 but who cares ?
caller-id works now, too.

Thx and thx again ;)

By: Michael Gernoth (mgernoth) 2007-04-07 18:17:08

Nice patch pkempgen :-)

Just one thing: Currently you can't be sure to pick up the call whose number is displayed when more than one call is ringing on the extension which is going to be picked up.

Idea for that: Put the content of a unique channel variable (${CHANNEL}, p->owner->name?) into the target uri and use the PICKUPMARK for the PickUp application instead of the extension.

As I have currently no test setup for pickups, I can't provide you a tested patch for this :-(

By: pkempgen (pkempgen) 2007-04-07 20:37:33

Thanks. :)

Though I'm still undecided whether I like that idea or if it would be more
correct to use the Replaces header.

oej has this code in his callpickup branch:
---cut---
/* If we have a channel, fake a unique call ID that we can use for call pickups. */
if (channel)  /* that's a char* --pkempgen */
snprintf(pickupcallid, sizeof(pickupcallid), "call-id=\"astpickup--%s--%s--%s\" local-tag=\"%s\" remote-tag=\"%s\"", global_realm, p->exten, channel, "ltag", "rtag");
---cut---

If we sent a call-id attribute in the dialog tag the Snom would copy this
value to the Replaces header. So there might not even be the need to use
Pickup() in the dialplan, provided the "picker" is allowed to pick that
channel according to callgroups and pickupgroups. All we'd had to do once
an INVITE with a Replaces: astpickup... header is received is find the call,
check if they are allowed to pick it and trigger the pickup code.
Any thoughts?

EDIT: Is the Replaces header still available when executing Pickup()? (in
initreq or something?) I don't want the call to be picked automatically
in chan_sip because of limited pickupgroups (64 bit mask) but have control
over whether the call gets picked in the dialplan (with Pickup()).



By: jackfritt (jackfritt) 2007-04-11 07:39:04

I have the problem mgernoth talked about.
When a second call comes in, pickup() connects all? misdn calls together.
I can hear all people talking. I heard about the PICKUPMARK Variable.
I don?t know how to use it and if it works with the patch from
pkempgen.

By: pkempgen (pkempgen) 2007-04-11 07:56:20

I don't really understand how Pickup() would interconnect 3 calls.

But then you should experience the same thing when doing a "manual" pickup
(i.e. dial *8... to pick up the call(s)). My patch doesn't change *anything*
in the way the Pickup() application or the PICKUPMARK works.

Can you attach a sip trace from the Snom which does the pickup? (Please clear
the history before trying the scenario.)

By: jackfritt (jackfritt) 2007-04-11 08:23:12

Ok, forget the whole thing. Everytime I tried this I had 4 Phones next to each other. So I produced a lot of echos. Next time before I write such thing I?ll try it in different rooms. Sorry for the headache.
I tried so much different things the last weeks, I should take some free days for fishing ;)

By: jackfritt (jackfritt) 2007-04-19 02:24:48

I have random segmentation faults and I don?t know if this has something to do with the patch or if its just the development tree. I have added a full backtrace of the segmentation fault. Maybe someone can see where the problem is.

When the segfault happened one person was talking with  SIP/21 to misdn line.

I use Asterisk SVN-trunk-r61667M with pkempgen-pickup-60212.patch

By: Gregory Hinton Nietsky (irroot) 2007-08-04 10:18:05

just added a non chan_walking patch for 1.4.9 seems to do the trick in a equivilant way to the original patch without the chan walk it is still not 100%

By: pkempgen (pkempgen) 2007-08-04 12:41:09

"not 100%" - what does that mean? ;)
Perhaps you could tell us so I or someone else can fix it?



By: Gregory Hinton Nietsky (irroot) 2007-08-05 08:16:08

not 100% means althogh it does not do a channel walk it is still limited to only working with SIP phones.... this is not ideal as you would wanty to be able to pickup any technology with a directed pickup.

what this does is to get the snom to send a reinvite/replaces with the sip bits to do a pickup.

traversing the iflist is more friendly than going through all channels and works fine as far as i can see ...

this is fine for a all sip implementation ... locking the iflist could be a good idea i guess ...

By: Sylvain Boily (sboily_proformatique) 2007-09-04 09:35:17

Hi,

I have upload a modified version for asterisk 1.2.24. It was possible to intercept call with thomson 2030 and 2022.

By: Sylvain Boily (sboily_proformatique) 2007-09-04 09:35:45

Sorry i forgot the name : pf_intercept_monitored.patch

By: C. Earley (cearley) 2007-11-25 16:01:11.000-0600

Hi,

How can I get the pickup-mgernoth-2006-07-28.patch? There are no links to it on this page.

A Google search revealed that others are asking the same question.

Thanks.

By: Michael Gernoth (mgernoth) 2007-11-25 16:06:43.000-0600

I have just noticed that my patches are no longer available and I need to sign a new disclaimer online. I had previously sent one by fax...
In the meantime you can get the pickup-patch at http://rmdir.de/~michael/ where you can also find a new version.

EDIT: The disclaimer was accepted by digium but the license is still NONE...



By: pkempgen (pkempgen) 2007-11-27 10:56:57.000-0600

For a description of dialog-info XML messages see RFC 4235.

By: Olle Johansson (oej) 2007-11-27 12:55:35.000-0600

pkempgen: You need to fix your license so I can see your XML update. Thanks.

By: pkempgen (pkempgen) 2007-11-27 13:11:42.000-0600

oej: My disclaimer was faxed to Digium before I had uploaded the patch.
When the online license check was integrated into Mantis I followed the
instructions and my license was accepted by mpetrone (@ Digium). So I have
no idea why my patch shows "License NONE" and what I can do to change that.

EDIT: Michelle "magically" fixed it :-)  Thanks again!



By: Martin Vit (festr) 2007-12-14 08:01:34.000-0600

Hi, i'm testing patch sip.snom.pu with 1.4.15 and i've replicable deadlocks. I'm attaching core show locks + gdb snapshot applied on all threads. See attached file deadlock-festr-2.

By: Torsten Krah (tkrah) 2007-12-27 12:39:47.000-0600

You may try the: pkempgen-pickup-60212.patch.
Only some minor changes are needed to get it working - it applies fine to 1.4.15 and afaik it works without problems.

By: jackfritt (jackfritt) 2007-12-28 02:49:14.000-0600

@tkrah
I tried it with 1.4.16.2 and had a few rejects. I applied them by hand. It seems to work since 5 minutes. Lets see what happens today.

By: Torsten Krah (tkrah) 2008-01-10 12:39:28.000-0600

I've got a Snom360 which subscribed to some other phones:
Lets take three extensions, 10, 11 and 15.

10 did a redirection on the phone to 15.
If someone calls 10 it gets correctly transfered to 15.
11 is subscribed to 10 and 15.

If 10 is ringing, 11 gets early state sip message.
10 redirects with 302 to 15.
Now 11 gets early state notify message about 15.
And 11 gets a terminate message about 10 (which is good, but * still does sent early state messages later).
Now if the call is canceled, a terminated notify message is sent to 11 that 15 is now in idle state.

But * does still sent early state messages to 11 telling that 10 is in early state (after the terminated message above), although no one is calling 10 (it was redirected to 15).
I would expect, if 302 is sent from a subscribed extension and this is successfull, a terminated notify is sent to 11 about 10 and thats it.

The subscribed party now sees in a "neverending" loop that 10 is ringing althoug "its not".
It gets only cleared at the time the subscriptions are refreshed, either through timeout or reboot of the phone.
Without pkempgens patch this does not happen.

Trace is siptrace-notify.txt.

By: pkempgen (pkempgen) 2008-02-29 10:34:21.000-0600

> Channels/chan_sip => Channels/NewFeature

Afaicr the XML content is incomplete.
So imho this is a bug, not a new feature.

By: Joshua C. Colp (jcolp) 2008-03-10 11:17:18

pkempgen: If there is a second issue including improperly formatted XML outside of using this patch... then that should be on a separate issue. This one is clearly for adding support for call pickup on Snom phones.

By: pkempgen (pkempgen) 2008-03-11 10:32:05

Had a quick look at the simple-pickup-2007-03-31.patch I wrote.
Looks like the missing
<remote><identity display=\"%s\">%s</identity><target uri=\"sip:%s%s@%s\"/></remote>
is more or less what prevents the Snom from doing the pickup. You
won't get the callerid of the original caller but the pickup works.
The XML content is valid XML without it but the Snom wants it. :-)

By: Russell Bryant (russell) 2008-03-13 13:56:41

After long consideration, we have decided that this patch isn't something that we can apply to Asterisk.  We have a strong architectural policy that we do things in a channel technology independent way.  Unfortunately, in this case, this is a very SIP specific patch.  To be able to do such a thing such that it is architecturally compatible with Asterisk would be a lot more work.

If someone wanted to work on such a patch, then let's talk about the planned implementation ahead of time on the asterisk-dev mailing list so that we can come up with a solution that fits something that we could merge.

By: Russell Bryant (russell) 2008-09-11 11:48:54

Reopening, as we're going to work on addressing my previously stated concerns and get this code merged.  :)

By: pkempgen (pkempgen) 2008-09-12 01:33:22

Great news. Let my try help you to get rid of your concerns:  :-)
What my patch (2007-04-05) for example does is make the XML content in the
NOTIFY more complete (see RFC 4235). It doesn't change anything at all
about how pickup works in Asterisk, so it's not SIP-specific. This bug
should probably be renamed from "implement call pickup on Snom phones" to
something like "make the extension state notifications RFC-4235-compliant".
(The Snom can use that additional information to make pickup possible but
that's just a side-effect.) I suggest this bug be about RFC 4235. If something
should be done about changing about how pickup works in a channel-independant
manner that should go to a seperate bug IMHO.

By: Theo Belder (tbelder) 2008-09-12 01:41:10

Since Snom FW version 7.1.33 it's possible to program the Function Key on a different way (type BLF):
Configure a Function Key with Type "BLF" for the extension you want to monitor and append the pickup string "|*8" to the content of the "Number" field.

e.g. If you have a button configured with Button Type "BLF" and Number "<31@registrar>" to monitor extension 31, change the value to "<31@registar>|*8"

Then, if the Extension enters "Ringing" state, the LED beside the button will start blinking. When you press the blinking button, the phone dials "*831" instead of "31" and executes the pickup in the Asterisk dialplan.


See also: http://asterisk.snom.com/index.php/Asterisk_1.4/Call_Pickup

By: pkempgen (pkempgen) 2008-09-12 01:57:28

I know but for the user agent to be able to display who is calling the
caller ID has to be added to the NOTIFYs XML content.

By: philipp2 (philipp2) 2008-09-12 08:03:01

I'd like to invite you to at least look at this work, and if that's only for inspiration:

http://www.net-performer.de/asterisk/asterisk-1.4.21-pickup-by-call-id.patch
http://www.ip-phone-forum.de/showpost.php?p=1120397&postcount=222
http://www.ip-phone-forum.de/showthread.php?t=111596&highlight=pickup+snom&page=12

By: Sean Bright (seanbright) 2008-09-23 20:00:04

I've uploaded two patches for this issue, one against 1.4 and another against trunk.

Assuming we are bug free and working, the patch will be committed to trunk, while the 1.4 will remain available here.

Note that the Caller ID information will not be available on the SNOM.  There is currently no reliable way of getting this information.  I reiterate the phrase "no reliable" because I have seen the other patches attached to this issue that pass Caller ID name and number along with the extension state change events.  While this works for a lot of cases, in others it won't, so we decided to just not show it at all.

Please let me know of any crashes/lockups/etc. that you might come across and include backtraces if possible!

By: pkempgen (pkempgen) 2008-09-24 07:03:23

> Note that the Caller ID information will not be available on the SNOM.
> There is currently no reliable way of getting this information.  I
> reiterate the phrase "no reliable" because I have seen the other patches
> attached to this issue that pass Caller ID name and number along with the
> extension state change events.  While this works for a lot of cases, in
> others it won't

What was wrong with it?

By: Sean Bright (seanbright) 2008-09-24 08:22:38

Nothing was wrong with it, but here is a (somewhat contrived) example of one of the issues:

SNOM: Monitoring extension 100
Call A: Call from "Joe <1>" to 100
Call B: Call from "Jane <2>" to 100

Call A calls 100, "Joe <1>" is sent to the SNOM via NOTIFY (100 is now 'ringing).
Call B calls 100, "Jane <2>" is sent to the SNOM via NOTIFY (100 is still ringing).

Now, we have two separate calls with distinct CID data.  Which one is "right?"  Which do we display on the SNOM?  The whole point is that the CID information is not predictive.



By: pkempgen (pkempgen) 2008-09-24 08:38:29

I see. Not predictive unless either call waiting was disabled on 100 or
Pickup() was predictive to always pickup the latest call.

btw: Your |B| mark causes the teyt to be bold (improper HTML-escaping in
Mantis).

By: Sean Bright (seanbright) 2008-09-24 09:12:37

Correct.  The way Pickup (with an exten/context argument) works now is it will just pickup the first channel it finds that matches the criteria.

(And I fixed my previous note, sorry about yelling :))

By: Digium Subversion (svnbot) 2008-09-30 16:22:57

Repository: asterisk
Revision: 145226

U   trunk/CHANGES
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r145226 | russell | 2008-09-30 16:22:56 -0500 (Tue, 30 Sep 2008) | 16 lines

Add support for call pickup on Snom phones.  Asterisk now includes a magic
call-id in the dialog-info event package used with extension state subscriptions
on Snom phones.  Then, when the phone sends an INVITE with Replaces for the
special callid, Asterisk will perform a pickup on the extension that was
subscribed to.

The original code on this issue was submitted by xylome.  However, contributions
have been made by (at least) mgernoth and pkempgen.  The final patch was written
by seanbright, and includes the necessary logic to allow this work in a
technology independent way.

(closes issue ASTERISK-4887)
Reported by: xylome
Patches:
     issue5014-trunk.diff uploaded by seanbright (license 71)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=145226