SR140 NAT Traversal
- John Shaheen
- Stephen Hoogerhyde
- Toshan Lash
Goals
The SR140 fax server will be deployed behind a NAT device, e.g. in AWS EC2. The media server will have a private IP address. SIP and RTP traffic will traverse the local NAT device.
Background and strategic fit
SR140 requires an SBC when running in AWS because the AWS environment does not perform NAT Traversal capabilities for SIP as a default. This adds to the cost of the solution and is not desirable.
Solution: Allow the setting of an IP address that will be used to modify the SIP headers, such as From and Contact, as well as the SDP headers defining the RTP connection information to the external IP of the EC2 instance.
The SR140 needs to be aware of the NAT device's public IP address. This public IP address will be used in place of the private IP address. This setting can be a single value for the whole system assigned when SR140 starts (in configuration file).
Assumptions
Requirements
| # | Title | User Story | Importance | Notes |
|---|---|---|---|---|
| 1 |
User interaction and design
Here are the fields that the SBC changed before they built it into the product: There could be others that I am missing.
On a SIP message with a SIP Request:
From IP Address
Contact IP address
Via IP address (first one in the list if multiple)
In the SDP:
IP address in the “C” lines
IP address in the :”o”
Any P-Asserted-Identity address field
Any Record-route address field
In a 18x message
Contact IP address
In a 200 message
Contact IP address
In 4xx message
Contact IP address
For question number 2 below "Who will obtain the public IP address?":
If the SR140 is required to figure out what the public IP address is, we need a keyword in the
callctrl.cfg file which would tell the SR140 to use the public IP address that it obtains.
If the customer obtains the public IP address, then we need a keyword in the callctrl.cfg file
which would tell the SR140 the public IP address it should use.
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|---|
| No. There will be two new keywords. nat_sip_address and nat_media_address in the callctrl.cfg file. |
2. Who will obtaining the public IP address? Is it the responsibility of the customer or is the SR140 required to figure out what external IP of the system is? | The customer will obtain the public IP addresses for SIP and Media and enter them in the callctrl.cfg file under the keywords nat_sip_address and nat_media_address, respectively. |
| 3. If there is a new keyword for the public IP address in the callctrl.cfg file, will this keyword take precendence over the other keywords such as sip_Contact, sip_ip_interface and sip_From? | The two NAT keywords in the callctrl.cfg file will take precedence over the other keywords such as sip_From, sip_Contact, etc. If the sip_From keyword Host Part is not an IPv4 address, then it will not be replaced with the value from the nat_sip_address keyword value. |
| 4. What about the Request URI and the To: header fields? Will these use the public IP address? | These should use the IP address of the remote side which is receiving the fax. |
| 5. Support for both IPv4 and IPv6 or just IPv4? Also, see question 16 below. | IPv4 only. |
| 6. What about the port for the public IP address? | Leave the ports alone. The ports for the public IP addresses will be the same as the ports for for the private IP addresses. From HMP: Each private port number will be mapped to the same public port number on the NAT device The UDP and TCP ports in SIP and SDP won't be translated since the NAT device will be configured for matching private / public ports. |
| 7. What about incoming SIP messages. | Incoming SIP messages can be left as is. When sending from the AWS machine to my laptop, the SR140 recognizes and processes the incoming SIP messages. From HMP: Media server inbound SIP and SDP Inbound SIP and SDP don't have private IP address issues at the media server since the source transport addresses in SIP messages and SDP payloads are set to the endpoint's public transport address. The NAT device handles forwarding of the inbound IP datagrams to the media server's private address. |
| 8. The HMP implementation only translates the From: Via: and Contact: fields for requests? What about the Contact: field in reponses? | This has now been changed as part of the check in for revision 4680. |
9. HMP changes the SDP o= and c= field IP addresses based on the NAT media IP address. Do we want to have both the o= and c= field IP addresses follow the keyword nat_media_address or have the c= field IP address follow the keyword nat_media_address and the o= field IP address follow the keyword nat_sip_address? | In an email exchange with Bob, he thinks the c= field IP address follows the media IP address and the o= field IP address follows the call control (SIP) IP address. From the HMP API document: GC replaces the host part of the addresses on the c= and o= SDP lines https://enghouseglobal.atlassian.net/secure/attachment/23912/23912_gc_nat_api_r4672.txt It was decided that the c= field will be set to the nat_media_address keyword and the o= field will be set to the nat_sip_address. |
| 10. Do we want to add NAT address capabilities to the API? For example, when making a call, do we want to be able to set the NAT SIP and media IP addresses on a per call basis. I believe HMP allows this. See: https://enghouseglobal.atlassian.net/secure/attachment/23912/23912_gc_nat_api_r4672.txt | John said in the standup meeting that we do not want to add this to the API. We only want the two new keywords in the callctrl.cfg file to affect the operation of NAT traversal. |
11. I don't see any mention of changes in the HMP code for P-Asserted-Identity or Record-route IP addresses for the NAT IP address. It may be that the HMP does not support these. Also, see questions 13 and 14 below. | P-Asserted-Identity and P-Preferred-Identity will be supported. Both will be set to the nat_sip_address keyword. |
12. NAT keep-alive From HMP: NAT keep-alive is used to keep the NAT bindings from timing out and being removed. It may be possible to use native transport keep-alives instead or configure Two NAT keep-alive techniques are described in section 3.5 of RFC 5626, CRLF Keep-Alive for TCP RFC 5626 also describes detecting handling NAT flow failures and NAT flow Do we need to do anything for NAT keep-alive? | There is no need to support this. |
| 13. I don't believe the SR140 adds a Record-Route: header field to any SIP messages. Record-Route: header fields are normally added by proxies to the initial request. Since the SR140 does not add a Record-Route: header field there is no address to change. The SR140 does add a Route: header field based on the keyword sip_Route in the callctrl.cfg file. Do we want to replace the IPv4 address for the Route: header field with the nat_sip_address keyword value? | It was decided the Route: header field will be not be set to the nat_sip_address keyword. See my email exchange with Bob Below: I was working on the code changes to replace the Route: header field with the nat_sip_address. After some testing and investigation, I don’t think we want to replace the Route: header field with the nat_sip_address as mentioned on the Confluence page under question 13. The Route: header field should normally not be set to the local private IP address. I believe it should be set to force the sending of requests to a proxy and therefore will probably be set to a proxy address. From the API reference manual under sip_route: Indicates the value provided in the SIP header for the Route parameter. The Route parameter contains the address or multiple addresses of proxy servers. The system uses the Route parameter to force routing of a request through the listed set of proxies. From RFC3261 under section 20.34: The Route header field is used to force routing for a request through the listed set of proxies. If I have the code change the value from the sip_Route keyword to the nat_sip_address, then this will most likely break this functionality. If the customer really wants the Route: header field to be set to the nat_sip_address, then they can set the sip_Route keyword themselves, which will have the same effect. What do you think? I think that’s fine then. We don’t have any customers who’ve ever used the sip_route keyword anyway so I’m not worried about our breaking something that’ll be seen in the field. So if the sip_route is meant to be set to something else other than the internal IP address of the system anyway, then we shouldn’t be changing it since NAT is only for translating the internal address. |
| 14. Do we want to replace the IPv4 address for the P-Asserted-Identity header field in a SIP message with the nat_sip_address? If we want to replace the IPv4 address for the P-Asserted-Identity header field in a SIP message, do we also want to replace the IPv4 address for the P-Preferred-Identity header field in a SIP message as well? | P-Asserted-Identity and P-Preferred-Identity will be supported. Both will be set to the nat_sip_address keyword. |
| 15. What about the Contact: header field in other responses besides 18x, 200 and 4xx? The HMP code does not seem to check which response is being sent before updating the Contact: header field with the NAT address. | All Contact: header fields in all responses will be set to the nat_sip_address keyword. |
16. Will we be supporting any string for the nat_sip_address keyword such as an IPv4 address, an IPv6 address or an FQDN? The HMP code supports this. Will we be supporting an IPv4 address or an IPv6 address for the nat_media_address keyword? The HMP code suports an IPv4 address or an IPv6 address. From HMP: nat_external_sip_address GC replaces the host part of the addresses in the From, Contact and Via SIP headers with the "nat_external_sip_address" string in all outbound SIP messages. The value can be any string, e.g. an IPv4 address, an IPv6 address or an FQDN. The default value is NULL which means SIP address translation is disabled.nat_external_rtp_address GC replaces the host part of the addresses on the c= and o= SDP lines with the "nat_external_rtp_address" string in all outbound SDP. The value must be an IPv4 address or an IPv6 address. The default value is NULL which means SDP address translation is disabled.https://enghouseglobal.atlassian.net/secure/attachment/23912/23912_gc_nat_api_r4672.txt | We will only be supporting IPv4 addresses for both the nat_sip_address keyword and the nat_media_address keyword. |
Links of interest:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html
http://bot.whatismyipaddress.com/