[Home]

Summary:ASTERISK-15877: [patch] Pickup with Aastra phones: Unable to find subscription
Reporter:Fossard Florent (ffossard)Labels:
Date Opened:2010-03-26 06:14:25Date Closed:2010-12-07 16:39:12.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Subscriptions
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) dump.tcpdump
( 1) pickup_fix.diff
( 2) sip-debug-patched-pickup-fails.txt
( 3) sip-debug-pickup.txt
Description:Hello

With Asterisk 1.6.2, the directed pickup don't works with Aastra phones (53/55/57/30/31i)
It works good with 1.4, 1.6.0, 1.6.1, but not with 1.6.2
The blf works good.
The pickup works good with "*8 + number".

When I press a blinking button, there is only that in CLI, and no pickup on the phone:
NOTICE[5161]: chan_sip.c:19843 handle_request_invite: Unable to find subscription with call-id: fb287af6461e248a

the "sip show subscriptions" command return the good call-id:
localhost*CLI> sip show subscriptions
Peer             User             Call ID          Extension        Last state     Type            Mailbox    Expiry
10.0.0.167       guillaume        fb287af6461e248  746@blf          Idle           dialog-info+xml <none>     000360
2 active SIP subscription
Is the call-id truncated? (fb287af6461e248 => fb287af6461e248a )



I can "solve" the problem by replacing this two pieces of 1.6.2 chan_sip by the same pièces of 1.6.1, this works but it's not a

solution:

1.6.2:

if ((state & AST_EXTENSION_RINGING) && sip_cfg.notifyringing) {
const char *local_display = p->exten;
char *local_target = mto;
/* There are some limitations to how this works.  The primary one is that the
callee must be dialing the same extension that is being monitored.  Simply dialing
the hint'd device is not sufficient. */
if (sip_cfg.notifycid) {
struct ast_channel *caller = ast_channel_search_locked(find_calling_channel, p);
if (caller) {
int need = strlen(caller->cid.cid_num) + strlen(p->fromdomain) + sizeof("sip:@");
local_target = alloca(need);
snprintf(local_target, need, "sip:%s@%s", caller->cid.cid_num, p->fromdomain);
local_display = ast_strdupa(caller->cid.cid_name);
ast_channel_unlock(caller);
caller = NULL;
}
}
/* We create a fake call-id which the phone will send back in an INVITE
Replaces header which we can grab and do some magic with. */
ast_str_append(&tmp, 0,
"<dialog id=\"%s\" call-id=\"pickup-%s\" direction=\"recipient\">\n"
"<remote>\n"
/* See the limitations of this above.  Luckily the phone seems to still be
happy when these values are not correct. */
"<identity display=\"%s\">%s</identity>\n"
"<target uri=\"%s\"/>\n"
"</remote>\n"
"<local>\n"
"<identity>%s</identity>\n"
"<target uri=\"%s\"/>\n"
"</local>\n",
p->exten, p->callid, local_display, local_target, local_target, mto, mto);
} else {
ast_str_append(&tmp, 0, "<dialog id=\"%s\">\n", p->exten);
}


1.6.1:

if ((state & AST_EXTENSION_RINGING) && global_notifyringing)
ast_str_append(&tmp, 0, "<dialog id=\"%s\" direction=\"recipient\">\n", p->exten);
else
ast_str_append(&tmp, 0, "<dialog id=\"%s\">\n", p->exten);






1.6.2:

/* Try to find call that we are replacing.
  If we have a Replaces header, we need to cancel that call if we succeed with this call.
  First we cheat a little and look for a magic call-id from phones that support
  dialog-info+xml so we can do technology independent pickup... */
if (strncmp(replace_id, "pickup-", 7) == 0) {
struct sip_pvt *subscription = NULL;
replace_id += 7; /* Worst case we are looking at \0 */
if ((subscription = get_sip_pvt_byid_locked(replace_id, NULL, NULL)) == NULL) {
ast_log(LOG_NOTICE, "Unable to find subscription with call-id: %s\n", replace_id);
transmit_response_reliable(p, "481 Call Leg Does Not Exist (Replaces)", req);
error = 1;
} else {
ast_log(LOG_NOTICE, "Trying to pick up %s@%s\n", subscription->exten, subscription->context);
ast_copy_string(pickup.exten, subscription->exten, sizeof(pickup.exten));
ast_copy_string(pickup.context, subscription->context, sizeof(pickup.context));
sip_pvt_unlock(subscription);
if (subscription->owner) {
ast_channel_unlock(subscription->owner);
}
}
}
/* This locks both refer_call pvt and refer_call pvt's owner!!!*/
if (!error && ast_strlen_zero(pickup.exten) && (p->refer->refer_call = get_sip_pvt_byid_locked(replace_id, totag, fromtag)) == NULL)

{
ast_log(LOG_NOTICE, "Supervised transfer attempted to replace non-existent call id (%s)!\n", replace_id);
transmit_response_reliable(p, "481 Call Leg Does Not Exist (Replaces)", req);
error = 1;
} else {
refer_locked = 1;
}


1.6.1:

/* Try to find call that we are replacing
If we have a Replaces  header, we need to cancel that call if we succeed with this call
*/
if ((p->refer->refer_call = get_sip_pvt_byid_locked(replace_id, totag, fromtag)) == NULL) {
ast_log(LOG_NOTICE, "Supervised transfer attempted to replace non-existent call id (%s)!\n", replace_id);
transmit_response_reliable(p, "481 Call Leg Does Not Exist (Replaces)", req);
error = 1;
} else {
refer_locked = 1;
}
/* At this point, bot the pvt and the owner of the call to be replaced is locked */




I've searched and found news things about pickup with asterisk 1.6.2:
http://www.mail-archive.com/asterisk-users@lists.digium.com/msg234379.html
http://lists.digium.com/pipermail/asterisk-users/2010-February/244771.html
http://www.asterisk.org/doxygen/asterisk1.6.2/chan__sip_8c.html (search "Unable to find subscription with call-id" in the page)



Maybe not really a bug, but a significant change which blocks an essential feature.

****** ADDITIONAL INFORMATION ******

sip.conf:

[general]
srvlookup=yes
context=telephones
port=5060
bindaddr=0.0.0.0
language=fr
localnet=10.0.0.0/255.255.255.0
bindport=5060
canreinvite=no
qualify=yes
notifyringing=yes
notifymimetype=application/simple-message-summary
allowsubscribe=yes
notifyhold=yes
limitonpeers=yes
pedantic=yes
directrtp=no

; template
[aastra](!)
type=friend
qualify=yes
nat=no
host=dynamic
canreinvite=no
disallow=all
allow=alaw
call-limit=10
subscribecontext=blf

[michel](aastra)
defaultuser=michel
secret=secret
callerid=michel <742>
context=telephones

(...and others phones)



extensions.conf:

[general]
static=yes
writeprotect=no
autofallthrough=no
clearglobalvars=no
language=fr

[globals]

[telephones]
include => blf
include => pickup
include => internal

[internal]
exten => 742,1,Dial(SIP/michel,60,tTwW)
exten => 742,n,hangup
exten => 746,1,Dial(SIP/benjamin,60,tTwW)
exten => 746,n,hangup
exten => 747,1,Dial(SIP/guillaume,60,tTwW)
exten => 747,n,hangup

[pickup]
exten => _*8.,1,SET(GLOBAL(PICKUPMARK)=${EXTEN:2})
exten => _*8.,n,Pickup(${EXTEN:2}@PICKUPMARK)
exten => _*8.,n,Hangup

[blf]
exten => 742,hint,SIP/michel
exten => 746,hint,SIP/benjamin
exten => 747,hint,SIP/guillaume



Aastra config:

<MAC>.cfg
prgkey1 type: blfxfer
prgkey1 label:
prgkey1 value: 742

prgkey2 type: blfxfer
prgkey2 label:
prgkey2 value: 746

aastra.cfg:
...
directed call pickup: 1
directed call pickup prefix: *8
...
Comments:By: Fossard Florent (ffossard) 2010-03-29 11:10:40

If necessary, I've a sip debug of a failed pickup.

By: David Vossel (dvossel) 2010-05-12 16:13:44

Yes, please provide sip debug.  A packet capture would help as well.

By: David Vossel (dvossel) 2010-05-12 16:15:56

also, a packet capture of the Aastra phone working correctly with 1.6.1 would be useful as well.

By: Fossard Florent (ffossard) 2010-05-12 17:03:27

I will try to provide this next week.

By: JPC (xricinx) 2010-05-18 02:29:08

I'm having the exact same issue with all my Grandstream phones (GXP-2010,GXP-2020).  BLF directed pickup worked great in 1.6.1, after update to 1.6.2 it fails. I can direct dial call pickup from the phone without issue.

By: David Vossel (dvossel) 2010-05-18 09:24:25

Any update on getting a packet capture and some debug information?

By: Gareth Blades (gblades_skymarket) 2010-05-21 10:36:28

I am experiencing the same issue so I have captured the data for you.
I made a call from extension 916 to 901 and then tried to pickup extension 901 from 905.

Attached is a sip debug on one call and a tcpdump capture (with -s 0) of a second.

By: Udo Schacht-Wiegand (udosw) 2010-05-24 08:46:20

I can confirm the exact same behaviour for Thomson ST2030 und snom 300 phones. Even more, when sip.conf has 'pedantic=yes' while hitting the blinking BLF key, it will say "Unable to find subscription with call-id: ...". When set 'pedantic=no' it says: 'Trying to pick up XXX@hints' and then fails to do so.

By: David Vossel (dvossel) 2010-05-24 10:33:15

Thank you for the debug information.  I have a SNOM phone so it sounds like I should be able to reproduce this easily.

By: David Vossel (dvossel) 2010-05-25 11:32:01

I uploaded a patch that should resolve the issue with pedantic=yes generating the "unable to find subscription with call-id" issue.   The other issues appear to be config related.  In the config in the description, I noticed that the 'notifycid' option is not set.  Correctly setting this along with applying the patch should resolve the issue.  Look at configs/sip.conf.sample for documentation of the 'notifycid' option.  

I got this feature to work with my SNOM phone by applying the patch, putting the hint in the same context as the extension, and setting 'notifycid=yes'.  Please let me know if this helps resolve the issue.


By: Steve Davies (one47) 2010-05-26 04:46:35

This sounds very much like an issue I discovered way back in 1.0 - My diagnosis back then was that this is an Aastra problem - They do not like the extended XML Dialog format added in 1.6.2 (it was also available as a patch since 1.0)

I had a patch which adds a new per-peer "shortnotify" parameter which causes the old smaller XML format to be sent to specified SIP devices.

Sadly that patch is for an old 1.2 build, and is obsolete, but should be quite easy to replicate.

By: Udo Schacht-Wiegand (udosw) 2010-05-26 06:27:07

I applied the patch from dvossel on 1.6.2.6 and 1.6.2.7 with no success, tried both with pedantic=yes and =no. Uploaded 'sip-debug-patched-pickup-fails.txt' is a failing pickup: Phone 347 calls 346, and 344 (a Thomson ST2030) tries to pick up 346.

By: David Vossel (dvossel) 2010-05-26 12:01:12

Udsow, can you post your sip.conf and extensions.conf, or at least the relevant parts here.

Based upon your debug information, this looks similar to a configuration problem I had.  If you have 'notifycid=yes' in your sip.conf and the 'subscribecontext' is not the same as the peer's 'context', then the call will not be found.  To do this you'd have to set 'notifycid=ignore-context' and then you have to set the 'PICKUPMARK' channel variable correctly in the dialplan for the extension you want to pickup.  This is further documented in the sip.conf.sample file for the 'notifycid' option.

I've been testing this by setting 'notifycid=yes' and putting the hint in the same context as the extension.  Below is an example of the config I'm using and it works for me with my SNOM 370 even without the patch (with the patch I can set pedantic=yes).  In this example, 222 calls 111.  The snom370 subscribes to 111 and picks up the ringing 111 extension.

---extensions.conf---
[general]

[phones]
exten => 111,n,Dial(SIP/111)
exten => 111,hint,SIP/111

---sip.conf---

pedantic=no
notifyringing=yes
notifycid=yes
notifyhold=yes
limtonpeers=yes
callcounter=yes
disallow=all
allow=ulaw

[111]
type=friend
context=phones
host=dynamic
secret=xxx

[222]
type=friend
context=phones
host=dynamic
secret=xxx

[snom370]
type=friend
context=phones
host=dynamic
secret=xxx
allowsubscribe=yes
subscribecontext=phones

By: Udo Schacht-Wiegand (udosw) 2010-05-26 17:23:43

This is amazing: Using the sip.conf like above and even with pedantic=yes and with an unpatched 1.6.2.7 pickup works with a snom 300 phone (ext 346):

   -= Registered Asterisk Dial Plan Hints =-
                   347@phones              : SIP/347               State:Idle            Watchers  1
                  _XXX@phones              : SIP/${EXTEN}          State:Unavailable     Watchers  0
----------------
- 2 hints registered

debian*CLI>
 == Using SIP RTP CoS mark 5
   -- Executing [347@phones:1] Dial("SIP/348-00000004", "SIP/347") in new stack
 == Using SIP RTP CoS mark 5
   -- Called 347
 == Extension Changed 347[phones] new state Ringing for Notify User 346
   -- SIP/347-00000005 is ringing
 == Using SIP RTP CoS mark 5
[May 27 00:16:30] NOTICE[7654]: chan_sip.c:19872 handle_request_invite: Trying to pick up 347@phones
[May 27 00:16:30] NOTICE[7654]: chan_sip.c:19872 handle_request_invite: Trying to pick up 347@phones
   -- SIP/346-00000006 answered SIP/348-00000004
   -- Native bridging SIP/348-00000004 and SIP/346-00000006
 == Extension Changed 347[phones] new state Idle for Notify User 346

Will try with the ST2030 phone tomorrow.

By: Udo Schacht-Wiegand (udosw) 2010-05-27 05:30:50

Tried with the Thomson ST2030 phone:
With pedantic=yes, pickup always fails, either patched or unpatched * (1.6.2.6/1.6.2.7).
With pedantic=no: Pickup works OK, also with unpatched *. So it is a configuration issue with the ST2030, too. Should be fixed for pedantic=yes, though. What should I provide to help with that?

BUT: This pickup is completely different from what we had till 1.6.1.x: It works inside the SIP dialog without the dialplan having any control on the pickup. Even callgroup/pickupgroup are w/o effect here, so we have no control about who is allowed to pickup.
The above patch from ffossard restores the 'old' behaviour, where the phone would dial *8XXX and one would be able to deal with that in the dialplan.



By: Olivier Krief (okrief) 2010-05-27 10:26:52

To udosw:
To make it work with ST2030 (pedantic=no):
1. Do you have a separate context for hints ?
2. Did you set notifycid ?
3. How do you set BLF for the ST2030 ? Do you still use *8-like Starcode ?

By: Fossard Florent (ffossard) 2010-05-27 11:09:55

Probem solved for Aastra with last firmware 2.6 (may 2010) !
I reported this issue last month in aastra support.

Actually this work with Asterisk 1.6.2.7 (no patch), Aastra 53i with 2.6 firmware, and this config:

sip.conf
[general]
srvlookup=yes
context=internal
port=5060
bindaddr=0.0.0.0
language=fr
localnet=10.0.0.0/255.255.255.0
nat=no
bindport=5060
canreinvite=no
qualify=yes
notifyringing=yes
;notifycid=yes <=== this work with and without this.
notifyhold=yes
notifymimetype=application/simple-message-summary
allowsubscribe=yes
limitonpeers=yes
pedantic=yes

; template
[aastra](!)
type=friend
host=dynamic
nat=no
qualify=yes
canreinvite=no
disallow=all
allow=alaw
call-limit=10
subscribecontext=blf
context=internal

[tel1](aastra)
defaultuser=tel1
callerid=tel1 <101>
secret=secret

[tel2](aastra)
defaultuser=tel2
callerid=tel2 <102>
secret=secret

[tel3](aastra)
defaultuser=tel3
callerid=tel3 <103>
secret=secret

extensions.conf
[general]

[internal]
include => blf
include => pickup

exten => 101,1,Dial(SIP/tel1)
same =>      n,hangup
exten => 102,1,Dial(SIP/tel2)
same =>      n,hangup
exten => 103,1,Dial(SIP/tel3)
same =>      n,hangup

[blf]
exten => 101,hint,SIP/tel1
exten => 102,hint,SIP/tel2
exten => 103,hint,SIP/tel3

[pickup]
exten => _*8.,1,SET(GLOBAL(PICKUPMARK)=${EXTEN:2})
exten => _*8.,n,Pickup(${EXTEN:2}@PICKUPMARK)
exten => _*8.,n,Hangup


CLI:
-- SIP/tel2-0000001c is ringing
== Using SIP RTP CoS mark 5
== Extension Changed 101[blf] new state InUse for Notify User tel2
-- Executing [*8102@internal:1] Set("SIP/tel1-0000001d", "GLOBAL(PICKUPMARK)=102") in new stack
== Setting global variable 'PICKUPMARK' to '102'
== Extension Changed 101[blf] new state InUse for Notify User tel3
-- Executing [*8102@internal:2] Pickup("SIP/tel1-0000001d", "102@PICKUPMARK") in new stack
== Extension Changed 101[blf] new state InUse for Notify User tel1
-- Executing [*8102@internal:3] Hangup("SIP/tel1-0000001d<MASQ>", "") in new stack
== Spawn extension (internal, *8102, 3) exited non-zero on 'SIP/tel1-0000001d<MASQ>'
-- SIP/tel1-0000001d answered SIP/tel3-0000001b
-- Packet2Packet bridging SIP/tel3-0000001b and SIP/tel1-0000001d




with old 2.5.3 firmware:
-- Called tel2
== Extension Changed 102[blf] new state Ringing for Notify User tel3
== Extension Changed 102[blf] new state Ringing for Notify User tel1
-- SIP/tel2-0000001a is ringing
-- SIP/tel2-0000001a is ringing
== Using SIP RTP CoS mark 5
[May 27 17:41:13] NOTICE[28522]: chan_sip.c:19868 handle_request_invite: Unable to find subscription with call-id: c7a2a4957ae46e47

By: David Vossel (dvossel) 2010-05-27 12:50:17

ffossard, so does the updated Aastra firmware resolve the initial reported issue entirely for you when using 1.6.2?

By: Fossard Florent (ffossard) 2010-05-27 13:42:23

The new 2.6 firmware resolve the issue for me with Asterisk 1.6.2, it restores the old method with *8.

By: Gareth Blades (gblades_skymarket) 2010-05-28 03:54:19

Same here. I found with the previous Aastra release call pickup used to work if pedantic=yes was not set but I used to get lots of 'CSEQ out of order' warnings and setting it fixed this but broke the call pickup.

The new firmware fixes this problem and uses the 'directed call pickup prefix' option in the phone configuration file.

I an still running stock asterisk 1.6.2.6

By: Olivier Krief (okrief) 2010-05-28 04:41:12

It seems to me that 1.6.2 is supporting a new kind of PickUp, based on SIP Replace header while the previous one, based on casual INVITE and a specific Starcode sequence is still available.
Configuring ip phones not to use this new method is fine but, for instance, some soft or hard phones can't be easily tuned so it is still interesting to be able to support Directed PickUp only using Asterisk-side settings.

IMHO, having BLF-PickUp with the Aastra 2.53 firmware is or is not an interesting goal, depending on the reason why it fails : if 2.60 simply works around an Asterisk bug, then there is still a bug to solve.

By: Steve Davies (one47) 2010-05-28 04:51:47

As per my earlier note, IMHO this is a bug in the Aastra firmware. Even though Asterisk sends a correctly formed NOTIFY, if it is the long-format packet then the Aastra simply "disables" directed pickup on that button. If asterisk sends the old short-form NOTIFY, the Aastra uses the internally programmed prefix to do the pickup (*8xxx)

It appears that Aastra have fixed this in their 2.60 firmware. Sadly this does not help with users of their abandoned 9112i, 9133i and 480i phones.

I am not sure what Asterisk can be expected to do, except allow a per-device "regress to shorter notify packet" option in sip.conf.

By: David Vossel (dvossel) 2010-05-28 14:06:01

udosw, in regard to this comment, "Tried with the Thomson ST2030 phone:
With pedantic=yes, pickup always fails, either patched or unpatched * (1.6.2.6/1.6.2.7).
With pedantic=no: Pickup works OK, also with unpatched *. So it is a configuration issue with the ST2030, too. Should be fixed for pedantic=yes, though. What should I provide to help with that?"

Can you please provide sip debug of the pickup failing with "pedantic=yes" and a separate debug of the pickup passing with "pedantic=no" with the patched Asterisk.

By: Udo Schacht-Wiegand (udosw) 2010-06-01 16:37:07

Sorry, just lacking the time to do so. Hope I will be able to continue till next weekend.

By: David Vossel (dvossel) 2010-06-16 16:20:52

Since the reporter has confirmed that this issue is resolved for Aastra phones with the latest v2.6 fireware I am closing this issue.  During the conversation surrounding the original issue there appeared to possibly be other problems people were encountering with sip pickup.  If you have an issue related to this one, and it is not Aastra firmware related, please open a separate issue as we need to track that separately from this one.

By: Leif Madsen (lmadsen) 2010-10-13 16:33:36

Reopening this issue as a reminder for dvossel to merge the changes associated with this issue into 1.6.2.

By: Leif Madsen (lmadsen) 2010-10-13 16:34:00

Per the mailing list:



----- Original Message -----
> > From: "Stefan Tichy" <asterisk2@pi4tel.de>
> > To: asterisk-dev@lists.digium.com
> > Sent: Tuesday, October 12, 2010 1:34:36 PM
> > Subject: [asterisk-dev] Issue 17097 - Replaces pickup
> > Issue 17097 is closed, but the patch [1] mentioned in [2] seems to
> > be usefull. Without this patch pickups may fail and Asterisk responds
> > "SIP/2.0 481 Call Leg Does Not Exist (Replaces)"
> >
> > Setting "pedantic=no" will avoid this problem, but this will
> > cause others.
> >
> > Is it planed to apply this patch to Asterisk 1.6.2.x ?
> >
> >
> > 1)
> > https://issues.asterisk.org/file_download.php?file_id=26200&type=bug
> >
> > 2) https://issues.asterisk.org/view.php?id=17097#122399
> >
> >
> > --
> > Stefan Tichy ( asterisk2 at pi4tel dot de )
> >
It looks like this patch is in 1.8 and Trunk, but now 1.6.2.  I wrote the patch, and I can't remember why it was not included into 1.6.2.  Can you make an issue for that so I'll remember to investigate it?

By: David Vossel (dvossel) 2010-12-07 16:39:11.000-0600

This was eventually committed in 1.6.2.  The latest release should have it.