d responses to this user would be sent back to the client at address 192.0.1.2 port 23131. An incoming INVITE or other request would be routed over this open TCP connection. The ability to specify in SDP a "symmetric" RTP session [15] has been proposed as a solution for some NAT traversal problems. Since a client behind a NAT can usually successfully send RTP packets to another client in the public Internet, in a symmetric mode, RTP sent in the other direction could be sent to the address and port that RTP was received from. For example, consider an SDP offer in an INVITE sent by the UAC which supports this connection-oriented media extension: o=client 28908445312 28908445312 IN IP4 10.1.2.23 t=0 0 C=IN IP4 10.1.2.23 m=audio 49172 RTP/AVP 0 a=rtpmap: 0 PCMU/8000 a=direction:active IN IP4 If the UAS supports this extension, it will wait for RTP packets to be received from the client behind the NAT before sending. The answer SDP will o=client 28908445214 28908445214 IN IP4 client.public.org t=0 0 C=IN IP4 client.public.org m=audio 54332 RTP/AVP 0 a=rtpmap 0 PCMU/8000 SIP: Understanding the Session Initiation Protocol a=direction:passive IN IP4 The direction attribute in the answer tells the UAC that the UAS supports the symmetric RTP extension. The UAS will then send its RTP pack- ets to the IP address and port number received from the UAC which overrides the unreachable 10.1.2.23 address and 49172 port number in the SDP. Finally, it is assumed that RTP Control Protocol (RTCP) packets (see Section 7.2) are received on one port higher than the RTP port number. If STUN or TURN is used to obtain port numbers, this consecutive numbering may not be possible if the NAT is mapping port numbers as well. Also, RTCP may need to be sent to an entirely different IP address. A solution to this is an explicit RTCP port number and possibly IP address in SDP extension [16]. This allows RTCP to still be received in these cases. For example, a UAC behind a NAT could include the attribute: a=rtcp: 53020 IN IP4 126.16.64.4 A UAS suppo