- •Contents
- •Foreword to the First Edition
- •Preface to the Third Edition
- •Preface to the Second Edition
- •Preface to the First Edition
- •1 SIP and the Internet
- •1.1 Signaling Protocols
- •1.2.2 Data/Link Layer
- •1.2.3 Network Layer
- •1.2.4 Transport Layer
- •1.2 Internet Multimedia Protocol Stack
- •1.2.1 Physical Layer
- •1.2.5 Application Layer
- •1.2.6 Utility Applications
- •1.2.7 Multicast
- •1.3 Internet Names
- •1.4 URLs, URIs, and URNs
- •1.5 Domain Name Service
- •1.5.1 DNS Resource Records
- •1.5.2 Address Resource Records (A or AAAA)
- •1.5.3 Service Resource Records (SRV)
- •1.5.4 Naming Authority Pointer Resource Records (NAPTR)
- •1.5.5 DNS Resolvers
- •1.6 Global Open Standards
- •1.7 Internet Standards Process
- •1.8 A Brief History of SIP
- •1.9 Conclusion
- •References
- •2 Introduction to SIP
- •2.1 A Simple Session Establishment Example
- •2.2 SIP Call with a Proxy Server
- •2.3 SIP Registration Example
- •2.4 SIP Presence and Instant Message Example
- •2.5 Message Transport
- •2.5.1 UDP Transport
- •2.5.2 TCP Transport
- •2.5.3 TLS Transport
- •2.5.4 SCTP Transport
- •2.6 Transport Protocol Selection
- •2.7 Conclusion
- •2.8 Questions
- •References
- •3 SIP Clients and Servers
- •3.1 SIP User Agents
- •3.2 Presence Agents
- •3.3 Back-to-Back User Agents
- •3.4 SIP Gateways
- •3.5 SIP Servers
- •3.5.1 Proxy Servers
- •3.5.2 Redirect Servers
- •3.5.3 Registrar Servers
- •3.6 Uniform Resource Indicators
- •3.7 Acknowledgment of Messages
- •3.8 Reliability
- •3.9 Multicast Support
- •3.10 Conclusion
- •3.11 Questions
- •References
- •4 SIP Request Messages
- •4.1 Methods
- •4.1.1 INVITE
- •4.1.2 REGISTER
- •4.1.5 CANCEL
- •4.1.6 OPTIONS
- •4.1.7 SUBSCRIBE
- •4.1.8 NOTIFY
- •4.1.9 PUBLISH
- •4.1.10 REFER
- •4.1.11 MESSAGE
- •4.1.12 INFO
- •4.1.13 PRACK
- •4.1.14 UPDATE
- •4.2 URI and URL Schemes Used by SIP
- •4.2.1 SIP and SIPS URIs
- •4.2.2 Telephone URLs
- •4.2.3 Presence and Instant Messaging URLs
- •4.3 Tags
- •4.4 Message Bodies
- •4.5 Conclusion
- •4.6 Questions
- •References
- •5 SIP Response Messages
- •5.1 Informational
- •5.1.1 100 Trying
- •5.1.2 180 Ringing
- •5.1.3 181 Call is Being Forwarded
- •5.1.4 182 Call Queued
- •5.1.5 183 Session Progress
- •5.2 Success
- •5.2.2 202 Accepted
- •5.3 Redirection
- •5.3.1 300 Multiple Choices
- •5.3.2 301 Moved Permanently
- •5.3.3 302 Moved Temporarily
- •5.3.4 305 Use Proxy
- •5.3.5 380 Alternative Service
- •5.4.3 402 Payment Required
- •5.4.4 403 Forbidden
- •5.4.5 404 Not Found
- •5.4.6 405 Method Not Allowed
- •5.4.7 406 Not Acceptable
- •5.4.8 407 Proxy Authentication Required
- •5.4.9 408 Request Timeout
- •5.4.11 410 Gone
- •5.4.12 411 Length Required
- •5.4.13 412 Conditional Request Failed
- •5.4 Client Error
- •5.4.1 400 Bad Request
- •5.4.2 401 Unauthorized
- •5.4.14 413 Request Entity Too Large
- •5.4.15 414 Request-URI Too Long
- •5.4.16 415 Unsupported Media Type
- •5.4.17 416 Unsupported URI Scheme
- •5.4.18 417 Unknown Resource Priority
- •5.4.19 420 Bad Extension
- •5.4.20 421 Extension Required
- •5.4.21 422 Session Timer Interval Too Small
- •5.4.22 423 Interval Too Brief
- •5.4.23 428 Use Identity Header
- •5.4.24 429 Provide Referror Identity
- •5.4.25 430 Flow Failed
- •5.4.26 433 Anonymity Disallowed
- •5.4.27 436 Bad Identity-Info Header
- •5.4.29 438 Invalid Identity Header
- •5.4.30 439 First Hop Lacks Outbound Support
- •5.4.31 440 Max-Breadth Exceeded
- •5.4.32 470 Consent Needed
- •5.4.33 480 Temporarily Unavailable
- •5.4.34 481 Dialog/Transaction Does Not Exist
- •5.4.35 482 Loop Detected
- •5.4.36 483 Too Many Hops
- •5.4.37 484 Address Incomplete
- •5.4.38 485 Ambiguous
- •5.4.39 486 Busy Here
- •5.4.40 487 Request Terminated
- •5.4.41 488 Not Acceptable Here
- •5.4.42 489 Bad Event
- •5.4.43 491 Request Pending
- •5.4.44 493 Request Undecipherable
- •5.4.45 494 Security Agreement Required
- •5.5 Server Error
- •5.5.1 500 Server Internal Error
- •5.5.2 501 Not Implemented
- •5.5.3 502 Bad Gateway
- •5.5.4 503 Service Unavailable
- •5.5.5 504 Gateway Timeout
- •5.5.6 505 Version Not Supported
- •5.5.7 513 Message Too Large
- •5.5.8 580 Preconditions Failure
- •5.6 Global Error
- •5.6.1 600 Busy Everywhere
- •5.6.2 603 Decline
- •5.6.3 604 Does Not Exist Anywhere
- •5.6.4 606 Not Acceptable
- •5.7 Questions
- •References
- •6 SIP Header Fields
- •6.1 Request and Response Header Fields
- •6.1.1 Accept
- •6.1.2 Accept-Encoding
- •6.1.3 Accept-Language
- •6.1.4 Alert-Info
- •6.1.5 Allow
- •6.1.6 Allow-Events
- •6.1.7 Answer-Mode
- •6.1.8 Call-ID
- •6.1.9 Contact
- •6.1.10 CSeq
- •6.1.11 Date
- •6.1.12 Encryption
- •6.1.13 Expires
- •6.1.14 From
- •6.1.15 History Info
- •6.1.16 Organization
- •6.1.17 Path
- •6.1.19 Record-Route
- •6.1.20 Recv-Info
- •6.1.21 Refer-Sub
- •6.1.22 Retry-After
- •6.1.23 Subject
- •6.1.24 Supported
- •6.1.25 Timestamp
- •6.1.27 User-Agent
- •6.2 Request Header Fields
- •6.2.1 Accept-Contact
- •6.2.2 Authorization
- •6.2.3 Call-Info
- •6.2.4 Event
- •6.2.5 Hide
- •6.2.6 Identity
- •6.2.7 Identity-Info
- •6.2.8 In-Reply-To
- •6.2.9 Info-Package
- •6.2.10 Join
- •6.2.11 Priority
- •6.2.12 Privacy
- •6.2.13 Proxy-Authorization
- •6.2.14 Proxy-Require
- •6.2.15 P-OSP-Auth-Token
- •6.2.16 P-Asserted-Identity
- •6.2.17 P-Preferred-Identity
- •6.2.18 Max-Breadth
- •6.2.19 Max-Forwards
- •6.2.20 Reason
- •6.2.21 Refer-To
- •6.2.22 Referred-By
- •6.2.23 Reply-To
- •6.2.24 Replaces
- •6.2.25 Reject-Contact
- •6.2.26 Request-Disposition
- •6.2.27 Require
- •6.2.28 Resource-Priority
- •6.2.29 Response-Key
- •6.2.30 Route
- •6.2.31 RAck
- •6.2.32 Security-Client
- •6.2.33 Security-Verify
- •6.2.34 Session-Expires
- •6.2.35 SIP-If-Match
- •6.2.36 Subscription-State
- •6.2.37 Suppress-If-Match
- •6.2.38 Target-Dialog
- •6.2.39 Trigger-Consent
- •6.3 Response Header Fields
- •6.3.1 Accept-Resource-Priority
- •6.3.2 Authentication-Info
- •6.3.3 Error-Info
- •6.3.4 Flow-Timer
- •6.3.5 Min-Expires
- •6.3.7 Permission-Missing
- •6.3.8 Proxy-Authenticate
- •6.3.9 Security-Server
- •6.3.10 Server
- •6.3.11 Service-Route
- •6.3.12 SIP-ETag
- •6.3.13 Unsupported
- •6.3.14 Warning
- •6.3.15 WWW-Authenticate
- •6.3.16 RSeq
- •6.4 Message Body Header Fields
- •6.4.1 Content-Encoding
- •6.4.2 Content-Disposition
- •6.4.3 Content-Language
- •6.4.4 Content-Length
- •6.4.5 Content-Type
- •6.4.6 MIME-Version
- •6.5 Questions
- •References
- •7 Wireless, Mobility, and IMS
- •7.1 IP Mobility
- •7.2 SIP Mobility
- •7.4 IMS Header Fields
- •7.5 Conclusion
- •7.6 Questions
- •References
- •8 Presence and Instant Messaging
- •8.1 Introduction
- •8.2 History of IM and Presence
- •8.3 SIMPLE
- •8.4 Presence with SIMPLE
- •8.4.1 SIP Events Framework
- •8.4.2 Presence Bodies
- •8.4.3 Resource Lists
- •8.4.4 Filtering
- •8.4.6 Partial Publication
- •8.4.7 Presence Documents Summary
- •8.5 Instant Messaging with SIMPLE
- •8.5.1 Page Mode Instant Messaging
- •8.5.4 Message Composition Indication
- •8.5.5 Multiple Recipient Messages
- •8.5.6 Session Mode Instant Messaging
- •8.6 Jabber
- •8.6.1 Standardization as Extensible Messaging and Presence Protocol
- •8.6.2 Interworking with SIMPLE
- •8.6.3 Jingle
- •8.6.4 Future Standardization of XMPP
- •8.7 Conclusion
- •8.8 Questions
- •References
- •9 Services in SIP
- •9.1 Gateway Services
- •9.2 SIP Trunking
- •9.3 SIP Service Examples
- •9.4 Voicemail
- •9.5 SIP Video
- •9.6 Facsimile
- •9.7 Conferencing
- •9.7.1 Focus
- •9.7.2 Mixer
- •9.8 Application Sequencing
- •9.9 Other SIP Service Architectures
- •9.9.1 Service Oriented Architecture
- •9.9.2 Servlets
- •9.9.3 Service Delivery Platform
- •9.10 Conclusion
- •9.11 Questions
- •References
- •10 Network Address Translation
- •10.1 Introduction to NAT
- •10.2 Advantages of NAT
- •10.3 Disadvantages of NAT
- •10.4 How NAT Works
- •10.5 Types of NAT
- •10.5.1 Endpoint Independent Mapping NAT
- •10.5.2 Address Dependent Mapping NAT
- •10.5.3 Address and Port Dependent Mapping NAT
- •10.5.4 Hairpinning Support
- •10.5.5 IP Address Pooling Options
- •10.5.6 Port Assignment Options
- •10.5.7 Mapping Refresh
- •10.5.8 Filtering Modes
- •10.6 NAT Mapping Examples
- •10.7 NATs and SIP
- •10.8 Properties of a Friendly NAT or How a NAT Should BEHAVE
- •10.9 STUN Protocol
- •10.10 UNSAF Requirements
- •10.11 SIP Problems with NAT
- •10.11.1 Symmetric SIP
- •10.11.2 Connection Reuse
- •10.11.3 SIP Outbound
- •10.12 Media NAT Traversal Solutions
- •10.12.1 Symmetric RTP
- •10.12.2 RTCP Attribute
- •10.12.3 Self-Fixing Approach
- •10.13 Hole Punching
- •10.14 TURN: Traversal Using Relays Around NAT
- •10.15 ICE: Interactive Connectivity Establishment
- •10.16 Conclusion
- •10.17 Questions
- •References
- •11 Related Protocols
- •11.1 PSTN Protocols
- •11.1.1 Circuit Associated Signaling
- •11.1.2 ISDN Signaling
- •11.1.3 ISUP Signaling
- •11.2 SIP for Telephones
- •11.3 Media Gateway Control Protocols
- •11.4.1 Introduction to H.323
- •11.4.2 Example of H.323
- •11.4.3 Versions
- •References
- •12 Media Transport
- •12.1 Real-Time Transport Protocol (RTP)
- •12.2 RTP Control Protocol (RTCP)
- •12.2.1 RTCP Reports
- •12.2.2 RTCP Extended Reports
- •12.3 Compression
- •12.4.1 Audio Codecs
- •12.4.2 Video Codecs
- •12.5 Conferencing
- •12.6 ToIP—Conversational Text
- •12.7 DTMF Transport
- •12.8 Questions
- •References
- •13 Negotiating Media Sessions
- •13.1 Session Description Protocol (SDP)
- •13.1.1 Protocol Version
- •13.1.2 Origin
- •13.1.3 Session Name and Information
- •13.1.5 E-Mail Address and Phone Number
- •13.1.6 Connection Data
- •13.1.7 Bandwidth
- •13.1.8 Time, Repeat Times, and Time Zones
- •13.1.9 Encryption Keys
- •13.1.10 Media Announcements
- •13.1.11 Attributes
- •13.2 SDP Extensions
- •13.3 The Offer Answer Model
- •13.3.1 Rules for Generating an Offer
- •13.3.2 Rules for Generating an Answer
- •13.3.3 Rules for Modifying a Session
- •13.3.4 Special Case—Call Hold
- •13.4 Static and Dynamic Payloads
- •13.5 SIP Offer Answer Exchanges
- •13.6 Conclusion
- •13.7 Questions
- •References
- •14 SIP Security
- •14.1 Basic Security Concepts
- •14.1.1 Encryption
- •14.1.2 Public Key Cryptography
- •14.1.4 Message Authentication
- •14.2 Threats
- •14.3 Security Protocols
- •14.3.1 IPSec
- •14.3.3 DNSSec
- •14.3.4 Secure MIME
- •14.4 SIP Security Model
- •14.4.1 SIP Digest Authentication
- •14.4.2 SIP Authentication Using TLS
- •14.4.3 Secure SIP
- •14.4.4 Identity
- •14.4.5 Enhanced SIP Identity
- •14.6 Media Security
- •14.6.1 Non-RTP Media
- •14.6.2 Secure RTP
- •14.6.3 Keying SRTP
- •14.6.4 Best Effort Encryption
- •14.6.5 ZRTP
- •14.7 Questions
- •References
- •15 Peer-to-Peer SIP
- •15.1 P2P Properties
- •15.2 P2P Properties of SIP
- •15.3 P2P Overlays
- •15.4 RELOAD
- •15.5 Host Identity Protocol
- •15.6 Conclusion
- •15.7 Questions
- •References
- •16 Call Flow Examples
- •16.1 SIP Call with Authentication, Proxies, and Record-Route
- •16.2 SIP Call with Stateless and Stateful Proxies with Called Party Busy
- •16.3 SIP to PSTN Call Through Gateways
- •16.4 PSTN to SIP Call Through a Gateway
- •16.5 Parallel Search
- •16.6 Call Setup with Two Proxies
- •16.7 SIP Presence and Instant Message Example
- •References
- •17 Future Directions
- •17.2 More Extensions
- •17.3 Better Identity
- •17.4 Interdomain SIP
- •17.5 Making Features Work Better
- •17.6 Emergency Calling
- •17.7 More SIP Trunking
- •17.9 Improved NAT Traversal
- •17.10 Security Deployment
- •17.11 Better Interoperability
- •References
- •A.1 ABNF Rules
- •A.2 Introduction to XML
- •References
- •About the Author
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Network Address Translation |
239 |
|||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 10.1 NAT example.
NAT, however, creates a new mapping between the source inside private address 10.0.0.1 port 42723 and the outside public address 172.34.5.1 port 34123 and rewrites the IP and transport layers with this information. When the SIP response comes back, the NAT uses the mapping created to rewrite the IP and transport layers with this information. As a result, the SIP server thinks the SIP client it is communicating with it at the address 172.34.5.1:34123 while the SIP client thinks it is using the address 10.0.0.1:42723. Since we have seen how SIP imbeds IP addresses and ports into SIP and SDP messages, clearly this will be problematic.
10.5 Types of NAT
NAT can be characterized by the type of address and port mapping they do, as well as the type of filtering they employ. To see the different types of NAT, we will use the notation shown in Figure 10.2 from RFC 4787 [6]. This figure shows a host X behind a NAT communicating with two different hosts, host 1 and host 2. Packets sent by X have a source address and port of X:x and a destination address and port of Y:y. The NAT has a number of IP addresses to use for mapping, and they are shown as X1, X2, ... (some NATs only have a single IP address to use for mapping such as a home NAT). Packets sent from device X to host 1 are sent by X to Y1:y1 from X;x. As received by Y1, the packets appear
240 |
|
|
SIP: Understanding the Session Initiation Protocol |
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 10.2 NAT mapping classifications.
to have been received from X1’:x1’. Packets sent by X to Y2 from the same source port x are received by Y2 and appear to have been received from X2’:x2’. That the packets sent to Y2 are sent from the same IP address and port as Y2 is essential for this classification method. The resulting relationship between X1’:x1’ and X2’:x2’ determines the type of NAT mapping.
Note that NAT classification is not precise, and many NATs change behavior over time and under differing conditions. As a result, trying to predict future NAT behavior based on past behavior is problematic. However, a good understanding of NAT behavior is still essential to understanding how to make SIP and Internet communications traverse NAT.
10.5.1 Endpoint Independent Mapping NAT
Endpoint independent mapping (EIM) NAT is where X1’:x1’ = X2’:x2’ for all Y;y (Y1:y1 and Y2:y2 as shown in Figure 10.2). That is, the mapping used is dependent only on the source address and port (X;x), independent of the destination address and port. This type of mapping is known as endpoint independent mapping (EIM). It is important to note that x1’ does not equal x1, which means that a NAPT can be an endpoint independent NAT. This type of NAT is best for SIP and RTP traversal as we shall see in the next sections.
10.5.2 Address Dependent Mapping NAT
An address dependent mapping (ADM) NAT is where X1’:x1’ = X2’:x2’ if and only if Y2 = Y1 in Figure 10.2. That is, the mapping is dependent on the destina-
Network Address Translation |
241 |
tion IP address of the packet as well as the source address and port. As a result, packets sent by X to different hosts will appear to come from different IP addresses and/or port numbers. This type of NAT is bad for SIP and RTP traversal as we shall see in the following sections.
10.5.3 Address and Port Dependent Mapping NAT
An address and port dependent mapping (ADPM) NAT is where X1’:x1’ = X2’:x2’ if and only if Y2:y2 = Y1:y1 as shown in Figure 10.2. That is, the mapping is dependent on both the destination address and port as well as the source address and port. As a result, packets sent by X to different ports on the same host will appear to come from different IP addresses and/or port numbers. This type of NAT is the most problematic for SIP and RTP traversal.
10.5.4 Hairpinning Support
Hairpinning is shown in Figure 10.3. Any NAT will allow hosts on the inside of the NAT (sometimes described as behind the same NAT) to use the private address of the other host—these packets can be routed by the NAT without any modification. A NAT supports hairpinning if an internal host can send packets to another internal host using the external address of the other host. Packets routed this way double back on the NAT giving a shape similar to a hairpin. To route these packets, the NAT must lookup two mappings to determine the destination. In the example, X has a mapping X:x to X1’:x1’ while Z has a mapping Z;z to X2’:x2’. Hairpinning is supported by the NAT if Z receives a packet sent by X from X;x to X2’:x2’ and vice versa. Support of hairpinning is very beneficial to SIP and RTP traversal. Note that this property is also sometimes called tromboning after the shape of the slide of the instrument.
Figure 10.3 Hairpinning support in NAT.
242 |
SIP: Understanding the Session Initiation Protocol |
10.5.5 IP Address Pooling Options
NATs that have a number of external or public IP addresses available for mapping have options in the way they allocate from this pool of IP addresses. Having multiple IP addresses is common in large service provider or enterprise NATs and is uncommon in small residential NATs. One pooling policy is known as paired IP address pooling. This policy means that only one external IP address is used for an internal IP address. As a result, all packets sent by this host will appear to come from the same IP address to hosts external to the NAT. This property is very good for SIP and RTP traversal. Another policy is known as arbitrary IP address pooling, which means there could be multiple external IP addresses mapped to an internal IP address. This property is very bad for SIP and RTP transport.
10.5.6 Port Assignment Options
While only NATs that have multiple external IP addresses have address pooling options, every NAT has port assignment options. There are a number of behaviors that are part of implemented NATs. Port preservation means the NAT tries to keep the external port the same as the internal source port. This port assignment approach generally only works if the NAT has a large pool of IP addresses. Otherwise, only one inside host can use a particular port. If a NAT implementing port preservation runs out of a particular port to allocate, it can use one of two strategies. One is to switch to a nonport preservation mode. The other is to do port overloading in which the same port can be used more than once on the inside and outside. Port overloading is very bad for the SIP and RTP transport because it leads to nondeterministic behavior. Another port assignment option is port parity, which preserves the oddness or evenness of ports. This is useful for media transport where the RTP media must be an even port while the RTCP control must use an odd port number. Port contiguity is when the NAT attempts to keep sequential inside ports mapped to sequential outside ports. This can help when an RTCP port is inferred to be one higher than the RTP port. For SIP and RTP traversal, the most important property is that the port assignment mode does not change. Since port preservation always runs the risk of having to switch modes or do port overloading, it is not recommended. Switching port mapping modes makes troubleshooting difficult.
10.5.7 Mapping Refresh
Each time a NAT creates a mapping it uses up memory resources in storing the information. It also uses up addressing resources since the external mapped IP address and port cannot be reused for another endpoint. As a result, a NAT must
