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
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:
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.
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
[Resent Packet: False]
[Request Frame: 22149]
[Response Time (ms): 187]
Via: SIP/2.0/UDP xxx.yyy.aaa.zzz:5060;branch=z9hG4bK04B82da620259a59a1a;received=xxx.yyy.aaa.zzz;rport=5060
Sent-by Address: xxx.yyy.aaa.zzz
Sent-by port: 5060
SIP from address: sip:email@example.com
SIP from tag: gK0441ee4f
SIP to address: sip:firstname.lastname@example.org
SIP to tag: as24643c1b
[Generated Call-ID: email@example.com]
CSeq: 321899 INVITE
Sequence Number: 321899
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact URI: sip:firstname.lastname@example.org:5060
Contact URI User Part: 07890123456
Contact URI Host Part: aaa.bbb.ccc.ddd
Contact URI Host Port: 5060
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.’