Why is NAT such a big deal for SIP communications:
- Although one SIP device is nominally the client device and another is nominally the server, all SIP end-points may need to act as a server or client at certain points in the dialogue – for example, the client device may initiate a call, but the server may end it.
- SIP requests may be relayed through a series of SIP Proxy servers (similar to email being relayed by SMTP servers)
- If Proxy servers want to be kept in the signalling path, they add a special “Record-Route” header containing their own address. They must respect any existing Record-Route headers.
- SIP requests always contain a “Request URI address” which describes the ultimate destination, but SIP devices and SIP Proxies may relay the request to an intermediate address which they know will relay it to the final destination.
- SIP requests contain IP addresses embedded in various headers and also in the SDP payload – see below for details
- The media path may not be the same as the SIP signalling path. The end points for the media are given in the SDP payload. The idea is that the media path needs to be as direct as possible, but the SIP signalling is less susceptible to latency so it is acceptable for it to go via a more convoluted path (e.g. via a billing server)
- SIP requests contain a Via header to tell the destination which IP address (and port) to send their replies. The source device that constructs the SIP request may not be aware of NAT traversal further downstream so is likely to specify its own local IP in the Via. To alleviate this known problem, many SIP devices have features (e.g. STUN) to allow them to examine their own networking environment and determine if they are behind NAT. It is also quite common to be able to manually program the device with an “external” IP address.
- The port specified in the Via address does not have to be the same as the port that the request was sent from.
- SIP requests contain a Contact header which specifies the address where the sending device can be reached by the remote end-point when the remote end-point wants to initiate a new request (as opposed to responding to the existing request, which is handled by the Via)
If you want some further reading on this topic, please take a look at the following articles on the Smartvox knowledgebase:
