Hi, we have a cloud-based phone system being used and the calls are losing audio every once in a while. The support team for the cloud-based phone system is saying RTP ports are being blocked.

How can I determine if this is true?
Is there a way I can make sure RTP ports 20000-27999 (RTP Media) don't get dropped?

Thanks

If you're losing audio mid-call it's highly unlikely to be a firewall or port blocking issue. You can see the RTP ports actually used by looking at a capture of the SIP signalling, particularly the SDP headers, look for the "m=" header that give port number. You may have to resort to a Wireshark capture at your end with the ITSP doing the same at their end.

Does the ITSP's SBC or proxy have a fixed IP address? If so you could add a firewall rule specifically permitting RTP from that address. But double check the port range, not everyone uses the same ports for RTP.

Normally RTP is sent between the same pair of ports for any given call, so for example if your end decides to listen on port XXXX then your RTP will be sourced on that port. The provider's stream will therefore appear as if it's a reply to yours, meaning that normal connection-based stateful firewall rules will permit it.

Just a couple ideas. Maybe want to look if the SIP ALG is enabled, that can introduce trouble in some types of call flows. Also you can just allow UDP on those ports in the firewall to avoid consideration of what the MT firewall might be doing do.

While disabling SIP ALG is always worth a try, I don't think it would cause loss of audio mid-call. More typical issues from a malfunctioning ALG would be failure during call setup, or one-way or no-way audio from the start.

Does the ITSP's SBC or proxy have a fixed IP address? If so you could add a firewall rule specifically permitting RTP from that address. But double check the port range, not everyone uses the same ports for RTP.


The phone system host has a FQDN of core1-yyc.iplogin.ca and uses ports 20,000 to 27,999 for RTP. I guess my question would be how do I put in a firewall rule so these don't get dropped?

Just a couple ideas. Maybe want to look if the SIP ALG is enabled, that can introduce trouble in some types of call flows. Also you can just allow UDP on those ports in the firewall to avoid consideration of what the MT firewall might be doing do.

I have SIP ALG off and H323 in the firewall's service ports. How do I just add UDP on those ports (20,000 to 27,7999)?

I should have asked outright in the first place. Do your calls lose audio mid-call? Or is it a case of some calls not having any audio at all while other calls are OK.

I should have asked outright in the first place. Do your calls lose audio mid-call? Or is it a case of some calls not having any audio at all while other calls are OK.

Midway through the call, but it does not happen every time about one in 20 calls.

OK it is vanishingly unlikely that this can be a firewall issue

First thing is to get the symptoms completely clear. Does the call stay up but remain silent, for both calling and called parties? Or does one end see the call drop while the other end sees the call still up but without audio? Then we need to get a packet capture or a SIP trace at the time of the fault and she whether there's any signalling at the time.

OK it is vanishingly unlikely that this can be a firewall issue

First thing is to get the symptoms completely clear. Does the call stay up but remain silent, for both calling and called parties? Or does one end see the call drop while the other end sees the call still up but without audio? Then we need to get a packet capture or a SIP trace at the time of the fault and she whether there's any signalling at the time.

Yes, the call stays up and remains silent, sounds like on both parties. I added a call trace from a failed call.

Do you perhaps have a less complicated call scenario where the same happens? I can see a call transfer there, maybe the silence starts after the transfer because the media path reconfiguration fails in some way?
Also, where in the log is it visible that the RTP did not go through?
Is it a log from a single call or from multiple ones taking place at the same time?

Yes, the call stays up and remains silent, sounds like on both parties. I added a call trace from a failed call.

Can you provide this as a Wireshark capture, or as some format that has readable SIP messages?

If the call is being transferred there are all sorts of possibilities.

Do you perhaps have a less complicated call scenario where the same happens? I can see a call transfer there, maybe the silence starts after the transfer because the media path reconfiguration fails in some way?
Also, where in the log is it visible that the RTP did not go through?
Is it a log from a single call or from multiple ones taking place at the same time?

Hi Sindy, this is what the host is telling us, and I'm trying to prove or at least configure the Mikrotik so these ports for sure aren't being dropped. I only know the calls when the client tells me when it's happening, right now I'm not getting any complaints so if I could configure the router to keep these ports open then I can see if it's not doing it in this period and troubleshoot from there.

Yes, the call stays up and remains silent, sounds like on both parties. I added a call trace from a failed call.

Can you provide this as a Wireshark capture, or as some format that has readable SIP messages?

If the call is being transferred there are all sorts of possibilities.

The best I can do is clean it up on note pad this comes from the UC Host. I'm not on site.

By "ports being dropped" I can imagine two things. Either that nothing comes to these ports at their side, which may have other reasons than ports being "blocked", or that they send RTP to the phones from these ports and get back some "icmp destination unreachable" messages.

I suppose the phones are on private IPs so there is a NAT on the Mikrotik and the pinholes for the RTP traffic are created dynamically, and unless you've created some super tight firewall rules on the Mikrotik, it does not restrict access of LAN hosts to particular remote UDP ports in any way.

If the WAN address of the Mikrotik is assigned dynamically, or if the WAN interface goes briefly down and up again from time to time, and you use an action=masquerade for NAT, it can be that whenever the WAN port gets a new address or goes down briefly, all connections src-nated using that rule get dropped (which is a normal behavior). But since the phone keeps sending RTP, they should be re-created again, so only the change of WAN address sounds to be a likely reason to me.

Another possibility is that in the affected calls, the media path is indeed rebuilt due to call transfer or something similar and for some reason the RTP doesn't get through following that rebuild.

A sniff from the Mikrotik side, ideally matching on the IP address of the cloud system, is necessary to say more.

Can you pin-point where in that trace the audio was lost? In a call transfer, typically the audio is muted ("a=inactive") then re-established once the call is transferred. There may be a change in endpoint as well, meaning the "c= .." and "m= .. " headers are updated as well as resuming audio with "a=sendrecv".

If you lose audio at this stage then we need to see signalling at both ends. I have seen cases where these changes aren't passed through.

Contrary to my earlier comment, if you lose audio during one of these supervisory functions, rather than just in the middle of an established call, then possibly the ALG is back in the frame. For example by re-writing the SDP headers it may be obscuring the internal addressing so that the phone system cannot distinguish between end points within your LAN and behind the same external IP. Typically for hosted telephony the carrier very much does not want the ALG doing this, as it makes it impossible to route calls internally. Sometimes this means the site works OK with a single handset, but has trouble as soon as you have more than one.

That trace is not particularly readable, so I think we need to start by knowing exactly what point the fault occurred. A brief flip though it shows lots of different RTP ports, where a single plan call would only reference two. So if that's a single call then something very funny is going on.