[asterisk-bugs] [Asterisk 0014567]: Directed call pickup does not work using subscription based pickup

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14567 
====================================================================== 
Reported By:                alecdavis
Assigned To:                mmichelson
====================================================================== 
Project:                    Asterisk
Issue ID:                   14567
Category:                   Applications/app_directed_pickup
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!): 178446 
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-02-27 04:35 CST
Last Modified:              2009-03-04 11:30 CST
====================================================================== 
Summary:                    Directed call pickup does not work using
subscription based pickup
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)
====================================================================== 

---------------------------------------------------------------------- 
 (0101201) svnbot (reporter) - 2009-03-04 11:30
 http://bugs.digium.com/view.php?id=14567#c101201 
---------------------------------------------------------------------- 
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 http://bugs.digium.com/view.php?id=14567
  submitted by: alecdavis
........

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

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-04 11:30 svnbot         Checkin                                      
2009-03-04 11:30 svnbot         Note Added: 0101201                          
======================================================================