Audio only after 15-20 seconds on Endpoints behind a Sonicwall

Hello everyone!

I’m encountering a tricky problem with a newly installed client, where in both outbound and inbound calls, sometimes the audio starts after 15-20 seconds.
It don’t happen in every call, but it’s a considerable amount that is causing some inconvenience.

The trunk and endpoints use PJSIP, and the server is on a VPS at Vultr.

After the client reported the situation to us, I tested it on our network and on alternative networks and realized that this only happens with endpoints registered on their network, which has a Sonicwall Firewall.

Analyzing the sngrep comparison between a call that worked well and one that presented this problem, in addition to the time it took for the RTP packets to start flowing, one thing that caught my attention was a change in ports where the RTP was being sent - first it tried on the 6000 of the endpoint, and after 20 seconds of silence, it switched to the correct port and the audio started flowing on both sides.

image

I requested that the client’s IT team whitelist all traffic from the FreePBX cloud public IP, which they did, but the problem still persists.

We scheduled a joint meeting for this Thursday to review some firewall settings together and run tests until we confirm that everything will be fine.

In this scenario, do you have any tips or suggestions that I could pass on to the firewall team or settings that we could request from them?

Thanks in advance for your help!

EDIT: I forgot to mention earlier, but the behavior is the same with default VOIP settings disabled or enabled.

Is VPN at Vultr has IPv6 enabled ? i had past some issues and when changed to ipv4 and disabled Vultr FW fixed issues.

2 Likes

6000 will be what the SDP (which you didn’t provide) is telling it to use. The change will be the result of receiving incoming traffic,from a different port, combined with having symmetric RTP enabled (the latter a good thing, in this case).

This would suggest that NAT is rewriting the port number.

That doesn’t explain the late start of the media in the opposite direction, only that the port changes when that starts. It is quite possible that you don’t generate any media in that time. There is enough information to determine whether that might be the case.

1 Like

First make sure that the SonicWALL settings are correct.

Consistent NAT

User Manage → VoIP

  • Enable consistent NAT.
  • Leave everything else unchecked.

SonicWALL SSO

SonicWALL SSO can cause issues, especially with the audio portion of the call.

  • Create a Service Group that contains your SIP and RTP ports
  • Under SSO Enforcement BYPASS this service group.

You may have to flush active connections for this to work


If this still does not work. You may need to create a NAT rule and disable source port remap.

2 Likes

IPV6 is currently disabled on Vultr, but thanks for the suggestion!

Sorry! I forgot to initially include the call’s SDP.
Here’s one from a recent call where this behavior was displayed:

The call was answered at 08:57:50, but the audio only started flowing from 08:58:11, after the ports were changed.
Does this SDP give us any hints?

@PitzKey Thanks for the tips! I will ask the client’s IT team to apply these settings, I’ll update with the results soon!

Yes it shows they have told Asterisk to send to port 10000, when they are actually sending from a different one (and presumably receiving on it). Asterisk cannot correct the destination port until it receives something from them.

A router is mangling the port number. Whilst Asterisk can recover from that, it can only do so if it receives traffic in the other direction.

image

1 Like

It’s probably what @PitzKey suggested to you.

2 Likes

This thread still might apply: Happiness With Sonicwalls - It can happen!

3 Likes

Hey @PitzKey, thanks!

I requested exactly these settings from the firewall team and after that, the problem is no longer occurring.

3 Likes

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