Gamma – cyber-cottage.co.uk

Over the last few weeks and possibly going on for a few more Gamma Telecom are migrating users from their MSX SBCs to their ‘new’ SWe SBCs, and as side effect of this change is that they now do not support non-symetrical nat translation of RTP traffic

Their previous SBCs and like many other carriers do not have an issue with this and in the words of Twilio’s notes below they support both methods

** When Symmetric RTP is enabled Twilio will detect where the remote RTP stream is coming from and start sending RTP to that destination instead of the one negotiated in the SDP. Please note that this setting is more vulnerable to RTP attacks.

When Symmetric RTP is disabled, Twilio will send RTP to the destination negotiated in the SDP. This setting is considered to be more secure and therefore recommended.

On making support calls to Gamma initially they just seem to tell users that the RTP is being sent from a port that isn’t specified in the SDP, and yes that is correct, But Gamma being Gamma and even though they will have had numerous calls they don’t go any further

It seems the problem is with the customer firewalls in particular pfSense:

By default, pfSense software rewrites the source port on all outgoing connections except for UDP port 500. Some operating systems do a poor job of source port randomization, if they do it at all. This makes IP address spoofing easier and makes it possible to fingerprint hosts behind the firewall from their outbound traffic. Rewriting the source port eliminates these potential (but unlikely) security vulnerabilities. Outbound NAT rules, including the automatic rules, will show in the Static Port column on rules set to randomize the source port.

Source port randomization breaks some rare applications. The default Automatic Outbound NAT ruleset disables source port randomization for UDP 500 because it will almost always be broken by rewriting the source port. Outbound NAT rules which preserve the original source port are called Static Port rules and have on the rule in the Static Port column. All other traffic has the source port rewritten by default.

To add a rule for a device which requires static source ports:

Navigate to Firewall > NAT, Outbound tab
Select Hybrid Outbound NAT rule generation
Click Save
Click to add a new NAT rule to the top of the list
Configure the rule to match the traffic that requires static port, such as a source address of a PBX.
Check Static Port in the Translation section of the page
Click Save
Click Apply Changes

After making that change, the source port on outgoing traffic matching the rule will be preserved. **The best practice is to use strict rules when utilizing static port to avoid any potential conflict if two local hosts use the same source port to talk to the same remote server and port using the same external IP address.**

Personally I would just make this change for the UDP port range and not all UDP ports as this could cause problem with traffic such a port 5060 when multiple servers or phones are on a site.

We have also been made aware of another issue with respect to call diversion to external numbers. By deafault Asterisk and many other IP PBXs set a diversion header in the 181 message giving the device that diverted the call and reason. in most cases this will be the extension number so the header will look like:

 Diversion: <sip:477@aaa.bbb.ccc.ddd>;reason=unconditional

This seems to cause issues at Gamma and they reject the call as it seems they are setting the callerid from this info.

To overcome this issue for chan_sip set ‘send_diversion = no’ in the general setting of sip.conf or in the “Other SIP Settings” fields in the Advanced sip setting menu. For PJSIP add it to the pjsip.endpoint_custom_post.conf file as below.

[PJSIPTwilio](+)
send_diversion=no

[GRAMMA_TEST](+)
send_diversion=no

And this seems to solve the problem.

To be honest we have only seen the problem with Gamma trunks and having tested with other suppliers and found they are not affected.

Gammas reson for this is as follows: “After reviewing the divert packet, I can see in the message header that the Diversion header is set to divert to “477”. I would recommend to change this to the full CLI you wish to forward the call to as I believe the system is trying to call “477” which wouldn’t be classed as a valid number. The 603 error you are seeing from your side would be in relation to OFCOMS national number length violation.”

See the Packet below

Session Initiation Protocol (181)
    Status-Line: SIP/2.0 181 Call is being forwarded
        Status-Code: 181
        [Resent Packet: False]
        [Request Frame: 22149]
        [Response Time (ms): 187]
    Message Header
        Via: SIP/2.0/UDP xxx.yyy.aaa.zzz:5060;branch=z9hG4bK04B82da620259a59a1a;received=xxx.yyy.aaa.zzz;rport=5060
            Transport: UDP
            Sent-by Address: xxx.yyy.aaa.zzz
            Sent-by port: 5060
            Branch: z9hG4bK04B82da620259a59a1a
            Received: xxx.yyy.aaa.zzz
            RPort: 5060
        From: <sip:01234567890@xxx.yyy.aaa.zzz>;tag=gK0441ee4f
            SIP from address: sip:01234567890@xxx.yyy.aaa.zzz
            SIP from tag: gK0441ee4f
        To: <sip:07890123456@aaa.bbb.ccc.ddd>;tag=as24643c1b
            SIP to address: sip:07890123456@aaa.bbb.ccc.ddd
            SIP to tag: as24643c1b
        Call-ID: 71571273_130153708@xxx.yyy.aaa.zzz
        [Generated Call-ID: 71571273_130153708@xxx.yyy.aaa.zzz]
        CSeq: 321899 INVITE
            Sequence Number: 321899
            Method: INVITE
        Server: FPBX-16.0.40.7(18.9)
        Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
        Supported: replaces, timer
        Session-Expires: 1800;refresher=uas
        Contact: <sip:07890123456@aaa.bbb.ccc.ddd:5060>
            Contact URI: sip:07890123456@aaa.bbb.ccc.ddd:5060
                Contact URI User Part: 07890123456
                Contact URI Host Part: aaa.bbb.ccc.ddd
                Contact URI Host Port: 5060
        Diversion: <sip:477@aaa.bbb.ccc.ddd>;reason=unconditional
        Content-Length: 0

Now the RFC says :

“When a diversion occurs, a Diversion header SHOULD be added to the forwarded request or forwarded 3xx response. The Diversion header MUST contain the Request-URI of the request prior to the diversion. The Diversion header SHOULD contain a reason that the diversion occurred.”

Which is what happens, Gamma seem to have confused what the diversion header does as they seem to assume its setting the diversion destination or outbound caller ID, Neither of which are the uses for the Diversion header.

‘I will add updates here as and when they become available.’

This website uses cookies