Since SIP was developed, guidelines for protocol design to make them more
NAT “friendly” have been developed by the IETF [4]. Unfortunately, SIP vio-
lates most of these newer guidelines. For example, one of the major recom-
mendations of this document is that application layer protocols should not
transport IP addresses and port numbers. The next example shows why this is
a major problem for routing SIP and resulting Real-time Transport Protocol
(RTP) sessions through a NAT. In this INVITEgenerated from behind a NAT,
the fields in bold represent IP addresses that cannot be routed across a globally
addressed network such as the Internet.
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 10.1.1.221:5060;branch=z9hG4bKhjh
From: TheBigGuy <sip:[email protected]>;tag=343kdw2
To: TheLittleGuy <sip:[email protected]>
Max-Forwards: 70
Call-ID: 123456349fijoewr
CSeq: 1 INVITE
Subject: Wow! It Works...
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: ...v=0
o=UserA 2890844526 2890844526 IN IP4 UserA.customer.com
c=IN IP4 10.1.1.221
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000Because of the presence of the NAT:
■■ The response to this request could not be routed back to the originator
because of the inability to route these private network address ranges
defined for use on private internal networks (based on an incorrect Via
header).
■■ Future requests during this session would be misrouted (based on an
incorrect Contactheader).
■■ RTP packets sent by user B would be misrouted (based on an incorrect
connection IP address c=for the media in the Session Description Pro-
tocol, or SDP).Note also that the two port numbers contained in this INVITE, port 5060
and port 49170, also may be changed by the NAT and may cause signaling or
media exchange to fail.
If the NAT is being used for security purposes, the amount of topology leak-
age shown in this INVITEwould not be acceptable to a network administra-
tor, as shown in Figure 10.1.
NAT and Firewall Traversal 175