Parallel Dial Problem (used To Work On Asterisk 13)
Hi,
We have instances where we dial multiple destinations simultaneously and then an answer ‘macro’ prompts the callee to press 1 to accept the call or 3 to reject.
Previously if they pressed 3 (or just hung up) the other destinations would continue to ring.
Now on Asterisk 18.13.0, the first person to answer and reject the call causes Asterisk to stop ringing the other destinations, with PJSIP
sending a CANCEL with the following headers:
Reason: SIP;cause=200;text=”Call completed elsewhere”
Reason: Q.850;cause=26
I’ve created a simplified test dialplan to illustrate the issue; calls come in to the test context. Phone numbers and endpoints anonymised:
–8<------------------------------------------------------------------
[test]
exten => _X.,1,Dial(Local/12345678@test_dodial&Local/87654321@test_dodial,20,g)
same => n,NoOp(########## HANGUPCAUSE=${HANGUPCAUSE}, DIALSTATUS=${DIALSTATUS})
[test_dodial]
exten => _X.,1,NoOp(Dialling ${EXTEN})
same => n,Dial(PJSIP/provider/sip:${EXTEN}@endpoint:5060,,U(macro-testanswer^${EXTEN})g)
same => n,NoOp(ENDED ${EXTEN})
[macro-testanswer]
exten => s,1,NoOp(ANSWERING ${ARG1})
same => n,GotoIf($[“${ARG1}”!=”12345678″]?end_macro)
same => n,Set(MACRO_RESULT=CONGESTION)
same => n,Hangup(21)
same => n(end_macro),Return()
–8<------------------------------------------------------------------
Both numbers ring at once, but if 12345678 answers my test treats that as the callee rejecting the call. What should happen is that 87654321
should continue to ring, but it doesn't.
What comes up in the Asterisk console is this:
--8<------------------------------------------------------------------
-- PJSIP/provider-00000004 answered Local/12345678@test_dodial-00000002;2
-- PJSIP/provider-00000004 Internal Gosub(macro-testanswer,s,1(12345678)) start
-- Executing [s@macro-testanswer:1] NoOp("PJSIP/provider-00000004", "ANSWERING 12345678") in new stack
-- Executing [s@macro-testanswer:2] GotoIf("PJSIP/provider-00000004", "0?end_macro") in new stack
-- Executing [s@macro-testanswer:3] Set("PJSIP/provider-00000004", "MACRO_RESULT=CONGESTION") in new stack
-- Executing [s@macro-testanswer:4] Hangup("PJSIP/provider-00000004", "21") in new stack
== Spawn extension (macro-testanswer, s, 4) exited non-zero on 'PJSIP/provider-00000004'
[Jul 28 14:30:38] NOTICE[31819][C-00000002]: app_stack.c:1079 gosub_run: PJSIP/provider-00000004 Abnormal 'Gosub(macro-testanswer,s,1(12345678))' exit. Popping routine return locations.
-- Local/12345678@test_dodial-00000002;1 answered PJSIP/squiresvi-00000003
-- Channel PJSIP/provider-00000004 joined 'simple_bridge' basic-bridge <8db6d4f7-dac2-4f6e-840a-eaa557f1769a>
— Channel PJSIP/provider-00000004 left ‘simple_bridge’ basic-bridge <8db6d4f7-dac2-4f6e-840a-eaa557f1769a>
== Spawn extension (test_dodial, 447919554754, 2) exited non-zero on ‘Local/447919554754@test_dodial-00000003;2’
— Executing [12345678@test_dodial:3] NoOp(“Local/12345678@test_dodial-00000002;2”, “ENDED 12345678”) in new stack
— Auto fallthrough, channel ‘Local/12345678@test_dodial-00000002;2’ status is ‘ANSWER’
— Channel Local/12345678@test_dodial-00000002;1 joined ‘simple_bridge’ basic-bridge <4e7cdff8-3fc6-412e-b11f-ffd95ca75960>
— Channel Local/12345678@test_dodial-00000002;1 left ‘simple_bridge’ basic-bridge <4e7cdff8-3fc6-412e-b11f-ffd95ca75960>
— Executing [01476292508@test:2] NoOp(“PJSIP/squiresvi-00000003”, “########## HANGUPCAUSE=21, DIALSTATUS=ANSWER”) in new stack
— Auto fallthrough, channel ‘PJSIP/squiresvi-00000003’ status is ‘ANSWER’
–8<------------------------------------------------------------------
I also note that the NoOp at the end of [test_dodial] doesn't get executed.
Any idea how I can fix this?
Cheers, Kingsley.
--
2 thoughts on - Parallel Dial Problem (used To Work On Asterisk 13)
I haven’t tested it, but you’re calling it a macro when it’s not. You’re invoking a subroutine. As a result MACRO_RESULT won’t do anything, it should be GOSUB_RESULT. You also shouldn’t call Hangup in there.
Thanks. The macro name is a hangover from Asterisk 13 but changing MACRO_RESULT to GOSUB_RESULT fixed it – thanks!
Cheers, Kingsley.
—