Gamma SIP RTP issue 2

[JoeNewton]

Hi Guys,

Does anyone understand exactly how RTP ports are chosen by the IP Office? We have a customer on Gamma SIP, no SBC, who has been working fine for a number of years, but as of yesterday is getting one way speech. They on R11.0. We logged this with Gamma, and after investigating for most of they day they came back to say:

After analysing the examples provided during the media trace time span, many thanks for performing those test calls.

I have determined that the reason One-Way Audio is apparant for your customer is due to a Port Negotiation with the RTP Streams themselves, which is no longer accepted behaviour on the new SWe SBCs your customer has been upgraded to.

Please find the attach screen capture of one of the test call examples, of the RTP Flow. You will see, the Incoming RTP media stream is delivered to a Port of 49154 as requested in the 200 OK response to the initial INVITE. However, Media that is being sent from site is coming from Port 59401.

As advised, this type of behaviour was accepted on the MSX SBCs, but now your customer has been upgraded to our new SWe SBCs this behaviour is considered invalid.

To amend, could you please ensure, that the Media Port that RTP is sent from, is the also the same port used to receive incoming RTP.

I have attached their image also.

My first though was that this would be an affect of the Firewall/NAT type selected, it is currently set to Static Port Block which is what we tend to use with IPO on Gamma; however I have been through each NAT type in turn, and none have worked. Also, 59401 is not part of the RTP port range.

Any ideas what could be causing this, and how to stop it?

Thanks

Joe

Joe Newton

 

[sizbut]

Well my first reaction might be a less than polite "so you admit that you broke it, now fix it".

Never looked at it, but always assumed that the IP Office used matching ports for TCP/TLS. And whatever it likes for UDP - mainly because those are the usual with just about everyone (had to avoid the word "standard" there, don't think there are any standards for it, just recommended practices).

The screenshot does show one oddity, they sent RTP on an odd port - the usual practice is to send RTP on even ports (and RTCP on the odd ports). But again that's more an industry recommendation than a standard and probably isn't the cause of the issue here (but does hint that Gamma might not have much regard for good practises).

Stuck in a never ending cycle of file copying.

 

[CMUK]

My standard is full cone NAT, my NAT/RTP ports usually just 6000-7000 locked to gamma on my draytek

Calum M
ACSS

 

[TomMills]

Are you using a STUN server? Or is it on a Gamma Assured connection?

APSS/ACIS/ACSS-SME
not arrogant, just succinct.

 

[biglebowski]

Gamma have become a massive PITA

Few years ago we lost all telephony when Gamma rejected all invites with a media error, turns out that overnight they had changed to only accepting an invite with a ptime of 30mS but didn't tell us or many other customers (we were using 20mS)

We used to have a hybrid of loadshare and static SIP trunks for use with smartnumbers but when they migrated us over to the new MSX SBCs that stopped working (or being supported) They said we needed to pay them an extra £20k per year for additional SIP trunks as loadshare and static are now separate products.

 

[TomMills]

We got slapped a bit by that ptime issue too. That wasn't a good day.

APSS/ACIS/ACSS-SME
not arrogant, just succinct.

 

[Johnhyde]

Gamma has changed its SBC and added additional unnecessary security when it comes to RTP ports.

We are now having issues with no CLI on some external calls since they have changed SBC!

Luckily we have moved most of our customers away from Gamma.

 

[OldAndKnackered]

The Gamma issue isn't just causing issues with Avaya kit either, we've had some systems by a completely different manufacturer that we've had to reconfigure the way the SIP works in order to get things working again. PITA is right.

 

[JoeNewton]

Hi Guys,

We resolved the issue, turned out to be the customer's firewall changing the RTP ports. It must have always done it, but only became an issue after Gamma changed their SBC. Swapped for a Draytek and problem solved.

Thanks

Joe

Joe Newton

 

[TLDuk]

Having endless issuse with Gamma at the moment with the new SBCs changing the ptime in the rtp from 20ms to 40ms for no reason

If its not broke tweak it..