Dialing with U gosub option

Hi All!

Asterisk 18.6, when dialing like this, with the intention of running a gosub on the answering PJSIP channel:

exten => 100,1,Dial(Local/100@test)
[test]
exten => 100,1,Dial(PJSIP/somepeer,,U(mygosub,s,1))
[mygosub]
exten => s,1,NoOp( ${CHANNEL} )

In this case, ${CHANNEL} is the Local channel, the docs say:

Execute via Gosub the routine x for the called channel before connecting to the calling channel

Am I missing something? Shouldn’t I get the PJSIP channel in mygosub?

Thanks for any insight!

Bill

You are missing the timeout, or a placeholder for it.

Thanks, type-o in my post, fixed, but same issue, always getting the Local channel in the subroutine vs the PJSIP channel.

Ultimately, what I’m trying to accomplish here is to attach a hangup handler to the PJSIP channel that answered the call from a Queue, using a subroutine, where the Queue member is a Local channel that dials a PJSIP channel.

Nothing I’ve tried has worked, the hangup handler always ends up on the Local channel and runs when the local channel optimizes out. I don’t want to keep the local channel up, I need it to go away (another requirement).

I’ve tried the queue gosub options (both with Queue() and in queues.conf, and the various b, B, and U dial options.

Thanks for any advice!

I’d show actual console output with this.

Here you go … this is using the queue.conf gosub option to the ‘agent’ subroutine:

exten => 100,1,Dial(Local/7810@experiment)
[experiment]
exten => 7810,1,Dial(PJSIP/test.7810)
[agent]
exten => s,1,NoOp( *** CHANNEL:${CHANNEL} *** )

-- Executing [200@context:7] Queue("PJSIP/carrier-0000010f", "queue,tTxIik,,,90") in new stack
-- Called Local/7810@experiment
-- Executing [7810@experiment:1] Dial("Local/7810@experiment-00000154;2", "PJSIP/test.7810/sip:test.7810@192.168.1.184:5060,,riexktw") in new stack
-- Called PJSIP/test.7810/sip:test.7810@192.168.1.184:5060
-- Local/7810@experiment-00000154;1 is ringing
-- PJSIP/test.7810-00000110 connected line has changed. Saving it until answer for Local/7810@experiment-00000154;2
-- PJSIP/test.7810-00000110 is ringing
-- Local/7810@experiment-00000154;1 is ringing
-- PJSIP/test.7810-00000110 answered Local/7810@experiment-00000154;2
-- Connected line update to PJSIP/carrier-0000010f prevented.
-- Local/7810@experiment-00000154;1 answered PJSIP/carrier-0000010f
-- Channel PJSIP/test.7810-00000110 joined 'simple_bridge' basic-bridge <7beb66b2-5bc9-4c92-b856-a1cb8e94257c>
-- Local/7810@experiment-00000154;1 Internal Gosub(agent,s,1) start
-- Channel Local/7810@experiment-00000154;2 joined 'simple_bridge' basic-bridge <7beb66b2-5bc9-4c92-b856-a1cb8e94257c>
-- Executing [s@agent:1] NoOp("Local/7810@experiment-00000154;1", " *** CHANNEL:Local/7810@experiment-00000154;1 *** ") in new stack

The execution doesn’t match your dialplan:

-- Executing [7810@experiment:1] Dial("Local/7810@experiment-00000154;2", "PJSIP/test.7810/sip:test.7810@192.168.1.184:5060,,riexktw") in new stack

That’s not equivalent to your given dialplan.

Sorry, I went back and was editing for clarity when you replied … got copy/paste happy :smiley:

Still not equivalent to the dialplan you’ve provided. The Dial() line has no ‘U’ option to it according to the log. It has other ones, riexktw.

You are correct! I’m using the queue.conf membergosub option here, but same result if I use Dial’s “U(agent,s,1)” option. Edited again. Thanks for putting up with me (and for any insight), been running this one around the block all day.

If using the Queue option, then it will execute on the dialed channel which is the Local channel ;1 leg. That is correct, and what should happen. You’re not directly dialing the PJSIP channel, the Queue has no idea that is what was dialed until everything bridges and any optimization occurs.

Yep, working up the Dial with U example now, be right back!

(falling on sword)

It’s working. We’re doing a lot of local channel work mixed in here and there’s so much CLI output I completely missed the U option working amid all my attempts. That, plus a type-o in an ExecIf I just found.

Thanks for taking the time @jcolp … I’m sure you have better things to do … :frowning: