Document: draft-ietf-sipping-nat-scenarios-08 Reviewer: Dan Wing Review Date: 5/30/2008 Review Due: 5/23/2008 Review Type: WGLC Summary: Overall a strong document. My review is below. Meta comments: --------------- * Solution Profiles seems to be not terribly useful. I think you're trying to get vendors to declare their products are compliant with the General or Consumer or Minimal profiles, but I doubt that will really occur. If you want to keep this idea, I would, instead, show what happens and what breaks with different combinations of ICE/STUN/Symmetric/RFC3605. For example, does it matter if RFC3605/rtcpmux isn't implemented (usually not). * There is too much wiggle room between allowing RFC3605 or rtcpmux. The WG needs to decide what the recommendation should be for these -- MUST 3605 and SHOULD rtcpmux, perhaps? * section ordering needs to be tweaked a bit (see my comment below). * This document discusses mostly media; should the title be changed to reflect that, perhaps "NAT Traversal for SIP media" ^^^^^ Comments: --------- > SIPPING Working Group C. Boulton, Ed. > Internet-Draft Avaya > Expires: October 27, 2008 J. Rosenberg > Cisco Systems > G. Camarillo > Ericsson > April 25, 2008 Missing "intended-status", which I guess from the title is BCP. > > > Best Current Practices for NAT Traversal for SIP > draft-ietf-sipping-nat-scenarios-08 ... Section 2: > destination for the response is correct, the port contained in the > SIP 'Via' header represents the listening port of the originating > client and not the port representing the open pin hole on the NAT. > This results in responses being sent back to the NAT but to a port > that is likely not open for SIP traffic. The SIP response will then > be dropped at the NAT. This is illustrated in Figure 1 which depicts > a SIP response being returned to port 5060. [dwing: the above text assumes a NAT that does not contain a SIP-aware ALG. This assumption should be clearly stated, as there are NATs on the market that incorporate SIP-aware ALGs and for which much of this document does not necessarily apply. Similarly, it should also be pointed out that SBC doing 'hosted NAT traversal' makes much of this document moot. Reference draft-ietf-sipping-sbc-funcs-05.txt and, if you like, also reference draft-ietf-mmusic-media-path-middleboxes.] > > > Private NAT Public > Network | Network > | > | > -------- SIP Request |open port 10923 -------- > | |-------------------->--->-----------------------| | > | | | | | > | Client | |port 5060 SIP Response | Proxy | > | | x<------------------------| | > | | | | | > -------- | -------- > | > | > | > > > Figure 1: Failed Response > > Secondly, when using a reliable, connection orientated transport > protocol such as TCP, SIP has an inherent mechanism that results in > SIP responses reusing the connection that was created/used for the > corresponding transactional request. Change above sentence to start with: "Secondly, there are two cases where new requests re-use existing connections. The first is ..." [and continue with the existing text] > The SIP protocol does not > provide a mechanism that allows new requests generated in the reverse > direction of the originating client to use, for example, the existing > TCP connection created between the client and the server during > registration. This results in the registered contact address not > being bound to the "connection" in the case of TCP. Requests are > then blocked at the NAT, as illustrated in Figure 2. This problem > also exists for unreliable transport protocols such as UDP where Change last sentence to start with: "The second case is when unreliable transport ..." > external NAT mappings need to be re-used to reach a SIP entity on the > private side of the network. ... > > Private NAT Public > Network | Network > | > | > -------- (UAC 8023) REGISTER/Response (UAS 5060) -------- > | |-------------------->---<-----------------------| | > | | | | | > | Client | |5060 INVITE (UAC 8015)| Proxy | > | | x<------------------------| | > | | | | | > -------- | -------- > | > | > | > > Figure 2: Failed Request > > In Figure 2 the original REGISTER request is sent from the client on > port 8023 and received on port 5060, establishing a reliable > connection and opening a pin-hole in the NAT. "Reliable connection" often means TCP; however, I don't believe that was the author's intent. Maybe just drop "reliable"? (of course, UDP itself is connectionless, so perhaps 'connection' is still not quite right). > The generation of a > new request from the proxy results in a request destined for the > registered entity (Contact IP address) which is not reachable from > the public network. This results in the new SIP request attempting > to create a connection to a private network address. This problem > would be solved if the original connection was re-used. While this > problem has been discussed in the context of connection orientated > protocols such as TCP, the problem exists for SIP signaling using any > transport protocol. The impact of connection reuse of connection > orientated transports (TCP, TLS, etc) is discussed in more detail in > the connection reuse specification[I-D.ietf-sip-connect-reuse]. The > approach proposed for this problem in Section 3 of this document is > relevant for all SIP signaling, regardless of the transport protocol. The last sentence implies that this document supersedes connect-reuse; I don't believe that is the intent of this document. I suggest rewording to soften the statement. > NAT policy can dictate that connections should be closed after a > period of inactivity. This period of inactivity may vary from a > number seconds to hours. SIP signaling can not be relied upon to > keep alive connections for the following two reasons. Firstly, SIP > entities can sometimes have no signaling traffic for long periods of > time which has the potential to exceed the inactivity timer, and this > can lead to problems where endpoints are not available to receive > incoming requests as the connection has been closed. Secondly, if a > low inactivity timer is specified, SIP signaling is not appropriate > as a keep-alive mechanism as it has the potential to add a large > amount of traffic to the network which uses up valuable resource and > also requires processing at a SIP stack, which is also a waste of > processing resources. > > Media associated with SIP calls also has problems traversing NAT. > > RTP [RFC3550] "runs over UDP and" > is one of the most common media transport types used in > SIP signaling. Negotiation of RTP occurs with a SIP session > establishment using the Session Description Protocol(SDP) [RFC2327] > and a SIP offer/answer exchange[RFC3264]. During a SIP offer/answer > exchange an IP address and port combination are specified by each > client in a session as a means of receiving media such as RTP. The > problem arises when a client advertises its address to receive media > and it exists in a private network that is not accessible from > outside the NAT. Figure 3 illustrates this problem. > > > NAT Public Network NAT > | | > | | > | | > -------- | SIP Signaling Session | -------- > | |----------------------->---<--------------------| | > | | | | | | > | Client | | | | Client | > | A |>=====>RTP>==Unknown Address==>X | | B | > | | | X<==Unknown Address== -------- | | -------- > | | > | | > | | > > > Figure 3: Failed Media > > The connection addresses of the clients behind the NATs will > nominally contain a private IPv4 or IPv6 address that is not routable > across the public Internet. Exacerbating matters even more would be > the tendency of Client A to send media to a destination address it > received in the signaling confirmation message -- an address that may > actually correspond to a host within the private network who is > suddenly faced with incoming RTP packets (likewise, Client B may send > media to a host within its private network who did not solicit these > packets.) And finally, to complicate the problem even further, a > number of different NAT topologies with different default behaviors > increases the difficulty of arriving at a single approach. Add something to the effect of: "This problem exists for all media transport protocols that might be NATted (e.g., TCP, UDP, SCTP, DCCP)." Otherwise, it will be assumed by many readers that we only need to solve this for UDP. ... Section 3.1.1: > Client B would normally respond to the port available in the SIP Via > header, as illustrated in Figure 1. Client B honors the 'rport' > parameter in the SIP Via header and routes the response to port from > which it was sent. The exact functionality for this method of > response traversal is called 'Symmetric Response' and the details are > documented in RFC 3581 [RFC3581]. Additional requirements are > imposed on SIP entities in this specification such as listening and ^^^^^^^^^^^^^^^^^^ change to: "RFC3581" > sending SIP requests/responses from the same port. > > 3.1.2. Re-use of Connections ... > Guidelines for devices such as User Agents that can only generate > outbound connections through a NAT are documented in 'SIP Conventions > for UAs with Outbound Only Connections'[I-D.ietf-sip-outbound]. The > document provides techniques that use a unique User Agent instance > identifier (instance-id) in association with a flow identifier > (reg-id). The combination of the two identifiers provides a key to a > particular connections (both UDP and TCP) that are stored in > association with registration bindings. On receiving an incoming > request to a SIP Address-Of-Record (AOR), a proxy/registrar routes to > the associated flow created by the registration and thus a route > through a NAT. It also provides a keepalive mechanism for clients to > keep NAT bindings alive. This is achieved by multiplexing a relative > ping/pong mechanism over the SIP signaling connection (STUN for UDP > and CRLF/operating system keepalive for reliable transports like > TCP). Usage of this specification is RECOMMENDED. This mechanism is ^^^^^^^^^^^^^^^^^^ [I-D.ietf-sip-outbound] ... > 3.2.1. Symmetric RTP/RTCP > > The primary problem identified in Section 2 of this document is that > internal IP address/port combinations can not be reached from the > public side of a NAT. In the case of media such as RTP, this will > result in no audio traversing a NAT (as illustrated in Figure 3). To > overcome this problem, a technique called 'Symmetric' RTP/RTCP can be > used. This involves an SIP endpoint both sending and receiving RTP/ > RTCP traffic from the same IP Address/Port combination. This > technique is known as 'Symmetric RTP/RTCP' and is documented in RFC > 4961 [RFC4961]. 'Symmetric RTP/RTCP' SHOULD only solely be used for > traversal of RTP through NAT when one of the participants in a media > session definitively knows that it is on the public network. [dwing: I don't know what the intent of this SHOULD is. The implication is that somebody is using Symmetric RTP/RTCP as their sole NAT traversal mechanism. But even if one party is absolutely on the public Internet, the sole use of Symmetric RTP/RTCP will not the endpoints traverse a NAT; the endpoints would still need something else (such as the endpoint behind the NAT doing STUN, but even thast doesn't work if that endpoint's NAT is symmetric or address dependent). The only way that Symmetric RTP/RTCP works, by itself, is if the other endpoint ignores the SDP and assumes any incoming RTP packets are from the intended peer - that is, it does 'latching' as described by draft-ietf-mmusic-media-path-middleboxes-00. This often happens when the other endpoint is an SBC. What is important to say is that Symmetric RTP/RTCP is important for EVERYTHING that might want to traverse a NAT or speak with an endpoint that is behind a NAT - even if the remote endpoint is an SBC performing 'hosted NAT traversal'.] > > 3.2.1.1. RTCP > > Normal practice when selecting a port for defining Real Time Control > Protocol(RTCP) [RFC3550] is for consecutive order numbering (i.e > select an incremented port for RTCP from that used for RTP). This > assumption causes RTCP traffic to break when traversing many NATs due ^^^^^^^^^ > to blocked ports. "many NATs" could mean "going through a bunch of NATs", but that isn't the intent. I suggest "certain types of NATs". ... > 3.2.2. STUN > > Simple Traversal of Underneath Network Address Translators(NAT) or > STUN is defined in RFC 3489bis [I-D.ietf-behave-rfc3489bis]. STUN is > a lightweight tool kit and protocol that provides details of the > external IP address/port combination used by the NAT device to > represent the internal entity on the public facing side of a NAT. On > learning of such an external representation, a client can use it > accordingly as the connection address in SDP to provide NAT > traversal. Using terminology defined in the draft 'NAT Behavioral > Requirements for Unicast UDP' [RFC4787], STUN does work with > 'Endpoint Independent Mapping' but does not work with either 'Address > Dependent Mapping' or 'Address and Port Dependent Mapping' type NATs. > Using STUN with either of the previous two NAT mappings to probe for > the external IP address/port representation will provide a different > result to that required for traversal by an alternative SIP entity. > The IP address/port combination deduced for the STUN server would be > blocked for incoming packets from an alterative SIP entity. ^^^^^^^^^^ alternative > > As mentioned in Section 3.1.2, STUN is also used as a client-to- > server keep-alive mechanism to refresh NAT bindings. > > 3.2.3. TURN > > As described in the Section 3.2.2, the STUN protocol does not work > for UDP traversal through certain identified NAT mappings. > 'Obtaining Relay Addresses from Simple Traversal of UDP Through NAT > (known as TURN)' is a usage of the STUN protocol for deriving (from a > STUN server) an address that will be used to relay packet towards a > client. TURN provides an external address (globally routable) at a > STUN server that will act as a media relay which guarantees traffic ^^^^^^^^^^ "guarantee" is a strong word. How about "all but guarantees". > will reach the associated internal address. The full details of the > TURN specification are defined in [I-D.ietf-behave-turn]. A TURN > service will almost always provide media traffic to a SIP entity but > it is RECOMMENDED that this method only be used as a last resort and > not as a general mechanism for NAT traversal. This is because using > TURN has high performance costs when relaying media traffic and can > lead to unwanted latency. > > 3.2.4. ICE > > Interactive Connectivity Establishment (ICE) is the RECOMMENDED > method for traversal of existing NAT if Symmetric RTP is not > appropriate. (Once we resolve my questions about Symmetric RTP/RTCP, the sentence above will need to be aligned accordingly.) > ICE is a methodology for using existing technologies > such as STUN, TURN and any other UNSAF[RFC3424] compliant protocol to > provide a unified solution. It is true that ICE can use an UNSAF mechanism to learn public IP addresses and ports. But an ICE endpoint can also use non-IETF mechanisms (e.g., NAT-PMP, UPnP IGD) to learn public IP addresses and ports, and populate a=candidate lines with that information. It would be good to point that out in this ICE summary. ... > This is achieved by obtaining as many > representative IP address/port combinations as possible using > technologies such as STUN/TURN etc. Once the addresses are > accumulated, they are all included in the SDP exchange in a new media > attribute called 'candidate'. Each 'candidate' SDP attribute entry > has detailed connection information including a media addresses, > priority, transport. The appropriate IP address/port combinations > are used in the correct order depending on the specified priority. A > client compliant to the ICE specification will then locally run > instances of STUN servers on all addresses being advertised using > ICE. Each instance will undertake connectivity checks to ensure that > a client can successfully receive media on the advertised address. > Only connections that pass the relevant connectivity checks are used > for media exchange. The full details of the ICE methodology are > contained in [I-D.ietf-mmusic-ice]. > > An extension to ICE is also available for TCP based media > interactions and is documented in 'TCP Candidates with Interactive > Connectivity Establishment (ICE)'[I-D.ietf-mmusic-ice-tcp]. > 3.2.5. Solution Profiles > > This draft has documented a number of technology solutions for the > traversal of media through differing NAT deployments. A number of > 'profiles' will now be defined that categorize varying levels of > support for the technologies described. > > 3.2.5.1. Primary Profile > > A client falling into the 'Primary' profile supports ICE in > conjunction with STUN, TURN usage and RFC 3605 [RFC3605] and/or > [I-D.ietf-avt-rtp-and-rtcp-mux] for RTCP. The "and/or" is complicated -- can I do rtp/rtcp multiplexing and not ICE/STUN/TURN? I suggest something like: "A client with the 'Primary' profile MUST support ICE, STUN, and TURN; additionally it MUST support RFC3605 or [I-D.ietf-avt-rtp-and-rtcp-mux] or both." > ICE is used in all cases > and falls back to standard operation when dealing with non-ICE > clients. A client which falls into the 'Primary' profile will be > maximally interoperable and function in a rich variety of > environments including enterprise, consumer and behind all varieties > of NAT. > > It is RECOMMENDED that symmetric RTP and symmetric RTCP always be > used for bidirectional RTP media streams. What about unidirectional RTP media streams (music on hold, media playout from voicemail server), where one side is 'sendonly'? Do we recommend that symmetric RTP/RTCP *not* be used, or are we purposefully silent on this point because there is a reason someone should not use symmetric RTP/RTCP? I believe this is a MUST-level requirement (not a RECOMMENDED-level requirement), and that ICE and an SBC's 'hosted NAT traversal' will not work without Symmetric RTP/RTCP. > 3.2.5.2. Consumer Profile > > A client falling into the 'Consumer' profile supports STUN and RFC > 3605 [RFC3605] and/or [I-D.ietf-avt-rtp-and-rtcp-mux] for RTCP. The "and/or" is complicated. I suggest: A client with the 'Consumer' profile MUST support STUN; additionally it MUST support either RFC3605 or [I-D.ietf-avt-rtp-and-rtcp-mux] or both. > It > uses STUN to allocate bindings, and can also detect when it is behind > an Address Dependant or Address and Port Dependant NAT, although it > simply cannot function in this case. These clients will only work in > deployment situations where the access is sufficiently controlled to > know definitively that there won't be Symmetric NAT. This is hard to > guarantee as users can always pick up their client and connect via a > different access network. > > It is RECOMMENDED that symmetric RTP and symmetric RTCP always be > used for bidirectional RTP media streams. I believe this is a MUST-level requirement (not a RECOMMENDED-level requirement), and that ICE and an SBC's 'hosted NAT traversal' will not work without Symmetric RTP/RTCP. > 3.2.5.3. Minimal Profile > > A client falling into the 'Minimal' profile will send/receive RTP/ > RTCP from the same IP/port combination. This client requires > proprietary network based solutions to function in any NAT traversal > scenario. Instead of 'proprietary network based solutions', I suggest referencing draft-ietf-mmusic-media-path-middleboxes. "In order for the minimal profile to work when the endpoint is behind a NAT, the endpoint MUST implement symmetric RTP/RTCP." This was shown correctly in the table, but there was not text saying so. (As all of the profiles need Symmetric RTP/RTCP, you may want to bump it up to a requirement common among all profiles.) > In summary, the following table provides a representation of the > profiles: > > | Primary | Consumer | Minimal | > | Profile | Profile | Profile | > ---------+----------+----------+---------+ > ICE | Yes | No | No | > ---------+----------+----------+---------+ > STUN | Yes | Yes | No | > ---------+----------+----------+---------+ > TURN Use | Yes | No | No | > ---------+----------+----------+---------+ > RFC3605 | Yes | Yes | No | > ---------+----------+----------+---------+ > Symm. RTP| Yes | Yes | Yes | > (RFC4961)| | | | > ---------+----------+----------+---------+ The table needs to include RTP/RTCP multiplexing; I suggest something like this (which will probably need to be a
rather than a ): | Primary | Consumer | Minimal | ----------+---------+-----------+----------+ ICE | Yes | No | No | ----------+---------+-----------+----------+ STUN | Yes | Yes | No | ----------+---------+-----------+----------+ TURN | Yes | No | No | ----------+---------+-----------+----------+ RFC3605 | | | No | ----------+ Yes + Yes +----------+ RTP/RTCP | | | No | mux | | | | ----------+---------+-----------+----------+ RFC4961 | Yes | Yes | Yes | ----------+---------+-----------+----------+ > Figure 5: Profiles > > All clients SHOULD support the 'Primary Profile', MUST support the > 'Minimal Profile' and MAY support the 'Consumer Profile'. > > > 4. NAT Traversal Scenarios > > This section of the document includes detailed NAT traversal > scenarios for both SIP signaling and the associated media. > > 4.1. Basic NAT SIP Signaling Traversal > > The following sub-sections concentrate on SIP signaling traversal of > NAT. The scenarios include traversal for both reliable and un- > reliable transport protocols. > > 4.1.1. Registration (Registrar/Proxy Co-Located) > > The set of scenarios in this section document basic signaling > traversal of a SIP REGISTER method through a NAT. > > 4.1.1.1. UDP > > > Client NAT Proxy > | | | > |(1) REGISTER | | > |----------------->| | > | | | > | |(1) REGISTER | > | |----------------->| > | | | > | |(2) 401 Unauth | > | |<-----------------| > | | | > |(2) 401 Unauth | | > |<-----------------| | > | | | > |(3) REGISTER | | > |----------------->| | > | | | > | |(3) REGISTER | > | |----------------->| > | | | > |*************************************| > | Create Outbound Connection Tuple | > |*************************************| > | | | > | |(4) 200 OK | > | |<-----------------| > | | | > |(4) 200 OK | | > |<-----------------| | > | | | > > > Figure 6 This is the first (of two) "Figure 6" figures. > In this example the client sends a SIP REGISTER request through a NAT > which is challenged using the Digest authentication scheme. The > client will include an 'rport' parameter as described in > Section 3.1.1 of this document for allowing traversal of UDP > responses. The original request as illustrated in (1) in Figure 6 is > a standard REGISTER message: > > > REGISTER sip:proxy.example.com SIP/2.0 > Via: SIP/2.0/UDP client.example.com:5060;rport;branch=z9hG4bK > Max-Forwards: 70 > Supported: path,gruu > From: Client ;tag=djks8732 > To: Client > Call-ID: 763hdc73y7dkb37@example.com > CSeq: 1 REGISTER > Contact: ;reg-id=1 > ;+sip.instance="" > Content-Length: 0 > > This proxy now generates a SIP 401 response to challenge for > authentication, as depicted in (2) from Figure 5: > > SIP/2.0 401 Unauthorized > Via: SIP/2.0/UDP client.example.com:5060 > ;rport=8050;branch=z9hG4bK;received=192.0.1.2 > From: Client ;tag=djks8732 > To: Client ;tag=876877 > Call-ID: 763hdc73y7dkb37@example.com > CSeq: 1 REGISTER > WWW-Authenticate: [not shown] > Content-Length: 0 This example would be more valuable if the ladder diagram in Figure 6 showed port numbers. The point of this example is to show that the "rport" causes the SIP proxy to place the source UDP port into the Via of the SIP response, but that isn't clear with the example. > The response will be sent to the address appearing in the 'received' > parameter of the SIP 'Via' header (address 192.0.1.2). The response > will not be sent to the port deduced from the SIP 'Via' header, as > per standard SIP operation but will be sent to the value that has > been stamped in the 'rport' parameter of the SIP 'Via' header (port > 8050). For the response to successfully traverse the NAT, all of the > conventions defined in RFC 3581 [RFC3581] MUST be obeyed. Make note > of both the 'connectionID' and 'sip.instance' contact header > parameters. They are used to establish an Outbound connection tuple > as defined in [I-D.ietf-sip-outbound]. The connection tuple creation > is clearly shown in Figure 5. This ensures that any inbound request > that causes a registration lookup will result in the re-use of the > connection path established by the registration. This exonerates the > need to manipulate contact header URI's to represent a globally > routable address as perceived on the public side of a NAT. The > subsequent messages defined in (3) and (4) from Figure 5 use the same > mechanics for NAT traversal. > > 4.1.1.2. Reliable Transport > > > > Client NAT Registrar > | | | > |(1) REGISTER | | > |----------------->| | > | | | > | |(1) REGISTER | > | |----------------->| > | | | > | |(2) 401 Unauth | > | |<-----------------| > | | | > |(2) 401 Unauth | | > |<-----------------| | > | | | > |(3) REGISTER | | > |----------------->| | > | | | > | |(3) REGISTER | > | |----------------->| > | | | > |*************************************| > | Create Outbound Connection Tuple | > |*************************************| > | | | > | |(4) 200 OK | > | |<-----------------| > | | | > |(4) 200 OK | | > |<-----------------| | > | | | > > Figure 6. This is the second "Figure 6". ... > Registrar. The important message to note is (5) in Figure 7. The > Edge proxy, on receiving a REGISTER request that contains a > 'sip.instance' media feature tag, forms a unique flow identifier > token as discussed in [I-D.ietf-sip-outbound]. At this point, the > proxy server routes the SIP REGISTER message to the Registrar. The > proxy will create the connection tuple as described in SIP Outbound > at the same moment as the co-located example, but for subsequent > messages to arrive at the Proxy, the element needs to request to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > remain in the SIP signaling path. To achieve this the proxy inserts ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Change highlighted text to: "... the proxy needs to indicate its need to remain in the SIP signaling path." > to REGISTER message (5) a SIP PATH extension header, as defined in > RFC 3327 [RFC3327]. The previously created flow association token is > inserted in a position within the Path header where it can easily be > retrieved at a later point when receiving messages to be routed to > the registration binding (in this case the user part of the SIP URI). > The REGISTER message of (5), when proxied in (6) looks as follows: ... > 4.1.4.2. Registrar/Proxy Not Co-located > > The core SIP signaling associated with this call flow is not impacted > directly by the transport protocol and so only one example scenario > is necessary. The example uses TCP and follows on from the > registration installed in the example from Section 4.1.2. I believe by 'core SIP signaling' you are referring to the SIP signaling that occurs in the 'core' of the network (behind the user's SIP proxy), rather than the 'core' specifications that define SIP signaling. It would be helpful to clarify, perhaps by rewording to something like: The SIP signaling on the interior of the network (behind the user's proxy) is not impacted directly .... > 4.2. Basic NAT Media Traversal Basic = "Minimal Profile" ?? > This section provides example scenarios to demonstrate basic media ^^^^^ "Minimal Profile"? > traversal using the techniques outlined earlier in this document. > > In the flow diagrams STUN messages have been annotated for simplicity > as follows: > o The "Src" attribute represents the source transport address of the > message. > o The "Dest" attribute represents the destination transport address > of the message. > o The "Map" attribute represents the server reflexive (XOR-MAPPED- > ADDRESS STUN attribute) transport address. > o The "Rel" attribute represents the relayed (RELAY-ADDRESS STUN > attribute) transport address. > > The meaning of each STUN attribute is extensively explained in the > core STUN[I-D.ietf-behave-rfc3489bis] and TURN > usage[I-D.ietf-behave-turn] drafts. > > A number of ICE SDP attributes have also been included in some of the > examples. Detailed information on individual attributes can be > obtained from the core ICE specification[I-D.ietf-mmusic-ice]. > > The examples also contain a mechanism for representing transport > addresses. It would be confusing to include representations of > network addresses in the call flows and make them hard to follow. > For this reason network addresses will be represented using the > following annotation. The first component will contain the > representation of the client responsible for the address. For > example in the majority of the examples "L" (left client), "R" (right > client), NAT-PUB" (NAT public), PRIV (Private), and "STUN-PUB" (STUN > Public) are used. To allow for multiple addresses from the same > network element, each representation can also be followed by a > number. These can also be used in combination. For example "L-NAT- > PUB-1" would represent a public network address on the left hand side ^^^^^^^^^^^^^^^^^^^^^ "of the left" > NAT while "R-NAT-PUB-1" would represent a public network address in ^^ "of" > the right hand side of the NAT. "L-PRIV-1" would represent a private ^^^^^^^^^^^^^^^^^^^^^^ "right NAT" > network address on the left hand side of the NAT while "R-PRIV-1" > represents a private address on the right hand side of the NAT. > > It should also be noted that during the examples it might be > appropriate to signify an explicit part of a transport address. This > is achieved by adding either the '.address' or '.port' tag on the end > of the representation. For example, 'L-PRIV-1.address' and 'L-PRIV- > 1.port'. Need to add an explanation of the "$" substitution that is used in the examples, too. ... > > 4.2.1.1.1. Initiating Session > > The following example demonstrates media traversal through a NAT with > 'Address Independent' properties using the STUN 'Binding Discovery' > usage. It is assumed in this example that the STUN client and SIP > Client are co-located on the same physical machine. Note that some > SIP signaling messages have been left out for simplicity. > > > > Client NAT STUN [..] > Server > | | | | > |(1) BIND Req | | | > |Src=L-PRIV-1 | | | > |Dest=STUN-PUB | | | > |----------------->| | | > | | | | > | |(2) BIND Req | | > | |Src=NAT-PUB-1 | | > | |Dest=STUN-PUB | | > | |----------------->| | > | | | | > | |(3) BIND Resp | | > | |<-----------------| | > | |Src=STUN-PUB | | > | |Dest=NAT-PUB-1 | | > | |Map=NAT-PUB-1 | | > | | | | > |(4) BIND Resp | | | > |<-----------------| | | > |Src=STUN-PUB | | | > |Dest=L-PRIV-1 | | | > |XOR=NAT-PUB-1 | | | ^^^^^^^^^^^^^ "Map=NAT-PUB-1" > | | | | > |(5) BIND Req | | | > |Src=L-PRIV-2 | | | > |Dest=STUN-PUB | | | > |----------------->| | | ... > o On deciding to initiate a SIP voice session the client starts a > local STUN client on the interface and port that is to be used for > media (send/receive). The STUN client generates a standard > 'Binding Discovery' request as indicated in (1) from Figure 7 > which also highlights the source address and port for which the > client device wishes to obtain a mapping. The 'Binding Discovery' > request is sent through the NAT towards the public internet and > STUN server. > o Message (2) traverses the NAT and breaks out onto the public > internet towards the public STUN server. Note that the source > address of the 'Binding Discovery' request now represents the > public address and port from the public side of the NAT. > o The STUN server receives the request and processes it > appropriately. This results in a successful 'Binding Discovery' > response being generated and returned (3). The message contains > details of the XOR mapped public address (contained in the STUN > XOR-MAPPED-ADDRESS attribute) which is to be used by the > originating client to receive media (see 'Map=NAT-PUB-1' from > (3)). The bullets above would be much easier to follow if they showed which steps they applied to, for example I find the following easier to read (I only added step numbers and left the text intact): 1. On deciding to initiate a SIP voice session the client starts a local STUN client on the interface and port that is to be used for media (send/receive). The STUN client generates a standard 'Binding Discovery' request as indicated in (1) from Figure 7 which also highlights the source address and port for which the client device wishes to obtain a mapping. The 'Binding Discovery' request is sent through the NAT towards the public internet and STUN server. 2. Message (2) traverses the NAT and breaks out onto the public internet towards the public STUN server. Note that the source address of the 'Binding Discovery' request now represents the public address and port from the public side of the NAT. 3. The STUN server receives the request and processes it appropriately. This results in a successful 'Binding Discovery' response being generated and returned (3). The message contains details of the XOR mapped public address (contained in the STUN XOR-MAPPED-ADDRESS attribute) which is to be used by the originating client to receive media (see 'Map=NAT-PUB-1' from (3)). 4-8. The 'Binding Discovery' response traverses back through the NAT using the path created by the 'Binding Discovery' request and presents the new XOR mapped address to the client (4). At this point the process is repeated to obtain a second XOR-mapped address (as shown in (5)-(8)) for an alternative local address (Address has changed from "L-PRIV-1" to "L-PRIV-2") for an RTCP port. 9. The client now constructs a SIP INVITE message(9). Note that traversal of SIP is not covered in this example and is discussed in earlier sections of the document. The INVITE request will use the addresses it has obtained in the previous STUN transactions to ... (If you're using xml2rfc, you can use list style=hanging and hangText to do this.) I have the same suggestion for the bulleted items below Figure 8. > o The 'Binding Discovery' response traverses back through the NAT > using the path created by the 'Binding Discovery' request and > presents the new XOR mapped address to the client (4). At this > point the process is repeated to obtain a second XOR-mapped > address (as shown in (5)-(8)) for an alternative local address ^^^^^^^^^^^ "second" (RTCP is not an "alternative" to RTP. "Additional" or "second" would be good words and I see you already used "second", so I stuck with that.) > o The client now constructs a SIP INVITE message(9). Note that > traversal of SIP is not covered in this example and is discussed > in earlier sections of the document. The INVITE request will use ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ add citation to specific section number. > the addresses it has obtained in the previous STUN transactions to ... > o Note that the XOR-mapped address obtained from the 'Binding > Discovery' transactions are inserted as the connection address for > the SDP (c=NAT-PUB-1.address). The Primary port for RTP is also ^ "$" > inserted in the SDP (m=audio NAT-PUB-1.port RTP/AVP 0). Finally, ^ "$" > the port gained from the additional 'Binding Discovery' is placed > in the RTCP attribute (as discussed in Section 3.2.1.1) for > traversal of RTCP (a=rtcp:NAT-PUB-2.port). ^ "$" > o The SIP signaling then traverses the NAT and sets up the SIP > session (9-12). Note that the client transmits media as soon as ^^^^^^^^^^ The left client or the right client? > the 200 OK to the INVITE arrives at the client (12). Up until ^^^^^^^^^^^^^ The left client or the right client? > this point the incoming media and RTCP will not pass through the > NAT as no outbound association has been created with the far end > client. Two way media communication has now been established. But of course two-way media can't be established until the SDP Answer is received anyway; this should be pointed out -- it's important to see that things are not _terribly_ worse with all of the ICE chit-chat. > 4.2.1.1.2. Receiving Session Invitation > > Receiving a session for an 'Endpoint Independent' NAT using the STUN > 'Binding Discovery' usage is very similar to the example outlined in > Section 4.2.1.1.1. Figure 8 illustrates the associated flow of > messages. > > > > Client NAT STUN [..] > Server > | | | (1)SIP INVITE | > | |<-----------------|------------------| ^ "-" (use a "-" here, otherwise it appears the SIP INVITE is being handled by the STUN server.) (Have you considered using "-" to indicate media path messages and using "=" to indicate SIP path messages?) ... > o The 'Binding Discovery' response traverses back through the NAT > using the path created by the outgoing 'Binding Discovery' request > and presents the new XOR-mapped address to the client (6). At > this point the process is repeated to obtain a second XOR-mapped > address (as shown in (7)-(10)) for an alternative local address ^^^^^^^^^^^ "second" (same comment as earlier.) > (local port has now changed and is represented by L-PRIV-2 in (7)) > for an RTCP port. > o The client now constructs a SIP 200 OK message (11) in response to > the original SIP INVITE requests. Note that traversal of SIP is > not covered in this example and is discussed in earlier sections > of the document. SIP Provisional responses are also left out for ^^^^^^^^^^^^^^^ please provide specific section number. > simplicity. The 200 OK response will use the addresses it has > obtained in the previous STUN transactions to populate the SDP of > the SIP 200 OK as shown below: > > v=0 > o=test 2890844526 2890842807 IN IP4 $L-PRIV-1.address > c=IN IP4 $NAT-PUB-1.address > t=0 0 > m=audio $NAT-PUB-1.port RTP/AVP 0 > a=rtcp:$NAT-PUB-2.port > > > o Note that the XOR-mapped address obtained from the initial > 'Binding Discovery' transaction is inserted as the connection > address for the SDP (c=NAT-PUB-1.address). The Primary port for > RTP is also inserted in the SDP (m=audio NAT-PUB-1.port RTP/AVP > 0). Finally, the port gained from the additional 'Binding ^^^^^^^^^^ "second" > Discovery' is placed in the RTCP attribute (as discussed in > Section 3.2.1.1) for traversal of RTCP (a=rtcp:NAT-PUB-2.port). > o The SIP signaling then traverses the NAT and sets up the SIP > session (11-14). Note that the client transmits media as soon as ^^^^^^^^^^ "R" > the 200 OK to the INVITE is sent to the UAC(11). Up until this ^^^^^^^^^^^ "L" > point the incoming media will not pass through the NAT as no > outbound association has been created with the far end client. > Two way media communication has now been established. > ... > 4.2.1.2.1. Initiating Session > > The following example demonstrates an initiating traversal through an > 'Endpoint independent' NAT using ICE. > > > > L NAT STUN NAT R ^^^^ "STUN/TURN" > Server > | | | | | > |(1) Alloc Req | | | | > |Src=L-PRIV-1 | | | | > |Dest=STUN-PUB-1 | | | | > |--------------->| | | | > | | | | | > | |(2) Alloc Req | | | > | |Src=L-NAT-PUB-1 | | | > | |Des=STUN-PUB-1 | | | ^^^ "Dest" > | |--------------->| | | > | | | | | > | |(3) Alloc Resp | | | > | |<---------------| | | > | |Src=STUN-PUB-1 | | | > | |Dest=L-NAT-PUB-1| | | > | |Map=L-NAT-PUB-1 | | | > | |Rel=STUN-PUB-2 | | | > | | | | | > |(4) Alloc Resp | | | | > |<---------------| | | | > |Src=STUN-PUB-1 | | | | > |Dest=L-PRIV-1 | | | | > |Map=L-NAT-PUB-1 | | | | > |Rel=STUN-PUB-2 | | | | > | | | | | > |(5) STUN Req | | | | > |Src=L-PRIV-2 | | | | > |Dest=STUN-PUB-1 | | | | > |--------------->| | | | > | | | | | > | |(6) Alloc Req | | | > | |Src=L-NAT-PUB-2 | | | > | |Dest=STUN-PUB-1 | | | > | |--------------->| | | > | | | | | > | |(7) Alloc Resp | | | > | |<---------------| | | > | |Src=STUN-PUB-1 | | | > | |Dest=NAT-PUB-2 | | | > | |Map=NAT-PUB-2 | | | ^^^^^^^^^ "L-NAT-PUB-2" > | |Rel=STUN-PUB-3 | | | > | | | | | > |(8) Alloc Resp | | | | > |<---------------| | | | > |Src=STUN-PUB-1 | | | | > |Dest=L-PRIV-2 | | | | > |Map=L-NAT-PUB-2 | | | | > |Rel=STUN-PUB-3 | | | | > | | | | | > |(9) SIP INVITE | | | | > |------------------------------------------------->| | > | | | | | > | | | |(10) SIP INVITE | > | | | |--------------->| It is highly unlikely, nah, I would say impossible, to expect that the two endpoints would be sending SIP directly to each other. I would like to see the SIP proxy in the ladder diagram. You might add it using a kludge like this: L L-NAT STUN/TURN R-NAT R | | | | | | | | | | | | | | | | | | | | | | - | | | | | | | | | | | | SIP proxy | | | | | | | | | | | | | | | | | | | - | | | | | | | | | | | | STUN/TURN server | | | | | | | | | | | | | | | | | | | - | | Not ideal, but it works with the formatting restrictions of RFCs and doesn't require changing all of your ladder diagram. It would additionally be clearer if you used different characters for media messages and SIP messages; I suggest "-" for media and "=" for SIP. But "." could work, too.... ... > o On deciding to initiate a SIP voice session the SIP client 'L' > starts a local STUN client. The STUN client generates a standard > Allocate request as indicated in (1) from Figure 9 which also > highlights the source address and port combination for which the > client device wishes to obtain a mapping. The Allocate request is > sent through the NAT towards the public internet. > o The Allocate message (2) traverses the NAT and breaks out onto the ^^^^^^^^^^^^^^^ "to" > public internet towards the public STUN server. Note that the > source address of the Allocate request now represents the public > address and port from the public side of the NAT (L-NAT-PUB-1). > o The STUN server receives the Allocate request and processes > appropriately. This results in a successful Allocate response > being generated and returned (3). The message contains details of > the server reflexive address which is to be used by the > originating client to receive media (see 'Map=L-NAT-PUB-1') from > (3)). It also contains an appropriate relayed address that can be > used at the STUN server (see 'Rel=STUN-PUB-2'). I would make this clearer you are using TURN here; perhaps "... appropriate TURN-relayed address ..." or something like that. > o The Allocate response traverses back through the NAT using the > binding created by the initial Allocate request and presents the > new mapped address to the client (4). The process is repeated and > a second STUN derived set of address' are obtained, as illustrated > in (5)-(8) in Figure 9. At this point the User Agent behind the > NAT has pairs of derived external server reflexive and relayed > representations. The client would be free to gather any number of > external representations using any UNSAF[RFC3424] compliant > protocol. > o The client now constructs a SIP INVITE message (9). The INVITE > request will use the addresses it has obtained in the previous > STUN/TURN interactions to populate the SDP of the SIP INVITE. > This should be carried out in accordance with the semantics > defined in the ICE specification[I-D.ietf-mmusic-ice], as shown > below in Figure 10 (*note - 'allOneLine' notation signifies line > continuation): I grepped all of the I-Ds and RFCs, and allOneLine appears to be some relatively new thing that some SIP and SIPPING drafts and RFCs have started doing. I found it very hard to read and unnecessary especially for a BCP document. (What made it even moe amusing was that the line was too long and got wrapped in my printout!) I suggest, instead, just using indentation to make your point, and have text that says "due to formatting restrictions, lines are wrapped in this document but would appear as one long line in actual SDP". Here is an example of how I would format the SDP for the document: v=0 o=test 2890844526 2890842807 IN IP4 $L-PRIV-1 c=IN IP4 $L-PRIV-1.address t=0 0 a=ice-pwd:$LPASS a=ice-ufrag:$LUNAME m=audio $L-PRIV-1.port RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=rtcp:$L-PRIV-2.port a=candidate:$L1 1 UDP 3102938476 $L-PRIV-1.address $L-PRIV-1.port typ local a=candidate:$L1 2 UDP 3010948635 $L-PRIV-2.address $L-PRIV-2.port typ local a=candidate:$L2 1 UDP 2203948363 $L-NAT-PUB-1.address $L-NAT-PUB-1.port typ srflx raddr $L-PRIV-1.address rport $L-PRIV-1.port a=candidate:$L2 2 UDP 2172635342 $L-NAT-PUB-2.address $L-NAT-PUB-2.port typ srflx raddr $L-PRIV-1.address rport $L-PRIV-2.port a=candidate:$L3 1 UDP 1763546473 $STUN-PUB-2.address $STUN-PUB-2.port typ relay raddr $L-PRIV-1.address rport $L-PRIV-1.port a=candidate:$L3 2 UDP 1109384746 $STUN-PUB-3.address $STUN-PUB-3.port typ relay raddr $L-PRIV-1.address rport $L-PRIV-2.port Another formatting choice that I have seen that works well is to use "\" to indicate a line continuation. ... > o The two clients have now exchanged SDP using offer/answer and can > now continue with the ICE processing - User Agent 'L' assuming the > role controlling agent, as specified by ICE. The clients are now > required to form their Candidate check lists to determine which > will be used for the media streams. In this example User Agent > 'L's 'Foundation 1' is paired with User Agent 'R's 'Foundation 1', > User Agent 'L's 'Foundation 2' is paired with User Agent 'R's > 'Foundation 2', and finally User Agent 'L's 'Foundation 3' is > paired with User Agent 'R's 'Foundation 3'. User Agents 'L' and > 'R' now have a complete candidate check list. Both clients now > use the algorithm provided in ICE to determine candidate pair > priorities and sort into a list of decreasing priorities. In this > example, both User Agent 'L' and 'R' will have lists that firstly > specifies the host address (Foundation $L1), then the server > reflexive address (Foundation $L2) and lastly the relayed address > (Foundation $L3). All candidate pairs have an associate state as > specified in ICE. At this stage, all of the candidate pairs for > User Agents 'L' and 'R' are initialized to the 'Frozen' state. > The User Agents then scan the list and move the candidates to the > 'Waiting' state. At this point both clients will periodically, > starting with the highest candidate pair priority, work their way > down the list issuing STUN checks from the local candidate to the > remote candidate (of the candidate pair). As a STUN Check is > attempted from each local candidate in the list, the candidate > pair state transitions to 'In-Progress'. As illustrated in (23), > client 'L' constructs a STUN connectivity check in an attempt to > validate the remote candidate address received in the SDP of the > 200 OK (20) for the highest priority in the check list. As a > private address was specified in the active address in the SDP, > the STUN connectivity check fails to reach its destination causing > a STUN failure. Client 'L' transitions the state for this > candidate pair to 'Failed'. In the mean time, Client 'L' is > attempting a STUN connectivity check for the second candidate pair > in the returned SDP with the second highest priority (24). As can > be seen from messages (24) to (29), the STUN Bind request is > successful and returns a positive outcome for the connectivity > check. Client 'L' is now free to steam media to the candidate > pair. Client 'R' also carries out the same set of binding ^ "Immediately after sending its 200 Okay," > requests. It firstly (in parallel) tries to contact the active > address contained in the SDP (30) which results in failure. (Wow, that is a lot of steps in one bullet!) > o In the mean time, a successful response to a STUN connectivity > check by User Agent 'R' (27) results in a tentative check in the > reverse direction - this is illustrated by messages (31) to (36). > Once this check has succeeded, User Agent 'R' can transition the > state of the appropriate candidate to 'Succeeded', and media can > be sent (RTP). The previously described check confirm on both ^^^^^^^^^^^^^^^^^^^^^^^^^^ There have been several previously-described checks -- which one is this referring to? > sides (User Agent 'L' and 'R') that connectivity can be achieved > using the appropriate candidate pair. User Agent 'L', as the > controlling client now sends another connectivity check for the > candidate pair, this time including the 'USE-CANDIDATE' attribute > as specified in ICE to signal the chosen candidate. This exchange > is illustrated in messages (37) to (42). > o As part of the process in this example, both 'L' and 'R' will now > complete the same connectivity checks for part 2 of the component > named for the favored 'Foundation' selected for use with RTCP. > The connectivity checks for part '2' of the candidate component > are shown in 'L'(43-48) and 'R'(49-54). Once this has succeeded, > User Agent 'L' as the controlling client sends another > connectivity check for the candidate pair. This time the 'USE- > CANDIDATE' attribute is again specified to signal the chosen > candidate for component '2'. > o The candidates have now been fully verified (and selected) and as > they are the highest priority, an updated offer (61-62) is now > sent from the offerer (client 'L') to the answerer (client 'R') > representing the new active candidates. The new offer would look > as follows: > > v=0 > o=test 2890844526 2890842808 IN IP4 $L-PRIV-1 ^^^^^^^^^ I know that "o" is mostly for grins and giggles, but would we want to leave the IP address to be the private IP address rather than the public address in the re-Invite? (I don't know the answer to this question.) > c=IN IP4 $L-NAT-PUB-1.address > t=0 0 > a=ice-pwd:$LPASS > a=ice-ufrag:$LUNAME > m=audio $L-NAT-PUB-1.port RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > a=rtcp:$L-NAT-PUB-2.port > > a=candidate:$L2 1 UDP 2203948363 $L-NAT-PUB-1.address $L-NAT-PUB-1.port typ srflx > raddr $L-PRIV-1.address rport $L-PRIV-1.port > > > a=candidate:$L2 2 UDP 2172635342 $L-NAT-PUB-2.address $L-NAT-PUB-2.port typ srflx > raddr $L-PRIV-1.address rport $L-PRIV-2.port > Why are two candidate addresses listed in the updated SDP offer? > > Figure 12: ICE SDP Updated Offer > > o The resulting answer (63-64) for 'R' would look as follows: > > v=0 > o=test 3890844516 3890842804 IN IP4 $R-PRIV-1 ^^^^^^^^^ Same question as above. > c=IN IP4 $R-PRIV-1.address ^^^^^^^^^ Should be the public port and address, I believe? Afterall, "R" is behind his NAT. > t=0 0 > a=ice-pwd:$RPASS > a=ice-ufrag:$RUNAME > m=audio $R-PRIV-1.port RTP/AVP 0 ^^^^^^^^^^^^^^ Should be the public port and address, I believe? Afterall, "R" is behind his NAT. > a=rtpmap:0 PCMU/8000 > a=rtcp:$R-PRIV-2.port > > a=candidate:$L2 1 UDP 2984756463 $R-NAT-PUB-1.address $R-NAT-PUB-1.port typ srflx > raddr $R-PRIV-1.address rport $R-PRIV-1.port > > > a=candidate:$L2 2 UDP 2605968473 $R-NAT-PUB-2.address $R-NAT-PUB-2.port typ srflx > raddr $R-PRIV-1.address rport $R-PRIV-2.port > I don't understand why there are two candidates in the SDP updated answer. > > > Figure 13: ICE SDP Updated Answer > > > > > > > > > Boulton, Ed., et al. Expires October 27, 2008 [Page 46] > > Internet-Draft NAT Scenarios April 2008 > > > 4.2.2. Address and Port Dependant NAT > > 4.2.2.1. STUN Failure > > This section highlights that while STUN is the preferred mechanism > for traversal of NAT, it does not solve every case. The use of basic > STUN on its own will not guarantee traversal through every NAT type, > hence the recommendation that ICE is the preferred option. This felt out of order. It seems you should describe STUN, how it works, why it doesn't work in all cases; then describe TURN, how it works, how it isn't ideal (because it is inefficient), and *then* describe ICE, how it works, and why it is recommended. As it is, the document describes STUN, then ICE, then STUN failures. ... > The example in Figure 14 is conveyed in the context of a client > behind the 'Port/Address Dependant' NAT initiating a call. It should > be noted that the same problem applies when a client receives a SIP > invitation and is behind a Port/Address Dependant NAT. Simplify to: The example in Figure 14 is conveyed in the context of a client behind the 'Port/Address Dependant' NAT initiating a call. The same problem applies with a SIP invitation (not shown). ... > > 4.2.2.2. TURN Usage Solution > > As identified in Section 4.2.2.1, STUN provides a useful tool kit for > the traversal of the majority of NATs but fails with Port/Address > Dependant NAT. This led to the development of the TURN usage > solution [I-D.ietf-behave-turn] which uses the STUN toolkit to create > a profile. It allows a client to request a relayed address at the > STUN server rather than a reflexive representation. This then > introduces a media relay in the path for NAT traversal (as described > in Section 3.2.3). The following example explains how the TURN usage > solves the previous failure when using STUN to traverse a 'Port/ > Address Dependant' type NAT. > > > > L Port/Address Dependant STUN [..] ^^^^ "STUN/TURN" > NAT Server > | | | | > |(1) Alloc Req | | | > |Src=L-PRIV-1 | | | > |Dest=STUN-PUB-1 | | | > |----------------->| | | > | | | | > | |(2) Alloc Req | | > | |Src=NAT-PUB-1 | | > | |Dest=STUN-PUB-1 | | > | |----------------->| | > | | | | > | |(3) Alloc Resp | | > | |<-----------------| | > | |Src=STUN-PUB-1 | | > | |Dest=NAT-PUB-1 | | > | |Map=NAT-PUB-1 | | > | |Rel=STUN-PUB-2 | | > | | | | > |(4) Alloc Resp | | | > |<-----------------| | | > |Src=STUN-PUB-1 | | | > |Dest=L-PRIV-1 | | | > |Map=NAT-PUB-1 | | | > |Rel=STUN-PUB-2 | | | > | | | | > |(5) Alloc Req | | | > |Src=L-PRIV-2 | | | > |Dest=STUN-PUB-1 | | | > |----------------->| | | > | | | | > | |(6) Alloc Req | | > | |Src=NAT-PUB-2 | | > | |Dest=STUN-PUB-1 | | > | |----------------->| | > | | | | > | |(7) Alloc Resp | | > | |<-----------------| | > | |Src=STUN-PUB-1 | | > | |Dest=NAT-PUB-2 | | > | |Map=NAT-PUB-2 | | > | |Rel=STUN-PUB-3 | | > | | | | > |(8) Alloc Resp | | | > |<-----------------| | | > |Src=STUN-PUB-1 | | | > |Dest=L-PRIV-2 | | | > |Map=NAT-PUB-2 | | | > |Rel=STUN-PUB-3 | | | > | | | | > |(9)SIP INVITE | | | > |----------------->| | | > | | | | > | |(10)SIP INVITE | | > | |------------------------------------>| > | | | | > | | |(11)SIP 200 OK | > | |<------------------------------------| > | | | | > |(12)SIP 200 OK | | | > |<-----------------| | | > | | | | > |========================================================| > |>>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>| > |========================================================| should show more clearly how this is sent from L-PRIV-1 until it hits the NAT, at which point it is now sent from L-PUB-1. > | | | | > | | |==================| > | | |<< | | |<<< | | |==================| > | | | | > |=====================================| | > | |=====================================| | should show more clearly that the TURN server sends the packets to L-PUB-1 (it can't send them to L-PRIV-1!), and the NAT forwards them to L-PRIV-1. > | | | | > | | |==================| > | | |<<| > | | |<<< | | |==================| > | | | | > |=====================================| | > |< |=====================================| | (Same comments as above -- show more clearly how the NAT is still involved and what the TURN server is doing.) > | | | | > |(13)SIP ACK | | | > |----------------->| | | > | | | | > | |(14) SIP ACK | | > | |------------------------------------>| > | | | | > > > Figure 15: Port/Address Dependant NAT with TURN Usage - Success > > o In this example, client 'L' issues a TURN allocate request(1) to > obtained a relay address at the STUN server. The request > traverses through the 'Port/Address Dependant' NAT and reaches the > STUN server (2). The STUN server generates an Allocate response > (3) that contains both a server reflexive address (Map=NAT-PUB-1) > of the client and also a relayed address (Rel=STUN-PUB-2). The > relayed address maps to an address mapping on the STUN server > which is bound to the public pin hole that has been opened on the > NAT by the Allocate request. I don't have a suggested improvement, but I found the text in the bullet above difficult to parse. There are too many pronouns and assumed meanings. > This results in any traffic sent to > the STUN server relayed address (Rel=STUN-PUB-2) being forwarded ^^^^^^^^^^^ "TURN server" > to the external representation of the pin hole created by the > Allocate request(NAT-PUB-1). > o The TURN derived address (STUN-PUB-2) arrives back at the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ "The TURN-derived addresses (STUN-PUB-2, STUN-PUB-3) > originating client(4) in an Allocate response. This address can ^^^ "(4-8)" > then be used in the SDP for the outgoing SIP INVITE request as > shown in the following example (note that the example also > includes client 'L' obtaining a second relay address for use in > the RTCP attribute (5-8)): Delete all of the text in the parenthesis. > o > > v=0 > o=test 2890844342 2890842164 IN IP4 $L-PRIV-1 > c=IN IP4 $STUN-PUB-2.address > t=0 0 > m=audio $STUN-PUB-2.port RTP/AVP 0 > a=rtcp:$STUN-PUB-3.port > > > o On receiving the INVITE request, the UAS is able to stream media > and RTCP to the relay address (STUN-PUB-2 and STUN-PUB-3) at the > STUN server. As shown in Figure 15 (between messages (12) and > (13), the media from the UAS is directed to the relayed address at > the STUN server. The STUN server then forwards the traffic to the > open pin holes in the Port/Address Dependant NAT (NAT-PUB-1 and > NAT-PUB-2). The media traffic is then able to traverse the 'Port/ > Address Dependant' NAT and arrives back at client 'L'. > o The TURN usage of STUN on its own will work for 'Port/Address > Dependent' and other types of NAT mentioned in this specification > but should only be used as a last resort. The relaying of media > through an external entity is not an efficient mechanism for NAT > traversal and comes at a high processing cost. > > 4.2.2.3. ICE Solution > > The previous two examples have highlighted the problem with using > core STUN usage for all forms of NAT traversal and a solution using > TURN usage for the Address/Port Dependant NAT case. As mentioned > previously in this document, the RECOMMENDED mechanism for traversing > all varieties of NAT is using ICE, as detailed in Section 3.2.4. (Actually, it wasn't recommended previously.) But, really, I think it was the "Primary Profile" that was really recommended, right -- not just ICE? > ICE > makes use of core STUN, TURN usage and any other UNSAF[RFC3424] > compliant protocol to provide a list of prioritized addresses that > can be used for media traffic. Detailed examples of ICE can be found > in Section 4.2.1.2.1. These examples are associated with an > 'Endpoint Independent' type NAT but can be applied to any NAT type > variation, including 'Address/Port Dependant' type NAT. The ICE > procedures carried out are the same. For a list of candidate > addresses, a client will choose where to send media dependant on the > results of the STUN connectivity checks and associated priority > (highest priority wins). It should be noted that the inclusion of a > NAT displaying Address/Port Dependent properties does not > automatically result in relayed media. In fact, ICE processing will > avoid use of media with the exception of two clients which both ^ "relay" > happen to be behind a NAT using Address/Port Dependent > characteristics. The connectivity checks and associated selection > algorithm enable traversal in this case. Figure 16 and following > description provide a guide as to how this is achieved using the ICE > connectivity checks. This is an abbreviated example that assumes > successful SIP offer/answer exchange and illustrates the connectivity > check flow. This paragraph seems to partially re-state information that appeared earlier, but in a slightly different way... Not sure if it should be consolidated? > > > L Port/Address Dependent Address Independent R > NAT NAT > |========================================================| > | SIP OFFER/ANSWER EXCHANGE | > |========================================================| Can the 'public Internet' be depicted in the ladder diagram somehow, or at least mentioned in the prelude to the figure? Otherwise, it isn't clear that the public network is between the two NATs and which way the NATs are 'facing'. Should title as "L-NAT" and "R-NAT" so they can be more easily referenced below. > | | | | > | | |(1)Bind Req | > | | |<-----------------| > | | |Src=R=PRIV-1 | > | | |Dest=L-NAT-PUB-1 | > | | | | > | |(2)Bind Req | | > | x<-----------------| | > | |Src=R-NAT-PUB-1 | | > | |Dest=L-NAT-PUB-1 | | > | | | | > |(3)Bind Req | | | > |----------------->| | | > |Src=L-PRIV-1 | | | > |Dest=R-NAT-PUB-1 | | | > | | | | > | |(4)Bind Req | | > | |----------------->| | > | |Src=L-NAT-PUB-1 | | > | |Dest=R-NAT-PUB-1 | | > | | | | > | | |(5)Bind Req | > | | |----------------->|> > | | |Src=R-NAT-PUB-1 | > | | |Dest=R-PRIV-1 | > | | | | > | | |(6)Bind Resp | > | | |<-----------------| > | | |Src=R-PRIV-1 | > | | |Dest=L-NAT-PUB-1 | > | | | | Should this show "MAP="? > | |(7)Bind Resp | | > | |<-----------------| | > | |Src=R-NAT-PUB-1 | | > | |Dest=L-NAT-PUB-1 | | > | | | | > |(8)Bind Resp | | | > |<-----------------| | | > |Src=L-NAT-PUB-1 | | | > |Dest=L-PRIV-1 | | | > | | | | > | | |(9)Bind Req | > | | |<-----------------| > | | |Src=R-Priv-1 | > | | |Dest=L-NAT-PUB-1 | > | |(10)Bind Req | | > | |<-----------------| | > | |Src=R-NAT-PUB-1 | | > | |Dest=L-NAT-PUB-1 | | > | | | | > |(11)Bind Req | | | > |<-----------------| | | > |Src=L-NAT-PUB-1 | | | 11 should be: Src=R-NAT-PUB-1 Dest=L-PRIV-1 > | | | | > |(12)Bind Resp | | | > |----------------->| | | > |Src=L-PRIV-1 | | | > |Dest=L-NAT-PUB-1 | | | Should this show "Map=" ? > | | | | > | |(13)Bind Resp | | > | |----------------->| | > | |Src=L-NAT-PUB-1 | | > | |Dest=R-NAT-PUB-1 | | > | | | | > | | |(14)Bind Resp | > | | |----------------->| > | | |Src=R-NAT-PUB-1 | > | | |Dest=R-PRIV-1 | > | | | | > | > > > Figure 16: Single Port/Address Dependant NAT - Success > > In this abbreviated example, Client R has already received a SIP > INVITE request and is starting its connectivity checks with Client L. > Client R generates a connectivity check (1) and sends to client L's > information as presented in the SDP offer. The request arrives at > client L's Port/Address dependent NAT and fails to traverse as there > is no security association. This would then move the connectivity > check to a failed state. In the mean time client L has received the > SDP answer in the SIP request and will also commence connectivity > checks. A check is dispatched (3) to Client R. The check is able to > traverse the NAT due to the association set up in the previously ^^^^^^^ "NAT-R" > failed check(1). The full Bind request/response is shown in steps > (3)-(8). As part of a candidate pair, Client R will now successfully > be able to complete the checks, as illustrated in steps (9)-(14). > The result is a successful pair of candidates that can be used > without the need to relay any media. ... > 5.2. IPv4-IPv6 Transition for Media > > Figure 17 shows a network of IPv6 SIP user agents that has a relay > with a pool of public IPv4 addresses. The IPv6 SIP user agents of > this IPv6 network need to communicate with users on the IPv4 > Internet. To do so, the IPv6 SIP user agents use the TURN usage to > obtain a public IPv4 address from the relay. The mechanism that an ^ ^ "and port" "TURN" > IPv6 SIP user agent follows to obtain a public IPv4 address from a > relay using the TURN usage is the same as the one followed by a user > agent with a private IPv4 address to obtain a public IPv4 address. > The example in Figure 18 explains how to use the TURN usage to obtain > an IPv4 address and how to use the ANAT semantics > [I-D.ietf-mmusic-anat] of the SDP grouping framework [RFC3388] to > provide both IPv4 and IPv6 addresses for a particular media stream. ANAT has been deprecated in favor of ICE (I know it was mentioned on the mailing list, but, hey, my review wouldn't be complete if I didn't say it again! :-)) _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP