Community discussions

MikroTik App
 
Salert
just joined
Topic Author
Posts: 7
Joined: Tue Jan 21, 2020 6:04 pm

Test RTP ports aren't dropping

Thu Jan 20, 2022 9:15 pm

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
 
aesmith
Member Candidate
Member Candidate
Posts: 260
Joined: Wed Mar 27, 2019 6:43 pm

Re: Test RTP ports aren't dropping

Fri Jan 21, 2022 7:27 pm

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.
 
User avatar
Amm0
Long time Member
Long time Member
Posts: 611
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: Test RTP ports aren't dropping

Fri Jan 21, 2022 8:51 pm

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.
 
aesmith
Member Candidate
Member Candidate
Posts: 260
Joined: Wed Mar 27, 2019 6:43 pm

Re: Test RTP ports aren't dropping

Fri Jan 21, 2022 10:49 pm

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.
 
Salert
just joined
Topic Author
Posts: 7
Joined: Tue Jan 21, 2020 6:04 pm

Re: Test RTP ports aren't dropping

Fri Jan 21, 2022 11:55 pm

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?
 
Salert
just joined
Topic Author
Posts: 7
Joined: Tue Jan 21, 2020 6:04 pm

Re: Test RTP ports aren't dropping

Sat Jan 22, 2022 12:02 am

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)?
 
aesmith
Member Candidate
Member Candidate
Posts: 260
Joined: Wed Mar 27, 2019 6:43 pm

Re: Test RTP ports aren't dropping

Sat Jan 22, 2022 5:54 pm

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.
 
Salert
just joined
Topic Author
Posts: 7
Joined: Tue Jan 21, 2020 6:04 pm

Re: Test RTP ports aren't dropping

Sun Jan 23, 2022 2:02 am

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.
 
aesmith
Member Candidate
Member Candidate
Posts: 260
Joined: Wed Mar 27, 2019 6:43 pm

Re: Test RTP ports aren't dropping

Sun Jan 23, 2022 6:00 pm

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.
 
Salert
just joined
Topic Author
Posts: 7
Joined: Tue Jan 21, 2020 6:04 pm

Re: Test RTP ports aren't dropping

Mon Jan 24, 2022 7:45 pm

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.
You do not have the required permissions to view the files attached to this post.
 
sindy
Forum Guru
Forum Guru
Posts: 8831
Joined: Mon Dec 04, 2017 9:19 pm

Re: Test RTP ports aren't dropping

Mon Jan 24, 2022 11:34 pm

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?
Don't write novels, post /export hide-sensitive file=x. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
aesmith
Member Candidate
Member Candidate
Posts: 260
Joined: Wed Mar 27, 2019 6:43 pm

Re: Test RTP ports aren't dropping

Tue Jan 25, 2022 8:17 pm

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.
 
Salert
just joined
Topic Author
Posts: 7
Joined: Tue Jan 21, 2020 6:04 pm

Re: Test RTP ports aren't dropping

Thu Jan 27, 2022 7:34 pm

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.
 
Salert
just joined
Topic Author
Posts: 7
Joined: Tue Jan 21, 2020 6:04 pm

Re: Test RTP ports aren't dropping

Thu Jan 27, 2022 7:37 pm

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.
You do not have the required permissions to view the files attached to this post.
 
sindy
Forum Guru
Forum Guru
Posts: 8831
Joined: Mon Dec 04, 2017 9:19 pm

Re: Test RTP ports aren't dropping

Thu Jan 27, 2022 7:59 pm

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.
Don't write novels, post /export hide-sensitive file=x. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
aesmith
Member Candidate
Member Candidate
Posts: 260
Joined: Wed Mar 27, 2019 6:43 pm

Re: Test RTP ports aren't dropping

Mon Jan 31, 2022 5:28 pm

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.

Who is online

Users browsing this forum: Baidu [Spider], Semrush [Bot], simsrw73 and 51 guests