WebRTC no audio in some calls

Asterisk Asterisk WebRTC
1

Hello,

I’m currently working with WebRTC extensions and my issue is related to some calls that don´t have audio when they´re answered.
I was doing some diagnostics and found out that the calls that don´t have audio are the ones which the user took more time to answer. In other words when I make the calls and users answers in the first or second ringing, the call has audio but when the user takes more time to answer the phone the call doesnt have audio.
I noticed the following in the log console when I have a call with audio:

 0x7fe14801f3b0 -- Strict RTP learning after remote address set to: XXX.XXX.116.52:23670
    -- SIP/SIPTRK-DEMO-AAA-00000033 is making progress passing it to SIP/206-00000032
       > 0x7fe14801f3b0 -- Strict RTP switching to RTP target address XXX.XXX.116.52:23670 as source
    -- SIP/SIPTRK-DEMO-AAA-00000033 is ringing
    -- SIP/SIPTRK-DEMO-AAA-00000033 is making progress passing it to SIP/206-00000032
       > 0x7fe14801f3b0 -- Strict RTP learning complete - Locking on source address XXX.XXX.116.52:23670
    -- SIP/SIPTRK-DEMO-AAA-00000033 answered SIP/206-00000032
    -- Channel SIP/SIPTRK-DEMO-AAA-00000033 joined 'simple_bridge' basic-bridge <12a3e5a8-df74-41ab-b39f-ffc48130b44d>
    -- Channel SIP/206-00000032 joined 'simple_bridge' basic-bridge <12a3e5a8-df74-41ab-b39f-ffc48130b44d>
       > 0x7fe158017ad0 -- Strict RTP learning after ICE completion
       > 0x7fe158017ad0 -- Strict RTP learning after remote address set to: XXX.XXX.180.118:56375
       > 0x7fe158017ad0 -- Strict RTP switching to RTP target address XXX.XXX.180.118:56375 as source

And this is the console log when I dont have audio in a call:

 0x7fe17003ecd0 -- Strict RTP learning after remote address set to: XXX.XXX.116.52:23190
    -- SIP/SIPTRK-DEMO-AAA-00000037 is making progress passing it to SIP/206-00000036
       > 0x7fe17003ecd0 -- Strict RTP switching to RTP target address XXX.XXX.116.52:23190 as source
    -- SIP/SIPTRK-DEMO-AAA-00000037 is ringing
    -- SIP/SIPTRK-DEMO-AAA-00000037 is making progress passing it to SIP/206-00000036
       > 0x7fe17003ecd0 -- Strict RTP learning complete - Locking on source address XXX.XXX.116.52:23190
       > 0x7fe1580160d0 -- Strict RTP learning after ICE completion
    -- SIP/SIPTRK-DEMO-AAA-00000037 answered SIP/206-00000036
    -- Channel SIP/SIPTRK-DEMO-AAA-00000037 joined 'simple_bridge' basic-bridge <7dc9410c-a71a-41b2-85c4-21560b300647>
    -- Channel SIP/206-00000036 joined 'simple_bridge' basic-bridge <7dc9410c-a71a-41b2-85c4-21560b300647>

What I noticed was that the call with no audio didnt lock on the internal ip source address (webrtc client) and it just locked on the public IP address source (trunk).
This behavior only happens when the call is answered by the user after some time of being ringing.
Is there anything that can be modified in the asterisk server that could help webrtc to wait some more time until user answers the phone before SRTP locks the audio only in the trunk side?

Thanks in advance.

2

That simply means it is getting no audio from that side.

1 Like
3

Yes most likely because the user didnt answer the phone after 3 or 4 ringings. But I think it’s necessary that the call doesn’t lose the audio just because the user doesn’t answer quickly. I tested udp and tls extensions and they don’t have any issues with the ringing and the audio.
Is there any timing configuration in webrtc that could be causing the issue?

Thanks

4

I did some more diagnostics and found out that the firewall was blocking SIP signaling from the webrtc client, therefore RPT ports were blocked. A new policy was applied to the firewall to accept those packets and open RTP ports through a SIP session helper and now all the calls have audio.
Thanks.

1 Like
5

Did you change your rtp.conf file to read : 8800 - 32728
Most of the times One way Audio has to do with rtp going over the standard 10000-20000 port range
; if not I’d suggest that small change

6

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