Jump to content

RTP TRAFFIC PORT RANGE (s)


andrewgroup

Recommended Posts

When you have two trunks configured from two seperate providers and dial plans allowing the use of either trunk.

 

How do we deal with the issue of each ITSP requesting the RTP ranges to be in two different Port Ranges.

 

 

Example 35000 - 40000 for ITSP provider #1 and 49152-53247 for ITSP provider #

 

 

Do we simply put 35000-53247 and let the SDP packets negotiate the final set of ports that will be used?

 

 

Do we select the "FOLLOW RTP" option on the ports settings page?

 

We recently added another SIP provider, and we are experiencing dropped calls... We think this may be the issue. (I just placed an inbound call, and was connected to what appeared to have been an active call hearing one side of an active call.

Link to comment
Share on other sites

Follow-RTP has to do with the fact that in theory according to the IETF you can send from A on system X to port B on system Y, and receive on port C on system X from port D on system Y. That has only very little practical relevance today as it is very NAT unfriendly.

 

 

The port range is a global setting, independent from trunks, extensions and others. This is the first time that I hear that a trunk provider requires specific RTP ports (this is also very NAT unfriendly). There is no negotiation for RTP ports in SDP, because each side has independent ports and each side just picks one.

 

 

Although theoretically possible, I would give this a low probability. If the problem can be reproduced easily, I would take a look at the PCAP trace.

Link to comment
Share on other sites

Thanks for the Snappy reply, but in the past, we've have situations where callers appeared to be cross connected, and the issues were resolved by matching the PORT range with the port range information provided by the carrier.

 

 

IE Windstream / Nuvox Communications on their SONOS sip servers recommend the following ports. These SIP trunks are not behind NAT devices and making these adjustments fixed the issues at the time.

RTP Media - udp range 16384 32767

udp range 49152 53247

 

 

We now make sure and ask the tech support groups at any carriers and see if they make recommendations.

 

This new trunk, just added a week ago, in on a BroadSoft Platform, and they recommended the MEDIA ports to be 35000-40000

 

I'm sure the carriers have to create some sort of acceptable port values in their equipment, so it seemed logical to match that.

 

This new PBX and SERVER is running Windows Server 2008, and their is a known issue with DNS grabbing a range of PORTS for DNS services, but I don't think that had any effect or issue within only the DNS client..

 

We'll dig some more and get a trace.

 

 

 

 

 

 

 

 

Follow-RTP has to do with the fact that in theory according to the IETF you can send from A on system X to port B on system Y, and receive on port C on system X from port D on system Y. That has only very little practical relevance today as it is very NAT unfriendly.

 

 

The port range is a global setting, independent from trunks, extensions and others. This is the first time that I hear that a trunk provider requires specific RTP ports (this is also very NAT unfriendly). There is no negotiation for RTP ports in SDP, because each side has independent ports and each side just picks one.

 

 

Although theoretically possible, I would give this a low probability. If the problem can be reproduced easily, I would take a look at the PCAP trace.

Link to comment
Share on other sites

We definitely had issues of crosstalk within active calls, and aligning the ports fixed the issues, or it was EXTREMELY coincidental. So we've posted various ITSP Port recommendations in the past.

 

Coredial out of Philidelphia recommends RTP Ports: Port Range Start: 10000 Port Range End: 30000, We've had no issues with them...

 

 

Window Stream - Nuvox when using their SONOS servers gave us these recommendations long ago. I assume they can use multiple UDP ranges for Media

 

RTP Media - udp range 16384 32767 udp range 49152 53247

Signal Protocol - udp 5060 tcp 5060

udp range 1718 1720 tcp range 1718 1720

udp 2427 tcp 2427

udp 2000 tcp 2000

 

We know have a large enterprise using the BroadSoft Platform on the Paetec Division of Windstream and working through the re-occurance of call issues. I personally called the client and appeared to have been connected to an in progress call..

 

 

Okay, we'll just add the RTP port begin and end to the trunk. Default will be like it is right now, so there should be no backward compatibility problems.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...