[Home]

Summary:ASTERISK-13665: Directed call pickup does not work using subscription based pickup
Reporter:Alec Davis (alecdavis)Labels:
Date Opened:2009-02-27 04:35:50.000-0600Date Closed:2010-08-12 16:28:26
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_directed_pickup
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) directed_pickup.debug.diff.txt
( 1) sip_debug_directed_pickup.txt
Description:Before upgrade from 1.6.0-rc6 to trunk. Directed pickup worked well.

Now we are getting:
[Feb 27 22:06:51] NOTICE[27187]: app_directed_pickup.c:255 pickup_exec: No target channel found for 8510.

After replacing pickup_by_exten with function from tag 1.6.0.6-rc6 I was able to find that the dialcontext and context were never going to match.

some debug below: with 1.6.0-rc6 version of pickup_by_exten

[Feb 27 22:39:20] NOTICE[1465]: app_directed_pickup.c:273 pickup_exec: context=BLF_Group_1.
[Feb 27 22:39:20] NOTICE[1465]: app_directed_pickup.c:217 pickup_by_exten: macroexten= exten=8510 dialcontext= context=BLF_Group_1 canpickup=1
[Feb 27 22:39:20] NOTICE[1465]: app_directed_pickup.c:217 pickup_by_exten: macroexten= exten=8510 dialcontext=trusted context=BLF_Group_1 canpickup=1
[Feb 27 22:39:20] NOTICE[1465]: app_directed_pickup.c:217 pickup_by_exten: macroexten=8510 exten=s dialcontext= context=BLF_Group_1 canpickup=0
[Feb 27 22:39:20] NOTICE[1465]: app_directed_pickup.c:282 pickup_exec: No target channel found for 8510.
 == Extension Changed 8520[BLF_Group_1] new state Idle for Notify User GXP0009 (queued)

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

The Grandstream's BLF button failed to find the target, dialling **8510 worked as previously

After replacing the dialcontext strcasecmp with strlen_zero, I was able to pickup the call again.

-         !strcasecmp(target->dialcontext, context) &&
+         !ast_strlen_zero(target->dialcontext) &&

This obviously isn't right, but as far as I can get tonight.

There is no dialplan being used for the call pickup as it appears to be done directly between asterisk and Grandstream GXP2000 FW 1.6.46 (downgraded to 1.6.37)

dialplan code when ** is being used for call pickup.

exten => _**85[0-5]X,1,NoOp(Directed call pickup)
exten => _**85[0-5]X,n,Pickup(${EXTEN:2}@incoming)   ;direct call pickup to local Asterisk
exten => _**85[0-5]X,n,Pickup(${EXTEN:2}@trusted)    ;direct call pickup to local Asterisk
exten => _**85[0-5]X,n,Pickup(${EXTEN:2}@default)    ;direct call pickup to local Asterisk
exten => _**85[0-5]X,n,Hangup()

Comments:By: Alec Davis (alecdavis) 2009-02-27 04:55:19.000-0600

WHILE IDLE
astrid*CLI> core show hints
astrid*CLI>
   -= Registered Asterisk Dial Plan Hints =-
...
                  8510@BLF_Group_1         : SIP/GXP0005           State:Idle            Watchers  6
...

WHEN RINGING
astrid*CLI> core show hints
astrid*CLI>
   -= Registered Asterisk Dial Plan Hints =-
...
            8510@BLF_Group_1         : SIP/GXP0005           State:Ringing         Watchers  6
...


astrid*CLI> sip show subscriptions
Peer             User        Call ID          Extension        Last state     Type            Mailbox    Expiry
....
192.168.x.121    GXP0005     9ce51e98d66bc96  8510@BLF_Group_  Idle           dialog-info+xml <none>     000060
192.168.x.121    GXP0005     dde65f99586c0c6  --               <none>         mwi             8510       000060
192.168.x.51     GXP0009     180af0adc9d4ca6  --               <none>         mwi             8519       000060
192.168.x.51     GXP0009     4d8d57b4c666a26  8510@BLF_Group_  Idle           dialog-info+xml <none>     000060
....
48 active SIP subscriptions

8530 ringing 8510(GXP0005)
astrid*CLI> sip show inuse
* Peer name               In use          Limit
....
8530                      1/0/0           10
....
GXP0005                   1/1/0           10
....
By: Alec Davis (alecdavis) 2009-02-27 19:12:25.000-0600

After reverting back to 1.6.0-rc6 the directed pickup works as before.
Dialplan code hasn't changed, same phones, same FW in phones.

The dialplan does attempt 3 pickups from 3 contexts, succeeds on the 2nd.
Notice the Grandstream phone now sends **8510 to do the pickup.
Whereas with trunk it directly communicates with Asterisk, asterisk will use do_magic_pickup to try to pickup the 8510 'Hint' in the context 'BLF_Group_1'. There's a clue there!

   -- Executing [**8510@trusted:1] NoOp("SIP/GXP0009-b779be80", "Directed call pickup") in new stack
   -- Executing [**8510@trusted:2] Pickup("SIP/GXP0009-b779be80", "8510@incoming") in new stack
[Feb 28 13:58:30] NOTICE[18209]: app_directed_pickup.c:152 pickup_exec: No target channel found for 8510.
   -- Executing [**8510@trusted:3] Pickup("SIP/GXP0009-b779be80", "8510@trusted") in new stack
   -- SIP/GXP0009-b779be80 answered SIP/8530-b7766420
 == Extension Changed 8510[BLF_Group_1] new state Idle for Notify User GXP0002
   -- Executing [**8510@trusted:4] Pickup("SIP/GXP0005-b778ed10<ZOMBIE>", "8510@default") in new stack
[Feb 28 13:58:30] NOTICE[18209]: app_directed_pickup.c:152 pickup_exec: No target channel found for 8510.
   -- Native bridging SIP/8530-b7766420 and SIP/GXP0009-b779be80


By: Alec Davis (alecdavis) 2009-02-27 20:11:03.000-0600

With 'SVN-trunk-r178446M', subscribecontext=BLF_Group_1 was the culprit, removing it throughout sip.conf fixed only internal sip-sip calls, but calls coming in from the ISDN PSTN are from the 'incoming' context, and thus directed pickup still fails.

Shouldn't it also work with the 'subscribecontext' defined in sip.conf?

Below snippet of file sip.conf
...
[GXP0009]
context=trusted
type=friend
host=dynamic
secret=xxxxxxxxxxxxx
disallow=all
allow=alaw
allow=ulaw
allow=gsm
;subscribecontext=BLF_Group_1
mailbox=8519
call-limit=10
pickupgroup=1
callgroup=1

[GXP0005]
context=trusted
type=friend
host=dynamic
secret=xxxxxxxxxxxxx
disallow=all
allow=alaw
allow=ulaw
allow=gsm
;subscribecontext=BLF_Group_1
mailbox=8510
call-limit=10
pickupgroup=1
callgroup=1
....


By: Alec Davis (alecdavis) 2009-02-28 15:19:33.000-0600

Please change subject to:
"do_magic_pickup fails to find target extension when not in same context"

It is a fundamental requirement if a call comes in from the [incoming] context, namely from Dahdi hardware in our case E1 cards, that a user be able to pick it up from a local sip phone which is in the 'trusted' context.

The workaround below is messy: (or is it elegant? I don't like it right now)

In the [incoming] context, use a goto(trusted,${EXTEN},1) this will change the context to 'trusted', which is the context of all the internal sip phones.

Make sure all the hints also subscribe to the same context as the internal phones, 'trusted' in our case, set with subscribecontext=trusted in sip.conf.


By: Alec Davis (alecdavis) 2009-02-28 15:35:43.000-0600

In additional information section above, please change the following:
"Both the direct BLF button, and entering **8510 failed to find the target"

to:
"The Grandstream's BLF button failed to find the target, dialling **8510 worked as previously"
By: Joshua C. Colp (jcolp) 2009-03-02 08:19:28.000-0600

This all really makes no sense... subscribecontext is only used when a subscription comes in. I've looked at the code and confirmed it. The only reason I can think of is if the Grandstream sends the call using the same dialog as the subscription, thus the context is set to subscribecontext. Can you please upload *complete* console output of the incoming call and then attempt to pick it up. A sip debug is also needed to see what the Grandstream is doing. Thanks.
By: Alec Davis (alecdavis) 2009-03-02 13:00:07.000-0600

I'll try to simplify this. No SIP, No Grandstream

1x TDM400P
1x FXO, context = incoming
2x FXS, context = trusted, extensions 501 and 502

incoming call from FXO starts in context 'incoming', asterisk rings 501 in context 'trusted'.

502 wants to pickup 501 so dials **501

dialplan code:
exten => _**50X,1,NoOp(Directed call pickup)
exten => _**50X,n,Pickup(${EXTEN:2}@trusted) ;direct call pickup to internal ringing phone

Feb 27 22:06:51] NOTICE[27187]: app_directed_pickup.c:255 pickup_exec: No target channel found for 501

summary:
It seems like app_directed_pickup needs to attempt to pickup the call of ringing extension's context, not the context of the originating call.

dialplan code workaround:
exten => _**50X,1,NoOp(Directed call pickup)
exten => _**50X,n,Pickup(${EXTEN:2}@trusted) ;direct call pickup to internally ringing phone
exten => _**50X,n,Pickup(${EXTEN:2}@incoming) ;direct call pickup to calls from FXOs

I will attempt sip capture tonight when system not busy.


By: Alec Davis (alecdavis) 2009-03-02 13:54:22.000-0600

The grandstream was using subscribeconext to pickup the call. In our case the subscribecontext was BLF_Group_1.

debug output from patched app_directed_pickup.c:
app_directed_pickup.c:217 pickup_by_exten: macroexten= exten=8510 dialcontext=trusted context=BLF_Group_1 canpickup=1

Removing subscribecontext from sip.conf allowed internal calls withing the same context to be picked up, but calls started from a different context IE. 'incoming' and ringing a phone in the same context 'trusted' as the phone that wants to pickup to ringing extension will fail.
By: Joshua C. Colp (jcolp) 2009-03-02 13:59:42.000-0600

You have "trutsed" in your example, but anyway I would really like to see the console output and exact dialplan includin contexts. Giving me bits like above only complicates things.

As for your statement about how it should pick up the ringing extension's context... a phone isn't associated with a context when it is dialed. Things have no idea of the context they are dialed from, or should be dialed from. The directed pickup call code works by using the extension that triggered the Dial().
By: Alec Davis (alecdavis) 2009-03-02 17:41:41.000-0600

sip_debug_directed_pickup.txt as requested

dialplan code that was executed:
exten => 8522,1,Dial(SIP/8522,,r)

extensions.conf
...
[trusted]
include => phones
include => bdt-extensions
include => outside-line

exten => _85[0-5]X,1,NoOp(context=${CONTEXT})
exten => _85[0-5]X,n,Macro(procexten,${EXTEN})

[incoming]
include => phones
include => bdt-extensions

[outside-line]
exten => _1.,1,Macro(dialout,${TRUNK},${EXTEN:1})               ;outside line

[bdt-extensions]
exten => _4XXX,1,Macro(dialout,${TRUNK},${EXTEN})
exten => _5XXX,1,Macro(dialout,${TRUNK},${EXTEN})
exten => _68XX,1,Macro(dialout,${TRUNK},${EXTEN})
exten => _83XX,1,Macro(dialout,${TRUNK},${EXTEN})
exten => _86XX,1,Macro(dialout,${TRUNK},${EXTEN})
exten => _88XX,1,Macro(dialout,${TRUNK},${EXTEN})

[phones]
exten => 8522,1,Dial(SIP/8522,,r)
exten => _85[0-5]X,1,NoOp(context=${CONTEXT})
exten => _85[0-5]X,n,Macro(procexten,${EXTEN})

exten => _**85[0-5]X,1,NoOp(Directed call pickup)
exten => _**85[0-5]X,n,Pickup(${EXTEN:2}@incoming)   ;direct call pickup to local Asterisk
exten => _**85[0-5]X,n,Pickup(${EXTEN:2}@trusted)    ;direct call pickup to local Asterisk
exten => _**85[0-5]X,n,Pickup(${EXTEN:2}@default)    ;direct call pickup to local Asterisk
exten => _**85[0-5]X,n,Hangup()

...
By: Alec Davis (alecdavis) 2009-03-03 16:11:21.000-0600

Is there anyway of configuring asterisk to tell the phones to not use subscription based call picked? Like they didn't in earlier 1.6.0-rc6 release.

Any chance of pointing me to where the changes were, that changed the phone's method of directed call picked, so we can work on a patch to make them compatible.

If a fix may be close, please let me know.
By: Joshua C. Colp (jcolp) 2009-03-04 08:53:49.000-0600

There is no way I'm afraid right now and I haven't yet found a solution.
By: Digium Subversion (svnbot) 2009-03-04 11:29:51.000-0600

Repository: asterisk
Revision: 180158

_U  branches/1.6.0/

------------------------------------------------------------------------
r180158 | mmichelson | 2009-03-04 11:29:51 -0600 (Wed, 04 Mar 2009) | 20 lines

Blocked revisions 180155 via svnmerge

........
 r180155 | mmichelson | 2009-03-04 11:03:32 -0600 (Wed, 04 Mar 2009) | 14 lines
 
 Allow for "magic" pickups to work when we wish to ignore the context
 
 When the subscription context for a call pickup subscription differs
 from the context of the call pickup target, there's not an easy way
 to divine what context should be used for the pickup. The way to work
 around this is to use PICKUPMARK as the context for the pickup.
 
 This has been documented in the sip.conf.sample file
 
 (ABE-1708)
 
 closes issue ASTERISK-13665
 submitted by: alecdavis
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=180158
By: Digium Subversion (svnbot) 2009-03-04 11:30:23.000-0600

Repository: asterisk
Revision: 180187

_U  branches/1.6.1/

------------------------------------------------------------------------
r180187 | mmichelson | 2009-03-04 11:30:23 -0600 (Wed, 04 Mar 2009) | 20 lines

Blocked revisions 180155 via svnmerge

........
 r180155 | mmichelson | 2009-03-04 11:03:32 -0600 (Wed, 04 Mar 2009) | 14 lines
 
 Allow for "magic" pickups to work when we wish to ignore the context
 
 When the subscription context for a call pickup subscription differs
 from the context of the call pickup target, there's not an easy way
 to divine what context should be used for the pickup. The way to work
 around this is to use PICKUPMARK as the context for the pickup.
 
 This has been documented in the sip.conf.sample file
 
 (ABE-1708)
 
 closes issue ASTERISK-13665
 submitted by: alecdavis
........

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

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