[Home]

Summary:ASTERISK-09215: Directed Pickup won't grab group calls - no target channel found
Reporter:James Brindle (jamesb63)Labels:
Date Opened:2007-04-06 09:26:16Date Closed:2011-06-07 14:10:47
Priority:TrivialRegression?No
Status:Closed/CompleteComponents:Applications/app_directed_pickup
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:If A directly calls C, B can execute Pickup(C) and it works successfully

If, however, A calls a number which calls a group of extensions (eg C, D and E), B cannot pickup any of the ringing extensions

This was found because my setup involves a call targeting handsets in my office room at home but I don't want them ringing say in the bedroom across the hall but I want to be able to pick up the call remotely.

Normal pickup does work though.




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

[sip.conf]

[general]
context = incoming
register 123456:password@provider.url/8001

[a sip phone]
context = internal

[extensions.conf]

[incoming]
8001,1,Dial(SIP/1000&SIP/1001&SIP/1002,30,tT)
8001,2,Voicemail stuff

[internal]
include => pickup
... stuff to call extensions ...

[pickup]
exten => _**XXXX,1,Pickup(${EXTEN}:2)
exten => _**XXXX,2,HangUp()

Comments:By: James Brindle (jamesb63) 2007-04-06 11:22:42

Also, this doesn't work if someone places a call into your Asterisk server over IAX2 - ie Asterisk server to Asterisk server.
By: dimitripietro (dimitripietro) 2007-04-07 11:50:43

Try to pickup 8001 it should be working. It is working in 1.2.17
By: Tilghman Lesher (tilghman) 2007-04-07 18:11:45

Wrong syntax.  That should have been ${EXTEN:2}
By: Joshua C. Colp (jcolp) 2007-04-08 12:19:50

I need to see the console output plus the actual dialplan logic (check Corydon's comment to make sure your dialplan is correct).
By: Eric Davis (ericwaynedavis) 2007-05-07 18:52:17

I observed the same problem. The inbound call is to extension 3974 on box A from another Asterisk box (B) using a SIP trunk.

The console output is as follows:

*CLI>
   -- Executing [3974@incoming:1] Macro("SIP/s-af7b5ef0", "stdexten|3974|sip/3974") in new stack
   -- Executing [s@macro-stdexten:1] Dial("SIP/s-af7b5ef0", "sip/3974|20") in new stack
   -- Called 3974
   -- SIP/3974-0cbf6858 is ringing
   -- Executing [*73974@default:1] Pickup("SIP/3993-af1d5028", "3974@default") in new stack
[May  7 19:49:24] NOTICE[4135]: app_directed_pickup.c:159 pickup_exec: No target channel found for 3974.
 == Auto fallthrough, channel 'SIP/3993-af1d5028' status is 'UNKNOWN'
 == Spawn extension (macro-stdexten, s, 1) exited non-zero on 'SIP/s-af7b5ef0' in macro 'stdexten'
 == Spawn extension (macro-stdexten, s, 1) exited non-zero on 'SIP/s-af7b5ef0'


The relevant portions of extensions.conf are:
; Directed call pickup - *7<extension>
exten => _*7.,1,Pickup(${EXTEN:2}@default)


By: Eric Davis (ericwaynedavis) 2007-06-03 12:48:47

Any news on this problem?
By: Joshua C. Colp (jcolp) 2007-06-04 12:33:14

I've tried to reproduce this tons of different ways but have failed. I need to see the rest of your dialplan logic as well, the part that actually places the phone calls to the phone.
By: Eric Davis (ericwaynedavis) 2007-06-06 07:55:42

OK. Here is what I have.

1) 'hfb-gw' (192.168.1.6) is an Asterisk box with a PRI interface to the PSTN and connection to a private LAN on eth0.

It's sole purpose is inter-working between SIP and TDM.
2) 'hfb-ops-pri' (192.168.1.2) is an Asterisk box with SIP phones connected to   eth0 and the same private LAN as 'hfb-

gw' on eth1.
3) Here are the relevant sections of sip.conf on each node:

3.1) 'hfb-gw' sip.conf:

register => hfb-ops-gw:password@192.168.1.2

[hfb-ops-vip]
type=friend
secret=password
host=dynamic
canreinvite=no
insecure=port,invite
qualify=yes
context=default

3.2) 'hfb-ops-pri' sip.conf:

register => hfb-ops-vip:password@192.168.1.6

[hfb-ops-gw]
type=friend
secret=password
host=dynamic
canreinvite=no
insecure=port,invite
qualify=yes
context=incoming

4) Here are the relevant sections of extensions.conf on each node:

4.1) 'hfb-gw' extensions.conf:

[incoming]
include => default

[default]
ignorepat => 9
include => trunklocal
include => trunkld
include => trunktollfree
include => trunkint
include => hfb-ops-vip

[hfb-ops-vip]
exten => _XXXX,1,Dial(sip/hfb-ops-vip/${EXTEN})


4.2) 'hfb-ops-pri' extensions.conf:

[incoming]
include => default

[default]
exten => 3993,1,Macro(stdexten,3993,sip/3993)
exten => 3993,hint,SIP/3993
exten => 3996,1,Macro(stdexten,3996,sip/3996)
exten => 3996,hint,SIP/3996


; Directed call pickup - *7<extension>
exten => _*7.,1,Pickup(${EXTEN:2}@default)


[macro-stdexten];
;
; Standard extension macro:
;   ${ARG1} - Extension  (we could have used ${MACRO_EXTEN} here as well
;   ${ARG2} - Device(s) to ring
;
exten => s,1,Dial(${ARG2},20)                   ; Ring the interface, 20 seconds maximum
exten => s,2,Goto(s-${DIALSTATUS},1)            ; Jump based on status (NOANSWER,BUSY,CHANUNAVAIL,CONGESTION,ANSWER)
exten => s-NOANSWER,1,Voicemail(${ARG1},u)      ; If unavailable, send to voicemail w/ unavail announce
exten => s-BUSY,1,Voicemail(${ARG1},b)          ; If busy, send to voicemail w/ busy announce
exten => _s-.,1,Goto(s-NOANSWER,1)              ; Treat anything else as no answer
exten => a,1,VoicemailMain(${ARG1})             ; If they press *, send the user into VoicemailMain

5) Synopsis:

If I place a call from the outside world to the number that rings in over my PRI to extension 3996, the 'hfb-gw' box

correctly signals the 'hfb-ops-pri' box and extension 3996 rings. If I then attempt to perform a directed pickup (i.e.

*73996) from extension 3993 (also in the default context) on 'hfb-ops-pri', I get the "NOTICE[4135]:

app_directed_pickup.c:159 pickup_exec: No target channel found for 3996." error message. Note that I'm using different

extensions than in my previous post and I'm simulating the call from the outside by using the 'dial 3996' command on the

console at 'hfb-gw'.

6) 'hfb-gw' console output:


�[Khfb-ops-gw*CLI> dial 3996hfb-ops-gw*CLI>
   -- Executing [3996@default:1] �[1;36;40mDial�[0;37;40m("�

[1;35;40mOSS/dsp�[0;37;40m", "�[1;35;40msip/hfb-ops-vip/3996�[0;37;40m") in new stack

�[Khfb-ops-gw*CLI>
   -- Called hfb-ops-vip/3996

�[Khfb-ops-gw*CLI>
   -- SIP/hfb-ops-vip-08481678 is ringing

�[Khfb-ops-gw*CLI> hanguphfb-ops-gw*CLI>
 == Spawn extension (default, 3996, 1) exited non-zero on 'OSS/dsp'
 << Hangup on console >>

7) 'hfb-ops-pri' console output:


�[Khfb-ops-pri*CLI>
   -- Executing [3996@incoming:1] �[1;36;40mMacro�[0;37;40m("�[1;35;40mSIP/s-0a1964a8�[0;37;40m", "�

[1;35;40mstdexten|3996|sip/3996�[0;37;40m") in new stack

�[Khfb-ops-pri*CLI>
   -- Executing [s@macro-stdexten:1] �[1;36;40mDial�[0;37;40m("�[1;35;40mSIP/s-0a1964a8�[0;37;40m",

"�[1;35;40msip/3996|20�[0;37;40m") in new stack

�[Khfb-ops-pri*CLI>
   -- Called 3996

�[Khfb-ops-pri*CLI>
   -- SIP/3996-0a18e018 is ringing

�[Khfb-ops-pri*CLI>
Extension Changed 3993 new state InUse for Notify User 3993
    -- Executing [*73996@default:1] �[1;36;40mPickup�[0;37;40m("�[1;35;40mSIP/3993-0a28ebd0�[0;37;40m", "�

[1;35;40m3996@default�[0;37;40m") in new stack
[Jun  6 08:46:37] �[1;33;40mNOTICE�[0;37;40m[8383]: �[1;37;40mapp_directed_pickup.c�[0;37;40m:�[1;37;40m159�[0;37;40m �

[1;37;40mpickup_exec�[0;37;40m:  No target channel found for 3996.
  == Auto fallthrough, channel 'SIP/3993-0a28ebd0' status is 'UNKNOWN'
 Extension Changed 3993 new state Idle for Notify User 3993

�[Khfb-ops-pri*CLI>
 == Spawn extension (macro-stdexten, s, 1) exited non-zero on 'SIP/s-0a1964a8' in macro 'stdexten'
  == Spawn extension (macro-stdexten, s, 1) exited non-zero on 'SIP/s-0a1964a8'
By: Joshua C. Colp (jcolp) 2007-06-06 08:17:15

Please try 1.4 as of revision 67626.
By: Eric Davis (ericwaynedavis) 2007-06-06 20:46:15

I tried using SVN-branch-1.4-r67941M and the problem is still there.
By: Joshua C. Colp (jcolp) 2007-06-07 12:04:37

Your Macro call is not being executed from within default, it is being executed from within incoming. Change your pickup line to be @incoming and I bet it will work.
By: Eric Davis (ericwaynedavis) 2007-06-07 13:12:26

You're right! I'm really sorry for the trouble.
By: Joshua C. Colp (jcolp) 2007-06-07 13:14:59

Since the reporter did not reply back any and the one remaining issue from someone else seemed to be a configuration issue I'm closing this out.
By: James Brindle (jamesb63) 2007-07-14 06:58:57

Sorry I didn't get back to everybody on this, i've been away for quite a while and haven't been able to participate.

In current version of SVN r75108M, app_directed_pickup still fails normally.

I did some digging around to ensure I had the right configuration etc and found a note on voip-info by Roberto at:
http://www.voip-info.org/wiki/view/Asterisk+cmd+Pickup

Which talked about a problem in the logic of the can_pickup() function

I've modified his example accordingly to the current source, compiled it and it works IF you include a context in the Pickup() command.

Here is the patch:

---- CUT ----
Index: app_directed_pickup.c
===================================================================
--- app_directed_pickup.c       (revision 75159)
+++ app_directed_pickup.c       (working copy)
@@ -83,7 +83,8 @@
/* Helper function that determines whether a channel is capable of being picked up */
static int can_pickup(struct ast_channel *chan)
{
-       if (!chan->pbx && (chan->_state == AST_STATE_RINGING || chan->_state == AST_STATE_RING))
+       //if (!chan->pbx && (chan->_state == AST_STATE_RINGING || chan->_state == AST_STATE_RING))
+        if (chan && (!chan->pbx))
               return 1;
       else
               return 0;
---- CUT ----

The pickup context in my AEL config now looks like:

context pickup {
 _**[1-468]. => {
   Pickup(${EXTEN:2}@internal_all);
   HangUp();
 };
}

"internal_all" being the context in which a person to person dialed call places itself, however, the pseudo-context "PICKUPMARK" does not work and just produces the ubiquitous "no target channel" error.

So, partial problem solved (or at least I think).

If I call a DID which lands in a different context, I can't direct pickup the ringing extension still though - D'OH!
By: Joshua C. Colp (jcolp) 2007-07-16 07:30:52

The code that confirms a channel is able to be picked up is correct, instead of changing it to not even check the state of the channel I would be more curious to see the console output and the state of the channel it skipped.

As for PICKUPMARK where are you setting this variable? If it's on the calling channel then that is incorrect, unless you set it to inherit. The other choice would be to use setvar in sip.conf when calling the peer.
By: James Brindle (jamesb63) 2007-07-16 08:02:40

With regards to PICKUPMARK, I found it noted here:
http://www.voip-info.org/wiki/view/Asterisk+cmd+Pickup&view_comment_id=14172

I can revert the code (I only commented out the original line) in can_pickup() and do a debug log, please let me know exactly what output you want and i'll be happy to assist.

The code change was taken from the URL I posted in my previous comment, if I use the current HEAD code, with or without a context, the channel will not pick up.  If I use the modified code, I can pick up a channel that is ringing so long as I use the context - I can also detect the state correctly in a macro and provide a useful message if there is no channel to pickup.
By: Joshua C. Colp (jcolp) 2007-07-18 11:41:24

I just need to see the value of chan->_state... and as well you didn't clarify how you are setting PICKUPMARK.
By: James Brindle (jamesb63) 2007-07-19 02:55:50

I'm not actually setting PICKUPMARK anywhere, as I stated, it was found in the documentation on voip-info which implied that you can use PICKUPMARK as a special context so by specifying:

Pickup(${EXTEN}:2@PICKUPMARK);

PICKUPMARK would internally (within app_directed_pickup.c) find an extension with name ${EXTEN:2} in some context which was currently ringing.

Maybe the documentation is misleading on voip-info - take a look at the link, I can only interpret what's printed.

As for chan->_state, I will put an ast_log() call in my version of app_directed_pickup.c and feed you the result.

Please let me know if you need anything different/more.

Thanks.
By: pkempgen (pkempgen) 2007-07-19 06:36:22

> PICKUPMARK would internally (within app_directed_pickup.c) find an extension
> with name ${EXTEN:2} in some context which was currently ringing.

pickup_by_mark() tries to find a channel where the channel variable
PICKUPMARK has the same content as passed to Pickup(<val>@PICKUPMARK)
By: Joshua C. Colp (jcolp) 2007-08-07 10:10:11

I'm suspending this since there has been no response and PICKUPMARK was being used incorrectly. If there is still an issue, please reopen.