Difference between revisions of "Network Configuration for VoIP Providers"
The Wiki of Unify contains information on clients and devices, communications systems and unified communications. - Unify GmbH & Co. KG is a Trademark Licensee of Siemens AG.
(initial import from word document) |
|||
| Line 4: | Line 4: | ||
| − | = The problem with NAT = | + | == The problem with NAT == |
| − | == SIP & SDP == | + | === SIP & SDP === |
Internet telephony uses the Session Initiation Protocol (SIP) to establish phone calls (or other “multimedia” sessions). SIP messages can contain a body with data of the Session Description Protocol (SDP), that contain at least one IP address and port that is used for sending and receiving the audio (voice) data (RTP). | Internet telephony uses the Session Initiation Protocol (SIP) to establish phone calls (or other “multimedia” sessions). SIP messages can contain a body with data of the Session Description Protocol (SDP), that contain at least one IP address and port that is used for sending and receiving the audio (voice) data (RTP). | ||
Furthermore some important SIP headers contain the local socket address (IP+port). | Furthermore some important SIP headers contain the local socket address (IP+port). | ||
| − | == Network address translation (NAT) == | + | === Network address translation (NAT) === |
| Line 21: | Line 21: | ||
The address change is made in IP/UDP header only – the data (SIP+SDP) is left unchanged. | The address change is made in IP/UDP header only – the data (SIP+SDP) is left unchanged. | ||
| − | == Binding life-time == | + | === Binding life-time === |
Practically all NAT implementations need to store some information about its state to recognize response packets and change them accordingly. This state information is called ''binding''. | Practically all NAT implementations need to store some information about its state to recognize response packets and change them accordingly. This state information is called ''binding''. | ||
| Line 30: | Line 30: | ||
It also means that an incoming packet can received only after a binding was opened earlier. | It also means that an incoming packet can received only after a binding was opened earlier. | ||
| − | == Problems resulting from router behavior == | + | === Problems resulting from router behavior === |
| − | === Payload establishment === | + | ==== Payload establishment ==== |
The private IP address used in the SDP c-line and port(s) used in the m-line(s) are not changed by the NAT, because they are belonging to the UDP data. | The private IP address used in the SDP c-line and port(s) used in the m-line(s) are not changed by the NAT, because they are belonging to the UDP data. | ||
| Line 39: | Line 39: | ||
Furthermore even if the address was correct, an open binding may be needed to pass a firewall. | Furthermore even if the address was correct, an open binding may be needed to pass a firewall. | ||
| − | === Routing of responses and new requests within the dialog === | + | ==== Routing of responses and new requests within the dialog ==== |
Also the SIP signaling is affected. The SIP RFC states that responses must to be sent back to the port used in the topmost Via-Header (or to the default port 5060 if no port is present). | Also the SIP signaling is affected. The SIP RFC states that responses must to be sent back to the port used in the topmost Via-Header (or to the default port 5060 if no port is present). | ||
| Line 51: | Line 51: | ||
In most configurations, the NAT router or firewall then has no open binding and cannot forward the request to the telephony system. | In most configurations, the NAT router or firewall then has no open binding and cannot forward the request to the telephony system. | ||
| − | === Registration === | + | ==== Registration ==== |
For incoming call the telephony system has to register itself at the ITSP. The address where incoming calls should be routed to is written to the Contact-Header of the SIP REGISTER request. | For incoming call the telephony system has to register itself at the ITSP. The address where incoming calls should be routed to is written to the Contact-Header of the SIP REGISTER request. | ||
If a private IP address is used that cannot be used by the ITSP, so no incoming calls are possible. | If a private IP address is used that cannot be used by the ITSP, so no incoming calls are possible. | ||
| − | = Possible Solutions = | + | == Possible Solutions == |
| − | == Application Layer Gateways == | + | === Application Layer Gateways === |
There are devices with “Application layer gateway” (ALG) functionality, that also inspect the UDP data for IP addresses and thus change SIP and SDP data. Experience shows that those devices are unreliable very often, so it is best to switch of any ALG functionality. | There are devices with “Application layer gateway” (ALG) functionality, that also inspect the UDP data for IP addresses and thus change SIP and SDP data. Experience shows that those devices are unreliable very often, so it is best to switch of any ALG functionality. | ||
| − | == STUN (RFC 3489, RFC 5389) == | + | === STUN (RFC 3489, RFC 5389) === |
One solution to solve this problem is that the endpoint finds out how the private transport address is changed by the NAT router. Therefore, the STUN protocol exists. A public STUN server responds to requests with an answer that contains the public address it has seen in the IP/UDP header of the request. Other protocols that query the NAT router for the public address directly are not used widespread due to security considerations (UPnP) or are still in draft state (Midcom). | One solution to solve this problem is that the endpoint finds out how the private transport address is changed by the NAT router. Therefore, the STUN protocol exists. A public STUN server responds to requests with an answer that contains the public address it has seen in the IP/UDP header of the request. Other protocols that query the NAT router for the public address directly are not used widespread due to security considerations (UPnP) or are still in draft state (Midcom). | ||
| − | == Remote (provider-side) solutions: SBC, symmetric response routing == | + | === Remote (provider-side) solutions: SBC, symmetric response routing === |
Another solution is to ignore the addresses in SIP and SDP data and just route responses and payload back to the originating address seen in the IP/UDP header. Obviously, this only works if at least one endpoint uses a public IP address and only one side uses this mechanism and the other starts with sending payload. Many ITSPs use media gateways (sometimes also called ''Session Border Controllers'' - SBC) that implement this (''far-end NAT support'' or ''symmetric response routing''). | Another solution is to ignore the addresses in SIP and SDP data and just route responses and payload back to the originating address seen in the IP/UDP header. Obviously, this only works if at least one endpoint uses a public IP address and only one side uses this mechanism and the other starts with sending payload. Many ITSPs use media gateways (sometimes also called ''Session Border Controllers'' - SBC) that implement this (''far-end NAT support'' or ''symmetric response routing''). | ||
To address all the problems mentioned in section 1.4, the ITSP has to support symmetric response routing for media, SIP responses (see also rport, section 2.4), SIP Requests (add Record-Route if working in proxy mode) and SIP Registration (store received IP and UDP source address as contact instead of the contact-header). | To address all the problems mentioned in section 1.4, the ITSP has to support symmetric response routing for media, SIP responses (see also rport, section 2.4), SIP Requests (add Record-Route if working in proxy mode) and SIP Registration (store received IP and UDP source address as contact instead of the contact-header). | ||
| − | == rport (RFC 3581) == | + | === rport (RFC 3581) === |
The rport mechanism changes the SIP routing behavior, so that responses can be received through a NAT even if private addresses are used in the SIP headers. It does not offer a solution for SIP registration and RTP establishment. | The rport mechanism changes the SIP routing behavior, so that responses can be received through a NAT even if private addresses are used in the SIP headers. It does not offer a solution for SIP registration and RTP establishment. | ||
| Line 75: | Line 75: | ||
When the rport-Parameter is added by the client to an outgoing SIP request, the receiving proxy also fills this parameter with the source port it sees in the received UDP header and uses it to route back the responses. | When the rport-Parameter is added by the client to an outgoing SIP request, the receiving proxy also fills this parameter with the source port it sees in the received UDP header and uses it to route back the responses. | ||
| − | == Offered solutions by the HiPath / OpenScape telephony systems == | + | === Offered solutions by the HiPath / OpenScape telephony systems === |
Our telephony systems support STUN and can trigger payload establishment with a provider-side media gateway. (This is needed if the ITSP wants to send payload before we start sending, e.g. if the provider wants to play back an announcement like “number not available” before the local phone starts sending payload.) | Our telephony systems support STUN and can trigger payload establishment with a provider-side media gateway. (This is needed if the ITSP wants to send payload before we start sending, e.g. if the provider wants to play back an announcement like “number not available” before the local phone starts sending payload.) | ||
Furthermore, the rport mechanism is always used (if not deactivated in the ITSP profile), because it does no harm and can help in diagnostics. | Furthermore, the rport mechanism is always used (if not deactivated in the ITSP profile), because it does no harm and can help in diagnostics. | ||
To keep NAT/firewall bindings open, empty UDP packets are sent to any SIP proxy and registration gateway of all registered ITSP. | To keep NAT/firewall bindings open, empty UDP packets are sent to any SIP proxy and registration gateway of all registered ITSP. | ||
| − | = STUN (RFC 3489 and RFC 5389) = | + | == STUN (RFC 3489 and RFC 5389) == |
| − | == NAT type detection == | + | === NAT type detection === |
The STUN protocol allows the detection of the way how the router performs NAT. This NAT type detection works with most, but not all routers that are available. | The STUN protocol allows the detection of the way how the router performs NAT. This NAT type detection works with most, but not all routers that are available. | ||
| Line 118: | Line 118: | ||
The filter behavior is of no interest to the HiPath / OpenScape telephony system: It always assumes that it needs to open a binding to the IP address and port of its peers and thus send empty UDP packets to open connections (RTP) or keeping bindings alive (SIP registration). | The filter behavior is of no interest to the HiPath / OpenScape telephony system: It always assumes that it needs to open a binding to the IP address and port of its peers and thus send empty UDP packets to open connections (RTP) or keeping bindings alive (SIP registration). | ||
| − | == Example SIP packets == | + | === Example SIP packets === |
| − | === Outgoing INVITE without STUN === | + | ==== Outgoing INVITE without STUN ==== |
<pre> | <pre> | ||
| Line 161: | Line 161: | ||
A NAT router does not look into the packets, but changes the IP address and may change UDP port, so the addresses in SIP header and SDP body are no longer valid. | A NAT router does not look into the packets, but changes the IP address and may change UDP port, so the addresses in SIP header and SDP body are no longer valid. | ||
| − | === Outgoing INVITE with STUN === | + | ==== Outgoing INVITE with STUN ==== |
<pre> | <pre> | ||
INVITE sip:089700732559@sip2.fsys.co.uk:5060 SIP/2.0 | INVITE sip:089700732559@sip2.fsys.co.uk:5060 SIP/2.0 | ||
| Line 200: | Line 200: | ||
With STUN the public IP and port can be learned with a STUN Binding Request. These addresses are then inserted in SIP header and SDP body. | With STUN the public IP and port can be learned with a STUN Binding Request. These addresses are then inserted in SIP header and SDP body. | ||
| − | = Behavior of the HiPath / Openscape system = | + | == Behavior of the HiPath / Openscape system == |
| − | == Overview of the different STUN modes == | + | === Overview of the different STUN modes === |
| − | === Auto === | + | ==== Auto ==== |
The STUN component does a NAT type detection and if the result shows that STUN can be used and needs to be used it is switched on, otherwise off. | The STUN component does a NAT type detection and if the result shows that STUN can be used and needs to be used it is switched on, otherwise off. | ||
In Tabelle 1 the green modes use STUN. For the red mode (symmetric UDP) STUN cannot be used, the grey modes do not need STUN, so STUN is switched off for these NAT types in AUTO mode. | In Tabelle 1 the green modes use STUN. For the red mode (symmetric UDP) STUN cannot be used, the grey modes do not need STUN, so STUN is switched off for these NAT types in AUTO mode. | ||
| − | === Always === | + | ==== Always ==== |
The NAT type detection is done, but STUN is switched on regardless of the result. The result is shown in WBM and log files, so it can be used for diagnostics. | The NAT type detection is done, but STUN is switched on regardless of the result. The result is shown in WBM and log files, so it can be used for diagnostics. | ||
| − | === Off === | + | ==== Off ==== |
STUN is switched off completely. | STUN is switched off completely. | ||
| − | === Port preserving router === | + | ==== Port preserving router ==== |
No NAT type detection is made. STUN gains the information of its public SIP signaling address, but does not start any request to lookup the address for payload. Instead of this, it assumes that the payload IP address is same as the SIP signaling IP address and the RTP port is not changed by the router. | No NAT type detection is made. STUN gains the information of its public SIP signaling address, but does not start any request to lookup the address for payload. Instead of this, it assumes that the payload IP address is same as the SIP signaling IP address and the RTP port is not changed by the router. | ||
Practically this means that STUN monitors the public address of port 5060 by sending out a binding request frequently (every 15 seconds). No binding request is made for ITSP calls. | Practically this means that STUN monitors the public address of port 5060 by sending out a binding request frequently (every 15 seconds). No binding request is made for ITSP calls. | ||
| − | === Static IP === | + | ==== Static IP ==== |
This mode is similar to “Port preserving router”, but the IP address is not monitored at all. Instead of this, the address entered in WBM is used as SIP signaling address. For SDP body, the public IP is used and the port remains unchanged. | This mode is similar to “Port preserving router”, but the IP address is not monitored at all. Instead of this, the address entered in WBM is used as SIP signaling address. For SDP body, the public IP is used and the port remains unchanged. | ||
| − | == Binding opening / keep-alive == | + | === Binding opening / keep-alive === |
| − | === Media stream === | + | ==== Media stream ==== |
As soon as the two endpoints of the media connection are known, the system sends out an empty UDP packet to the received media address (c and m-line in received SDP data) to open a NAT/firewall binding. This empty packet also triggers the ITSP’s media gateway to start sending payload (if in “symmetric response routing” mode). | As soon as the two endpoints of the media connection are known, the system sends out an empty UDP packet to the received media address (c and m-line in received SDP data) to open a NAT/firewall binding. This empty packet also triggers the ITSP’s media gateway to start sending payload (if in “symmetric response routing” mode). | ||
| − | === Registration === | + | ==== Registration ==== |
The fully qualified domain name (FQDN) of any active ITSP that is successfully registered or needs no registration is added to a list. Every 15 the entries are resolved to one or more IP addresses. If the port is 0, DNSSRV is used for resolving. Then an empty UDP packet is sent to every gained IP address. | The fully qualified domain name (FQDN) of any active ITSP that is successfully registered or needs no registration is added to a list. Every 15 the entries are resolved to one or more IP addresses. If the port is 0, DNSSRV is used for resolving. Then an empty UDP packet is sent to every gained IP address. | ||
(A multi-level cache makes sure that the impact of name resolving on system or network performance is as small as possible). | (A multi-level cache makes sure that the impact of name resolving on system or network performance is as small as possible). | ||
| − | = Interworking of STUN and NAT routers in practice = | + | == Interworking of STUN and NAT routers in practice == |
| − | == Port preserving routers == | + | === Port preserving routers === |
The biggest problems with STUN are some routers that behave non-deterministic. The NAT type detection detects a NAT that works fine, but under load the router changes it behavior. | The biggest problems with STUN are some routers that behave non-deterministic. The NAT type detection detects a NAT that works fine, but under load the router changes it behavior. | ||
For example, a lot of routers try to preserve the port if possible. NAT type detection then usually detects a “Port restricted Cone NAT” and uses STUN. Everything is fine, until it happens that the port needs to be changed, because it is already in use by another host or was used before by the same host and the binding has not timed out yet. | For example, a lot of routers try to preserve the port if possible. NAT type detection then usually detects a “Port restricted Cone NAT” and uses STUN. Everything is fine, until it happens that the port needs to be changed, because it is already in use by another host or was used before by the same host and the binding has not timed out yet. | ||
| Line 236: | Line 236: | ||
The best solution in both cases is to open the RTP port range on the firewall/NAT router and configure a port-forwarding rule that forwards the whole range unchanged to the telephony system. Then the “Port preserving router” mode can be used reliably. | The best solution in both cases is to open the RTP port range on the firewall/NAT router and configure a port-forwarding rule that forwards the whole range unchanged to the telephony system. Then the “Port preserving router” mode can be used reliably. | ||
| − | == Application Layer Gateways (ALG) == | + | === Application Layer Gateways (ALG) === |
Some routers offer more or less well implemented application layer gateways. | Some routers offer more or less well implemented application layer gateways. | ||
An ALG looks into the packet and changes the transported addresses in the same way as it does the NAT. A good ALG needs to know the protocol to do this correctly. SIP is supported by most ALG, but sometimes the implementation has significant problems (see below). | An ALG looks into the packet and changes the transported addresses in the same way as it does the NAT. A good ALG needs to know the protocol to do this correctly. SIP is supported by most ALG, but sometimes the implementation has significant problems (see below). | ||
| Line 246: | Line 246: | ||
Experience shows that some ALGs are badly implemented and for example cannot handle two simultaneous connections, because they mix up the used RTP ports. | Experience shows that some ALGs are badly implemented and for example cannot handle two simultaneous connections, because they mix up the used RTP ports. | ||
| − | == Symmetric NAT == | + | === Symmetric NAT === |
Symmetric NAT cannot be traversed by STUN, because the information gained with the help of the STUN server is not valid for packets that are sent to another server (SIP proxy). | Symmetric NAT cannot be traversed by STUN, because the information gained with the help of the STUN server is not valid for packets that are sent to another server (SIP proxy). | ||
A solution would be to send the STUN requests to the SIP proxy and payload partner directly (SIP Outbound / ICE). This is currently supported by neither our telephony systems nor any ITSP we know. | A solution would be to send the STUN requests to the SIP proxy and payload partner directly (SIP Outbound / ICE). This is currently supported by neither our telephony systems nor any ITSP we know. | ||
| Line 252: | Line 252: | ||
Open the RTP port range on the firewall/NAT router and configure a forwarding rule that the whole range is forwarded unchanged to the telephony system. Then the “Port preserving router” mode can be used reliably. | Open the RTP port range on the firewall/NAT router and configure a forwarding rule that the whole range is forwarded unchanged to the telephony system. Then the “Port preserving router” mode can be used reliably. | ||
| − | == Session border controller == | + | === Session border controller === |
The term “session border controller” (SBC) is not clearly defined. | The term “session border controller” (SBC) is not clearly defined. | ||
In general a SBC is a device that terminates (in the sense of “communication endpoint”) both SIP signaling and RTP media stream. | In general a SBC is a device that terminates (in the sense of “communication endpoint”) both SIP signaling and RTP media stream. | ||
| Line 261: | Line 261: | ||
If a SBC is used within the local network, it is recommended to disable STUN. | If a SBC is used within the local network, it is recommended to disable STUN. | ||
| − | == Far-end NAT traversal == | + | === Far-end NAT traversal === |
Some ITSP use “far-end NAT traversal” mechanism like “symmetric response routing”. | Some ITSP use “far-end NAT traversal” mechanism like “symmetric response routing”. | ||
There are differences in their implementations, so there is no recommendation how to configure the HiPath / Openscape telephony system. | There are differences in their implementations, so there is no recommendation how to configure the HiPath / Openscape telephony system. | ||
Some ITSP only activates their far-end NAT traversal support, if they see known private IP address (e.g. 192.168.0.1 or any other RFC 1918) | Some ITSP only activates their far-end NAT traversal support, if they see known private IP address (e.g. 192.168.0.1 or any other RFC 1918) | ||
| − | = Examples of misbehaving network devices = | + | == Examples of misbehaving network devices == |
In this chapter some problems we had in the past are mentioned. This is neither a complete list nor a detailed analysis of the problem’s cause. It is meant to give a ‘feeling’ for the kind of problems that may occur when setting up an IP network. | In this chapter some problems we had in the past are mentioned. This is neither a complete list nor a detailed analysis of the problem’s cause. It is meant to give a ‘feeling’ for the kind of problems that may occur when setting up an IP network. | ||
| − | == NAT routers == | + | === NAT routers === |
TODO: | TODO: | ||
* port preserving with symmetric fallback | * port preserving with symmetric fallback | ||
* load problems | * load problems | ||
| − | == ALG == | + | === ALG === |
TODO: | TODO: | ||
* ''Baudtec ALG'' | * ''Baudtec ALG'' | ||
Revision as of 13:10, 5 March 2010
| This document is still in draft state. It is incomplete and may contain wrong information |
Contents
The problem with NAT
SIP & SDP
Internet telephony uses the Session Initiation Protocol (SIP) to establish phone calls (or other “multimedia” sessions). SIP messages can contain a body with data of the Session Description Protocol (SDP), that contain at least one IP address and port that is used for sending and receiving the audio (voice) data (RTP). Furthermore some important SIP headers contain the local socket address (IP+port).
Network address translation (NAT)
Figure 1: Typical Internet access with NAT
This is a problem if a NAT router is present between the two telephony endpoints. The NAT router changes private IP addresses to the public one (e.g. ADSL endpoint address). In the example network in Figure 1, the router translates the private network 192.168.1.0/24 to one single IP address 149.246.229.150. In addition, the port is changed in many cases. This is sometimes named “Network address port translation” (NAPT). In this document, the term NAT always may also mean NAPT.
Figure 1: TCP/IP Layer Model (Source: Wikipedia )
The address change is made in IP/UDP header only – the data (SIP+SDP) is left unchanged.
Binding life-time
Practically all NAT implementations need to store some information about its state to recognize response packets and change them accordingly. This state information is called binding.
These bindings have a time-to-live (TTL) that is implementation-specific and may also depend on the used port number and the count of transmitted packets (e.g. DNS responses have a shorter lifetime than other packets). Also stateful firewalls that do not perform NAT store a “binding” that has a specific time-to-live. That means that if there is no response (or new request) on a open binding, the binding is closed after some time and responses or new requests no longer can traverse the router or firewall.
It also means that an incoming packet can received only after a binding was opened earlier.
Problems resulting from router behavior
Payload establishment
The private IP address used in the SDP c-line and port(s) used in the m-line(s) are not changed by the NAT, because they are belonging to the UDP data.
This private IP is received by the other telephony endpoint (peer). The peer is not able to use this address as destination address for its payload.
Furthermore even if the address was correct, an open binding may be needed to pass a firewall.
Routing of responses and new requests within the dialog
Also the SIP signaling is affected. The SIP RFC states that responses must to be sent back to the port used in the topmost Via-Header (or to the default port 5060 if no port is present).
So if the NAT router changes the port, the response cannot be sent back to the client. The same applies for new requests within the dialog (e.g. a BYE send by the called party).
If the ITSP works in proxy mode and does not add the “Record-Route” header, there is another problem for these requests:
The called party sends new requests within the dialog directly to the peer (the caller), e.g. a BYE request to release the call.
In most configurations, the NAT router or firewall then has no open binding and cannot forward the request to the telephony system.
Registration
For incoming call the telephony system has to register itself at the ITSP. The address where incoming calls should be routed to is written to the Contact-Header of the SIP REGISTER request. If a private IP address is used that cannot be used by the ITSP, so no incoming calls are possible.
Possible Solutions
Application Layer Gateways
There are devices with “Application layer gateway” (ALG) functionality, that also inspect the UDP data for IP addresses and thus change SIP and SDP data. Experience shows that those devices are unreliable very often, so it is best to switch of any ALG functionality.
STUN (RFC 3489, RFC 5389)
One solution to solve this problem is that the endpoint finds out how the private transport address is changed by the NAT router. Therefore, the STUN protocol exists. A public STUN server responds to requests with an answer that contains the public address it has seen in the IP/UDP header of the request. Other protocols that query the NAT router for the public address directly are not used widespread due to security considerations (UPnP) or are still in draft state (Midcom).
Remote (provider-side) solutions: SBC, symmetric response routing
Another solution is to ignore the addresses in SIP and SDP data and just route responses and payload back to the originating address seen in the IP/UDP header. Obviously, this only works if at least one endpoint uses a public IP address and only one side uses this mechanism and the other starts with sending payload. Many ITSPs use media gateways (sometimes also called Session Border Controllers - SBC) that implement this (far-end NAT support or symmetric response routing).
To address all the problems mentioned in section 1.4, the ITSP has to support symmetric response routing for media, SIP responses (see also rport, section 2.4), SIP Requests (add Record-Route if working in proxy mode) and SIP Registration (store received IP and UDP source address as contact instead of the contact-header).
rport (RFC 3581)
The rport mechanism changes the SIP routing behavior, so that responses can be received through a NAT even if private addresses are used in the SIP headers. It does not offer a solution for SIP registration and RTP establishment.
For those interested, some more details: The SIP RFC specifies that responses to requests are sent back to the IP address seen in the IP header, but to the port seen in the SIP Via: - header. To achieve this in a multi-proxy environment, every proxy adds a received-parameter containing the source IP address of the received packet to the Via-Header of a SIP message it forwards.
When the rport-Parameter is added by the client to an outgoing SIP request, the receiving proxy also fills this parameter with the source port it sees in the received UDP header and uses it to route back the responses.
Offered solutions by the HiPath / OpenScape telephony systems
Our telephony systems support STUN and can trigger payload establishment with a provider-side media gateway. (This is needed if the ITSP wants to send payload before we start sending, e.g. if the provider wants to play back an announcement like “number not available” before the local phone starts sending payload.) Furthermore, the rport mechanism is always used (if not deactivated in the ITSP profile), because it does no harm and can help in diagnostics. To keep NAT/firewall bindings open, empty UDP packets are sent to any SIP proxy and registration gateway of all registered ITSP.
STUN (RFC 3489 and RFC 5389)
NAT type detection
The STUN protocol allows the detection of the way how the router performs NAT. This NAT type detection works with most, but not all routers that are available.
Different NAT types were defined in the original STUN RFC 3489. Experience showed that these are ambiguous sometimes and the detection method specified in RFC 3489 is unreliable for some routers. For these reasons RFC 4787 introduced new terms and now distinguishes between NAT behavior and filter behavior. The new STUN RFC 5389 makes use of the new terms.
| RFC 3489 (STUN v1) | RFC 4787 (NAT behavioral requirements for UDP) |
|---|---|
| Symmetric NAT | NAT with Endpoint dependent mapping (EDM-NAT) |
| Port Restricted Cone NAT | NAT with endpoint independent mapping (EIM-NAT) and Address and Port-Dependent Filtering |
| Restricted Cone NAT | NAT with endpoint independent mapping (EIM-NAT) and Address-Dependent Filtering |
| Full Cone NAT | NAT with endpoint independent mapping (EIM-NAT) and Endpoint-Independent Filtering |
| Symmetric UDP firewall | no NAT, but filtering |
| Open Internet | No NAT, no filtering |
Tabelle 1: Comparison of old and new NAT type definitions Red STUN does not help in NAT traversal Green STUN can be used for NAT traversal Gray No NAT traversal necessary
The filter behavior is of no interest to the HiPath / OpenScape telephony system: It always assumes that it needs to open a binding to the IP address and port of its peers and thus send empty UDP packets to open connections (RTP) or keeping bindings alive (SIP registration).
Example SIP packets
Outgoing INVITE without STUN
INVITE sip:089700732559@sip2.fsys.co.uk:5060 SIP/2.0 Accept: application/sdp Via: SIP/2.0/UDP 192.168.138.70:5060;rport;branch=z9hG4bKf08fd3da8b8f1cab9 Max-Forwards: 70 From: <sip:84415955@fsys.co.uk>;tag=5509ef8b35 To: <sip:089700732559@sip2.fsys.co.uk> Call-ID: 5675ca5b59b3a97e CSeq: 1076853466 INVITE Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER, INFO Contact: <sip:192.168.138.70:5060> Supported: 100rel User-Agent: HiPath OpenOffice V3 M5T SIP Stack/4.0.26.26 X-Siemens-Call-Type: ST-insecure Content-Type: application/sdp Content-Length: 355 v=0 o=MxSIP 0 1965008630 IN IP4 192.168.138.70 s=SIP Call c=IN IP4 192.168.138.70 t=0 0 m=audio 30520 RTP/AVP 9 8 0 18 96 101 a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=rtpmap:96 AMR/8000 a=rtpmap:101 telephone-event/8000 a=silenceSupp:off - - - - a=fmtp:18 annexb=no a=fmtp:101 0-15 a=sendrecv
Figure 2 Outgoing INVITE without usage of STUN
As you can see, the own IP address is used for both SIP signaling (Contact and Via header) and payload negotiation (c and m line). The o-line also contains a private IP address, but this is not critical for payload establishment. A NAT router does not look into the packets, but changes the IP address and may change UDP port, so the addresses in SIP header and SDP body are no longer valid.
Outgoing INVITE with STUN
INVITE sip:089700732559@sip2.fsys.co.uk:5060 SIP/2.0 Accept: application/sdp Via: SIP/2.0/UDP 80.144.207.205:62600;rport;branch=z9hG4bKf0791ba4f4197c0dd Max-Forwards: 70 From: <sip:84415955@fsys.co.uk>;tag=c404812abd To: <sip:089700732559@sip2.fsys.co.uk> Call-ID: b0f373a4d6609fa9 CSeq: 1151429907 INVITE Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER, INFO Contact: <sip:80.144.207.205:62600> Supported: 100rel User-Agent: HiPath OpenOffice V3 M5T SIP Stack/4.0.26.26 X-Siemens-Call-Type: ST-insecure Content-Type: application/sdp Content-Length: 354 v=0 o=MxSIP 0 857906743 IN IP4 80.144.207.205 s=SIP Call c=IN IP4 80.144.207.205 t=0 0 m=audio 30520 RTP/AVP 9 8 0 18 96 101 a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=rtpmap:96 AMR/8000 a=rtpmap:101 telephone-event/8000 a=silenceSupp:off - - - - a=fmtp:18 annexb=no a=fmtp:101 0-15 a=sendrecv
Figure 3 Outgoing INVITE without usage of STUN
With STUN the public IP and port can be learned with a STUN Binding Request. These addresses are then inserted in SIP header and SDP body.
Behavior of the HiPath / Openscape system
Overview of the different STUN modes
Auto
The STUN component does a NAT type detection and if the result shows that STUN can be used and needs to be used it is switched on, otherwise off. In Tabelle 1 the green modes use STUN. For the red mode (symmetric UDP) STUN cannot be used, the grey modes do not need STUN, so STUN is switched off for these NAT types in AUTO mode.
Always
The NAT type detection is done, but STUN is switched on regardless of the result. The result is shown in WBM and log files, so it can be used for diagnostics.
Off
STUN is switched off completely.
Port preserving router
No NAT type detection is made. STUN gains the information of its public SIP signaling address, but does not start any request to lookup the address for payload. Instead of this, it assumes that the payload IP address is same as the SIP signaling IP address and the RTP port is not changed by the router. Practically this means that STUN monitors the public address of port 5060 by sending out a binding request frequently (every 15 seconds). No binding request is made for ITSP calls.
Static IP
This mode is similar to “Port preserving router”, but the IP address is not monitored at all. Instead of this, the address entered in WBM is used as SIP signaling address. For SDP body, the public IP is used and the port remains unchanged.
Binding opening / keep-alive
Media stream
As soon as the two endpoints of the media connection are known, the system sends out an empty UDP packet to the received media address (c and m-line in received SDP data) to open a NAT/firewall binding. This empty packet also triggers the ITSP’s media gateway to start sending payload (if in “symmetric response routing” mode).
Registration
The fully qualified domain name (FQDN) of any active ITSP that is successfully registered or needs no registration is added to a list. Every 15 the entries are resolved to one or more IP addresses. If the port is 0, DNSSRV is used for resolving. Then an empty UDP packet is sent to every gained IP address. (A multi-level cache makes sure that the impact of name resolving on system or network performance is as small as possible).
Interworking of STUN and NAT routers in practice
Port preserving routers
The biggest problems with STUN are some routers that behave non-deterministic. The NAT type detection detects a NAT that works fine, but under load the router changes it behavior. For example, a lot of routers try to preserve the port if possible. NAT type detection then usually detects a “Port restricted Cone NAT” and uses STUN. Everything is fine, until it happens that the port needs to be changed, because it is already in use by another host or was used before by the same host and the binding has not timed out yet. Some routers then fall back to a “symmetric NAT”, some keep their “Cone NAT” behavior. For the first it often helps to change the mode to “port preserving router”, for the latter the “Auto” (or “Always”) mode works better. The best solution in both cases is to open the RTP port range on the firewall/NAT router and configure a port-forwarding rule that forwards the whole range unchanged to the telephony system. Then the “Port preserving router” mode can be used reliably.
Application Layer Gateways (ALG)
Some routers offer more or less well implemented application layer gateways. An ALG looks into the packet and changes the transported addresses in the same way as it does the NAT. A good ALG needs to know the protocol to do this correctly. SIP is supported by most ALG, but sometimes the implementation has significant problems (see below). In general it is a bad idea to activate both STUN on the telephony system and ALG on the router at the same time, because they both try to do the same. While in theory a good ALG should cope with that, experience shows that this often results in really strange behavior (e.g. same ALG change the public IP inserted by STUN back to the private IP on incoming packets).
Either enable STUN (system) and disable the ALG (router) or vice versa.
Please be aware that if an ALG is used, it is the responsibility of the ALG to do the NAT traversal. Experience shows that some ALGs are badly implemented and for example cannot handle two simultaneous connections, because they mix up the used RTP ports.
Symmetric NAT
Symmetric NAT cannot be traversed by STUN, because the information gained with the help of the STUN server is not valid for packets that are sent to another server (SIP proxy). A solution would be to send the STUN requests to the SIP proxy and payload partner directly (SIP Outbound / ICE). This is currently supported by neither our telephony systems nor any ITSP we know. However, by enabling port forwarding on the router, a symmetric NAT router can be “changed” to a “port preserving router”. Open the RTP port range on the firewall/NAT router and configure a forwarding rule that the whole range is forwarded unchanged to the telephony system. Then the “Port preserving router” mode can be used reliably.
Session border controller
The term “session border controller” (SBC) is not clearly defined. In general a SBC is a device that terminates (in the sense of “communication endpoint”) both SIP signaling and RTP media stream. As such they have full control over signaling and voice payload and can and must perform NAT traversal on their own. Sometimes devices or configurations used by ITSPs are also called “SBC”. For details about these, see section 5.5. Some typical SBC features are also provided by the HiPath / Openscape telephony systems, so there is usually no need to install a SBC in the local network. If the customer whishes to install a SBC, the local network must be configured according to the SBC’s documentation and guidelines. If a SBC is used within the local network, it is recommended to disable STUN.
Far-end NAT traversal
Some ITSP use “far-end NAT traversal” mechanism like “symmetric response routing”. There are differences in their implementations, so there is no recommendation how to configure the HiPath / Openscape telephony system. Some ITSP only activates their far-end NAT traversal support, if they see known private IP address (e.g. 192.168.0.1 or any other RFC 1918)
Examples of misbehaving network devices
In this chapter some problems we had in the past are mentioned. This is neither a complete list nor a detailed analysis of the problem’s cause. It is meant to give a ‘feeling’ for the kind of problems that may occur when setting up an IP network.
NAT routers
TODO:
- port preserving with symmetric fallback
- load problems
ALG
TODO:
- Baudtec ALG
