Group Calls Over Trunk Answered Prematurely

Asterisk Asterisk SIP
1

I have two asterisk-18.18 servers and I am trying group call over the trunk.

exten => 200,1,Dial(PJSIP/1000@trunk&PJSIP/2000@trunk&PJSIP/3000@trunk)

When I dial the the extension only one of the extension are called. Usually at random. The verbose log are as follows.

    -- Remote UNIX connection
    -- Remote UNIX connection disconnected
    -- Remote UNIX connection
    -- Remote UNIX connection disconnected
    -- Executing [200@phones:1] Answer("PJSIP/6600-0000003f", "")
       > 0x7fce78017b90 -- Strict RTP learning after remote address set to: 10.0.0.250:4000
    -- Executing [200@phones:1] Dial("PJSIP/6600-0000003f", "PJSIP/1000@trunk&PJSIP/2000@trunk&PJSIP/3000@trunk,,g")
       > 0x7fce78017b90 -- Strict RTP learning after remote address set to: 10.0.0.250:4000
    -- Called PJSIP/1000@trunk
    -- Called PJSIP/2000@trunk
    -- Called PJSIP/3000@trunk
       > 0x7fce78017b90 -- Strict RTP switching to RTP target address 10.0.0.250:4000 as source
    -- PJSIP/trunk-00000042 connected line has changed. Saving it until answer for PJSIP/6600-0000003f
    -- PJSIP/trunk-00000041 connected line has changed. Saving it until answer for PJSIP/6600-0000003f
    -- PJSIP/trunk-00000040 connected line has changed. Saving it until answer for PJSIP/6600-0000003f
       > 0x7fce780439e0 -- Strict RTP learning after remote address set to: 10.0.0.6:19790
    -- PJSIP/trunk-00000040 answered PJSIP/6600-0000003f
    -- Channel PJSIP/trunk-00000040 joined 'simple_bridge' basic-bridge <af7465c8-eb6b-4ad2-b591-7b7fa05eaa9a>
    -- Channel PJSIP/6600-0000003f joined 'simple_bridge' basic-bridge <af7465c8-eb6b-4ad2-b591-7b7fa05eaa9a>
       > Bridge af7465c8-eb6b-4ad2-b591-7b7fa05eaa9a: switching from simple_bridge technology to native_rtp
       > Remotely bridged 'PJSIP/6600-0000003f' and 'PJSIP/trunk-00000040' - media will flow directly between them
       > 0x7fce780439e0 -- Strict RTP learning after remote address set to: 10.0.0.6:19790
    -- Channel PJSIP/6600-0000003f left 'native_rtp' basic-bridge <af7465c8-eb6b-4ad2-b591-7b7fa05eaa9a>
    -- Channel PJSIP/trunk-00000040 left 'native_rtp' basic-bridge <af7465c8-eb6b-4ad2-b591-7b7fa05eaa9a>
  == Spawn extension (phones, 200, 1) exited non-zero on 'PJSIP/6600-0000003f'
    -- Executing [h@phones:1] Log("PJSIP/6600-0000003f", "NOTICE,Test hangup")
[Mar  5 15:25:25] NOTICE[417059][C-00000012]: Ext. h:1 @ phones: Test hangup

It seems that when the trunk server registers a connection it sends an answer response which kills the other attempt’s. When not dialing over trunk everything behaves accordingly. Is there a setting in pjsip.conf or something else.

2

If the remote side has said the call has been answered, then it is treated as answered. There’s not really anything in PJSIP configuration as a caller you can do to alter it.

1 Like
3

I also implemented the remote side:

[trunk]
exten => _X.,1,Answer()
 same => n,Dial(PJSIP/${EXTEN},,rg)
 same => n,Hangup()

Should I get rid of the Answer application?

4

The problem was the remote side. The Answer App prematurely cancels the other calls, and it doesn’t seem to be necessary. I would like to know what the Answer and Hangup apps do?

5

They do exactly what they say. Answer answers the call when executed, and Hangup hangs the call up. If you do Dial() without answering first, then the calling party will be answered when the called party answers.

6

Which is what most people really want. There seems to a common misunderstanding that you must answer the call in the dialplan, but that means toll callers get billed, even if the call then fails.

There are times when you do want to answer early, e.g. if the call is going into a queue and an agent won’t pick up promptly.

There is an implied Hangup when you run off the end of the dialplan, and answered calls hangup, by default, without continuing in the dialplan. You might want an explicit Hangup, if you want to return a status other than the default. People also use it because they are using wildcards in dialplans, and it is possible that an explicit extension could end on a lower priority than a wildcard match for the same number; they use it as a belt and braces approach.

2 Likes
7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.