Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
understanding-SIP.pdf
Скачиваний:
115
Добавлен:
01.03.2016
Размер:
3.99 Mб
Скачать

Network Address Translation

249

• Detecting generic ALGs, which rewrite IP addresses.

This new usage defines a number of minor extensions to STUN and will shortly be standardized. Note that this usage of STUN has some limitations in that it can only characterize a NAT for a particular address at a particular time. Since a NAT can change its behavior for different addresses and at a later time, care must be taken in using the information derived from these tests.

10.10 UNSAF Requirements

With a number of peer-to-peer protocols such as SIP attempting to fix and work around NAT problems, the Internet Architecture Board (IAB) published RFC 3424 [11] setting the requirements and limitations on IETF solutions to deal with NAT. These approaches are known as Unilateral Self-Address Fixing or UNSAF approaches, the acronym being chosen to highlight the fact that these approaches could, if not done correctly, make the NAT problem worse. Each protocol that tries to work around NATs must clearly scope the problem and describe the exit strategy and transition plan. The approach must discuss specific issues that might make the approach “brittle” or likely to fail. The approach must also discuss known practical issues encountered with real NAT in deployments.

10.11 SIP Problems with NAT

Consider the typical example of a SIP UA behind a NAT trying to communicate with a SIP server outside the NAT. Since SIP has some client/server properties, some SIP operations will work as long as the requests are originated by the UA. Requests originated by the SIP server may be blocked by lack of mappings or filtering rules. One approach used in practice is to use frequent SIP registrations to create the mapping and then reuse the mapping for incoming requests to the UA. However, this approach doesn’t quite work without some SIP extensions as we shall see. Media negotiated using SIP offer answer is a big problem as the SDP offer and answer will contain private addresses and ports in the c= and m= lines. An example SIP message sent from behind a NAT is shown here:

INVITE sip:UserB@there.com SIP/2.0

Via: SIP/2.0/UDP 10.1.1.221:5060;branch=z9hG4bKhjh

From: TheBigGuy <sip:UserA@customer.com>;tag=343kdw2

To: TheLittleGuy <sip:UserB@there.com>

Max-Forwards: 70

Call-ID: 123456349fijoewr

CSeq: 1 INVITE

Subject: Wow! It Works...

Contact: <sip:UserA@10.1.1.221>

250

SIP: Understanding the Session Initiation Protocol

Content-Type: application/sdp

Content-Length: ...

v=0

o=UserA 2890844526 2890844526 IN IP4 UserA.customer.coms=- t=0 0

c=IN IP4 10.1.1.221 m=audio 49170 RTP/AVP 0

a=rtpmap:0 PCMU/8000

There are three main problems with this message. The Via header field contains a private IP address (10.1.1.221) and the listening port (5060) may not have an active mapping or filter rule. The Contact URI is unroutable due to the private IP address. Finally, the SDP information in the c= and m= lines will not work behind the NAT.

Via already has a partial solution for the response routing. The use of the received parameter will record the mapped public IP address, which is then used for routing the response. However, this will only work for a port preservation NAT (which is not recommended NAT behavior). A normal NAT that also changes the port will not work. The Contact URI problem is even more serious. If the request is a REGISTER, the AOR binding will not work since the URI is unroutable. If the request is an INVITE, the ACK and all subsequent requests such as BYE will also fail to route.

There are three main solutions to these problems: symmetric SIP, connection reuse, and SIP outbound. Each of these will be discussed in the following sections.

10.11.1 Symmetric SIP

Symmetric SIP operation uses the rport extension defined in RFC 3581 [12]. Just as the received Via parameter saves the mapped address, the rport parameter saves the mapped port number for use in routing responses. A SIP UA indicates support for this extension by including the rport parameter (without the “=” and an address which is not known) in the SIP request. This tells the next hop proxy that the UA will be listening for the response on the same address and port number that the request was sent from, instead of the address and port listed in the Via. When the proxy receives the request, it stores the mapped port in the rport parameter and then uses this for routing any responses back. The use of rport is shown in Figure 10.1.

10.11.2 Connection Reuse

Connection reuse is a method in SIP to reuse existing TCP connections. It is defined in [13]. Once a connection is opened, UAs can reuse the connection for subsequent connections. If a NAT traversal approach such as ICE is used, con-

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]