No audio when bridging two trunk calls

Hi all,

I am facing one weird issue with asterisk. I am using manager api to originate calls. I am successfully able to do that between one direct channel (on webrtc) and mobile number (through my sip provider) while everything works perfectly (able to hear voice, can end the call etc). But when I am trying to do the same between two mobile numbers (through my sip provider), I get all the signals (ringing, hangup) on both phones, but no audio on both phone.

Sample PJSIP config for my sip provider I am using as:

[sipprovider]
type=endpoint
transport=transport-udp
aors=sipprovider
auth=sipprovider
outbound_auth=sipprovider
context=sets
allow=ulaw,alaw
direct_media=no
ice_support=yes
rewrite_contact=yes
from_domain=example.com
from_user=+XXXXXXXXXXXX
contact_user=+XXXXXXXXXXXX
callerid=+XXXXXXXXXXXX
max_audio_streams=5

same PJSIP endpoint is being used in both the cases.

My extension file is:

[globals]
SIPPROVIDER=PJSIP/sipprovider
[sets]
include => external
[external]
exten => _+XXXXXXXXXXXX,1,NoOp()
same => n,MixMonitor(${UNIQUEID}.wav)
same => n,Dial(${SIPPROVIDER}/sip:${EXTEN}@example.com,b(handler^addheader^1(${CallerId})))
same => n,Hangup()

Sharing sample call file for better clarity (i have tried both approaches, using call-file and using manager api (asterisk-java), same issue)

Channel: PJSIP/sipprovider/sip:+XXXXXXXXXXXX@example.com
Extension: +YYYYYYYYYY
Context: external

Forgive me if I have missed any important information here.

Hi @grvtslyr, maybe it helps to see the logs what actually is done by asterisk.
I’m using rasterisk -vvvvv to see the dialplan and other details like RTP connections, for example:

0x7fee80096ac0 – Strict RTP learning after remote address set to: 192.168.1.14:12540

This may be easier to track down your issue.
Best

Thanks @terraformer for the response. I am sharing the logs below (obfuscated)

– Attempting call on PJSIP/sipprovider/sip:+xxxxxxxxxxxx@example.com for +yyyyyyyyyyy@external:1 (Retry 1)
– Called sipprovider/sip:+xxxxxxxxxxxx@example.com
> 0x7f6850033e20 – Strict RTP learning after remote address set to: 10.232.139.148:59936
– PJSIP/sipprovider-00000006 is making progress
– PJSIP/sipprovider-00000006 is making progress
– PJSIP/sipprovider-00000006 is ringing
– PJSIP/sipprovider-00000006 is ringing
– PJSIP/sipprovider-00000006 answered
– Executing [+yyyyyyyyyyy@external:1] NoOp(“PJSIP/sipprovider-00000006”, “”) in new stack
– Executing [+yyyyyyyyyyy@external:2] NoOp(“PJSIP/sipprovider-00000006”, "Variable received ") in new stack
– Executing [+yyyyyyyyyyy@external:3] MixMonitor(“PJSIP/sipprovider-00000006”, “1599893385.9.wav”) in new stack
== Begin MixMonitor Recording PJSIP/sipprovider-00000006
– Executing [+yyyyyyyyyyy@external:5] Dial(“PJSIP/sipprovider-00000006”, “PJSIP/sipprovider/sip:+yyyyyyyyyyy@example.com,b(handler^addheader^1())”) in new stack
– PJSIP/sipprovider-00000007 Internal Gosub(handler,addheader,1) start
– Executing [addheader@handler:1] Set(“PJSIP/sipprovider-00000007”, “PJSIP_HEADER(add,P-Preferred-Identity)=sip:example.com”) in new stack
[Sep 12 06:49:52] NOTICE[66963][C-00000004]: app_stack.c:1081 gosub_run: PJSIP/sipprovider-00000007 Abnormal ‘Gosub(handler,addheader,1)’ exit. Popping routine return locations.
– Called PJSIP/sipprovider/sip:+yyyyyyyyyyy@example.com
– PJSIP/sipprovider-00000007 is making progress passing it to PJSIP/sipprovider-00000006
> 0x7f6850047c60 – Strict RTP learning after remote address set to: 10.232.139.147:30708
– PJSIP/sipprovider-00000007 is making progress passing it to PJSIP/sipprovider-00000006
– PJSIP/sipprovider-00000007 is making progress passing it to PJSIP/sipprovider-00000006
– PJSIP/sipprovider-00000007 is making progress passing it to PJSIP/sipprovider-00000006
– PJSIP/sipprovider-00000007 is ringing
– PJSIP/sipprovider-00000007 is ringing
– PJSIP/sipprovider-00000007 answered PJSIP/sipprovider-00000006
– Channel PJSIP/sipprovider-00000007 joined ‘simple_bridge’ basic-bridge <1ae39d51-620a-4e42-9965-f069398171ec>
– Channel PJSIP/sipprovider-00000006 joined ‘simple_bridge’ basic-bridge <1ae39d51-620a-4e42-9965-f069398171ec>
– Channel PJSIP/sipprovider-00000006 left ‘simple_bridge’ basic-bridge <1ae39d51-620a-4e42-9965-f069398171ec>
– Channel PJSIP/sipprovider-00000007 left ‘simple_bridge’ basic-bridge <1ae39d51-620a-4e42-9965-f069398171ec>
== Spawn extension (external, +yyyyyyyyyyy, 5) exited non-zero on ‘PJSIP/sipprovider-00000006’
[Sep 12 06:50:04] NOTICE[66963][C-00000004]: pbx_spool.c:463 attempt_thread: Call completed to PJSIP/sipprovider/sip:+xxxxxxxxxxxx@example.com
== MixMonitor close filestream (mixed)
== End MixMonitor Recording PJSIP/sipprovider-00000006

Thanks for the details, @grvtslyr.
Please bear in mind that I’m just a hobbyist and no Asterisk professional.

However, when I establish a call, it looks like that:

[Sep 17 09:06:14] – Executing [222@from-internal:3] Dial(“PJSIP/224-00000044”, “PJSIP/222,60”) in new stack
[Sep 17 09:06:14] – Called PJSIP/222
[Sep 17 09:06:14] – PJSIP/222-00000045 is ringing
[Sep 17 09:06:14] – PJSIP/222-00000045 is ringing
[Sep 17 09:06:15] > 0x7fee8006cf10 – Strict RTP learning after remote address set to: 192.168.1.14:12544
[Sep 17 09:06:15] – PJSIP/222-00000045 answered PJSIP/224-00000044
[Sep 17 09:06:15] > 0x7fee8801b5d0 – Strict RTP learning after remote address set to: 192.168.1.18:5110
[Sep 17 09:06:15] – Channel PJSIP/222-00000045 joined ‘simple_bridge’ basic-bridge <7544b48b-b02c-4c26-986e-6f1887209509>
[Sep 17 09:06:15] – Channel PJSIP/224-00000044 joined ‘simple_bridge’ basic-bridge <7544b48b-b02c-4c26-986e-6f1887209509>
[Sep 17 09:06:15] > 0x7fee8801b5d0 – Strict RTP switching to RTP target address 192.168.1.18:5110 as source
[Sep 17 09:06:15] > 0x7fee8006cf10 – Strict RTP switching to RTP target address 192.168.1.14:12544 as source
[Sep 17 09:06:18] – Channel PJSIP/222-00000045 left ‘simple_bridge’ basic-bridge <7544b48b-b02c-4c26-986e-6f1887209509>
[Sep 17 09:06:18] – Channel PJSIP/224-00000044 left ‘simple_bridge’ basic-bridge <7544b48b-b02c-4c26-986e-6f1887209509>

In your case, there are no strict RTP lines. Maybe it’s normal and depends on our configurations, for example, I do not use ICE. Can you make a call that has working audio to see the differences?

Another difference I see is

PJSIP/sipprovider-00000006 is making progress

I’ve never seen such a line in my logs but I don’t use ICE.
Another wild guess: Can you set up an outgoing extension without the MixMonitor? Maybe that introduces a problem.

Best

thanks @terraformer for response. for better comparison, I am sharing the logs for case 1 (working scenario between webrtc and sipprovider

    -- Attempting call on PJSIP/agent1 for +xxxxxxxxxxx@external:1 (Retry 1)
    -- Called agent1
    -- PJSIP/agent1-00000004 is ringing
    -- PJSIP/agent1-00000004 is ringing
    -- PJSIP/agent1-00000004 answered
    -- Executing [+xxxxxxxxxxx@external:1] NoOp("PJSIP/agent1-00000004", "") in new stack
       > 0x7f67bc01b8e0 -- Strict RTP learning after remote address set to: 10.255.0.4:55000
    -- Executing [+xxxxxxxxxxx@external:2] NoOp("PJSIP/agent1-00000004", "Variable received ") in new stack
    -- Executing [+xxxxxxxxxxx@external:3] MixMonitor("PJSIP/agent1-00000004", "1599893330.6.wav") in new stack
  == Begin MixMonitor Recording PJSIP/agent1-00000004
    -- Executing [+xxxxxxxxxxx@external:5] Dial("PJSIP/agent1-00000004", "PJSIP/sipprovider/sip:+xxxxxxxxxxx@example.com,,b(handler^addheader^1())") in new stack
    -- PJSIP/sipprovider-00000005 Internal Gosub(handler,addheader,1) start
       > 0x7f67bc01b8e0 -- Strict RTP switching to RTP target address 10.255.0.4:55000 as source
    -- Executing [addheader@handler:1] Set("PJSIP/sipprovider-00000005", "PJSIP_HEADER(add,P-Preferred-Identity)=<sip:@example.com>") in new stack
[Sep 12 06:48:59] NOTICE[66927][C-00000003]: app_stack.c:1081 gosub_run: PJSIP/sipprovider-00000005 Abnormal 'Gosub(handler,addheader,1)' exit.  Popping routine return locations.
    -- Called PJSIP/sipprovider/sip:+xxxxxxxxxxx@example.com
    -- PJSIP/sipprovider-00000005 is making progress passing it to PJSIP/agent1-00000004
       > 0x7f6850033e20 -- Strict RTP learning after remote address set to: 10.232.139.150:30874
    -- PJSIP/sipprovider-00000005 is making progress passing it to PJSIP/agent1-00000004
       > 0x7f6850033e20 -- Strict RTP switching to RTP target address 10.232.139.150:30874 as source
       > 0x7f67bc01b8e0 -- Strict RTP learning complete - Locking on source address 10.255.0.4:55000
    -- PJSIP/sipprovider-00000005 is ringing
    -- PJSIP/sipprovider-00000005 is ringing
    -- PJSIP/sipprovider-00000005 answered PJSIP/agent1-00000004
    -- Channel PJSIP/sipprovider-00000005 joined 'simple_bridge' basic-bridge <67fc7ead-48f2-4275-9d8d-5fac50fb3147>
    -- Channel PJSIP/agent1-00000004 joined 'simple_bridge' basic-bridge <67fc7ead-48f2-4275-9d8d-5fac50fb3147>
       > 0x7f6850033e20 -- Strict RTP learning complete - Locking on source address 10.232.139.150:30874
    -- Channel PJSIP/sipprovider-00000005 left 'simple_bridge' basic-bridge <67fc7ead-48f2-4275-9d8d-5fac50fb3147>
    -- Channel PJSIP/agent1-00000004 left 'simple_bridge' basic-bridge <67fc7ead-48f2-4275-9d8d-5fac50fb3147>
  == Spawn extension (external, +xxxxxxxxxxx, 5) exited non-zero on 'PJSIP/agent1-00000004'
[Sep 12 06:49:17] NOTICE[66927][C-00000003]: pbx_spool.c:463 attempt_thread: Call completed to PJSIP/agent1
  == MixMonitor close filestream (mixed)
  == End MixMonitor Recording PJSIP/agent1-00000004

I can see one extra line in working scenario but don’t know the reason. Both the cases, uses same configuration for sipprovider

Strict RTP switching to RTP target address (some mediaip+port) as source

Making progress simply means that Asterisk received a 183 intermediate response from the callee. That is a function of the callee.

The strict RTP messages are common, but I’ve never had enough cause to look at the code to work out what produces them, although I suspect that they are a clue, and particularly that there are two of them.

I think I would want very detailed logging here, to work out whether Asterisk or the peer is imposing the delay. That might go as far as running tcpdump and wireshark, and using the latter to actually listen to the audio streams in and out of Asterisk.

Unless you are using a conference bridge or jitter buffer, I cannot think of any reason why Asterisk would internally delay media. Neither is default.

@grvtslyr thank you for the details.
I searched for the is making progress lines and found this. Maybe you can find something corresponding in your dialplan?

I have these RTP switching lines, too. Maybe it has to do with a

PJSIP/201-0000004b is ringing
[Sep 17 10:01:33] > 0x7fee8006cf10 – Strict RTP switching to RTP target address

Not sure if this helps you solving the problem but I have an idea that i would try. In lack of ad hoc knowledge how to bridge to channels manually together, I would set up a conference room. Then I would create two call files. One per mobile phone and have them connect to conference room. Maybe audio works that way?
Note that I did not try that myself. But digging into call files a little more sounds interesting for me.

Despite that and in accordance to @david551 you could pjsip set logger on or you use pjsip set logger host example.com to find out if SIP messages get lost.

Hope that helps

I will try this conference approach too if not able to resolve this. Thanks for the suggestion though.

Actually I checked the pcap too through wireshark but there were no rtp packets in this case, just sip and sip/sdp packets.

Weirdly, I have started getting audio once I added Playback(silence/1) before calling dialplan application. So now my extension looks like below:

[globals]
SIPPROVIDER=PJSIP/sipprovider
[sets]
include => external
[external]
exten => _+XXXXXXXXXXXX,1,NoOp()
same => n,Playback(silence/1)
same => n,MixMonitor({UNIQUEID}.wav) same => n,Dial({SIPPROVIDER}/sip:{EXTEN}@example.com,,b(handler^addheader^1({CallerId})))
same => n,Hangup()

Though I haven’t fully understood yet but I feel, by doing this I am forcing asterisk to start the audio which was not happening otherwise.
Thanks @david551 @terraformer for the help.

Dear @grvtslyr, glad to hear you found a workaround.
Interestingly, this seems to be related to my 2 seconds audio delay issue. Like your workaround, playing audio or Answer() the call right away solved my problem.

Best

1 Like

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