During the initial SIP offer/answer exchange, both the originating and terminating SIP user agents (UAs) specify in the SDP payload the desired IP address and port combination for the caller and callee to receive the associated media stream and to properly direct the signaling stream. SIP UAs within the enclave may use private addressing for topology hiding reasons. A problem occurs when private addressing is used within the SDP payload since the private address is not resolvable from the WAN side of the NAT.
A traditional NAT device will change the IP source address and/or port combination at packet header level, but not the IP address within the SDP payload. Consequently, the callee, or UA in the remote enclave, will not have the correct IP address to respond to from a signaling perspective and the call setup will fail. Even if the call is established from a signaling perspective, the bearer stream would be sent to the wrong address/port and the session would not be established.
SIP INVITE example:
INVITE sip:2222222;phone -context=telecom.com@telecom.com;user =phone SIP/2.0 Via: SIP/2.0/TLS clientA.telecom.com:5061;branch=z9hG4bK74bf9 Max-Forwards: 70 To: <2222222;phone -context=telecom.com@telecom.com;user =phone> From: <1111111;phone -context=telecom.com@telecom.com;user =phone>;tag=9fxced76sl Call -ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:1111111@10.10.10.1> Contact-Type: application/sdp Content-Length: 142 c=IN IP4 10.10.10.10 m=audio 49170 RTP/SAVP 0 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 FIGURE 19.1
An additional problem is that the signaling and bearer paths are different IP sessions, and NAT bindings in a traditional NAT appliance are fi nite in nature (not correlated). A scenario may result in that a VoIP session may continue for many minutes with active RTP streams, but with no signaling messages. Since there is no signaling, the signaling NAT binding could time out and the session would not be able to terminate properly.
Difficulties experienced by SIP signaling and real-time transport protocol/real-time control protocol (RTP/RTCP) media protocols passing through firewalls stem mainly from the fact that bearer stream port numbers are selected dynamically for each call from a large pool of potential port numbers. Allowing this large range of potential port numbers to be open at the enclave boundary is unacceptable. The SBC needs to know which ports to open temporarily, when to open them and when to close them. Placing this functionality (essentially an application level gateway) into data fi rewalls has not happened yet and carries with it some disadvantages, for example, having the firewall perform actions it is not supposed to handle.