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.
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.
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.
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.