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://jira.dialogic.com:8443/secure/attachment/23912/23912_gc_nat_api_r4672.txt |
| 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://jira.dialogic.com:8443/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. | |
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? | |
| 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? | |
| 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? | |
| 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. | |
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://jira.dialogic.com:8443/secure/attachment/23912/23912_gc_nat_api_r4672.txt | |
Links of interest:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html
http://bot.whatismyipaddress.com/
0 Comments