I’m working on directed call pickup and can correctly route the requisite feature code on the channel of the line trying to remote pickup to a context that tries to do a Pickup()/PickupChan(). It seems no matter what I try I get the following error:
In my specific scenario I have extension 104 call 103 and extension 110 attempts to do the pickup. The pickup/pickupchan command is called from 110’s channel.
These are some things I’ve tried. In an attempt to just get something to work I even just put in string literals:
exten => _**., n, Pickup(103)
exten => _**., n, Pickup(SIP/103)
exten => _**., n, Pickup(SIP/103@mydomain)
exten => _**., n, PickupChan(103)
exten => _**., n, PickupChan(SIP/103)
exten => _**., n, PickupChan(SIP/103@mydomain)
How can I better debug this? 104 and 103 are softphones, so I’m not sure if that has an impact, or if phones have to be provisioned in a specific way to be able to do Pickup()/PickupChan(). I haven’t provided many details because I’m uncertain what info would be helpful. I’ll add more as needed. Thanks in advance for any solutions.
Only the first example is valid, although you are also allowed to specify a context.
For PickupChan, assuming the bad practice of making sip.conf sections match extension names, you would need
SIP/103-xxxxxxx, where xxxxxxxx can only be found out at run time.
[quote]
centosCLI> core show application Pickup
centosCLI>
-= Info about application ‘Pickup’ =-
[Synopsis]
Directed Call Pickup
[Description]
Pickup([extension[@context][&extension2@[context]…]]): This application can
pickup any ringing channel that is calling the specified extension. If no
context is specified, the current context will be used. If you use the special
string “PICKUPMARK” for the context parameter, for example 10@PICKUPMARK,
this application tries to find a channel which has defined a ${PICKUPMARK}
channel variable with the same value as “extension” (in this example, “10”).
When no parameter is specified, the application will pickup a channel matching
the pickup group of the active channel.
centosCLI> core show application PickupChan
centosCLI>
-= Info about application ‘PickupChan’ =-
[Synopsis]
Pickup a ringing channel
[Description]
PickupChan(channel[&channel…]): This application can pickup any ringing chan
nel[/quote]
You mention the first example being valid. Since it’s valid but still fails, is there a good way to backtrace why? I’ve raised core set verbose and debug as high as they can reasonably be set (without drowning in noise) and am not seeing anything that explains why the target channel cannot be found for extension 103.
Secondly, as you indicate I have to pass the channel identified to PickupChan (SIP/103-xxxxxxxx), is there some way in the dialplan (maybe with HASH?) that I can look this up?
Thanks again David.
Probably the wrong context.
You would have to capture the channel name in a global variable.
Are you saying I’m calling Pickup in the wrong context?
You may need to explicitly specify a context.
Is there some setting somewhere in a .conf I have to turn on to enable this feature? Also, would it matter the phone I’m trying to intercept incoming call from is a soft phone?
Solved. What was happening was that I was doing Pickup() in a different context than where the incoming call was being handled. Because of this, I had to set PICKUPMARK where the incoming call was happening. I set it it to <sip_user>.<sip_domain>. However, if my feature codes context the match I was trying to get in Pickup was <extension #>.<sip_domain>. Since there was no match, no channel was picked up. So to solve this problem I just changed ${HASH(phone,sip_user)} to ${HASH(extension,number)} at the incoming call where PICKUPMARK was set.
One thing worth noting is that if I just tried to set PICKUPMARK to the extension number it failed. Every single time. The Pickup() application simply could not match to a channel if I just supplied with an extension. This is the reason why I had to postpend the sip_domain.