Document: draft-ietf-sipping-nat-scenarios-08 Reviewer: Francois Audet Review Date: 5/15/2008 Review Due: 5/23/2008 Review Type: WGLC Summary: On the right track; open issues Major Comments: --------------- - Section 3.2.5 I don't find this section on "Solution Profiles" useful at all. I would recommend removing it completely. If we decide that it is useful and should be kept, then I would think that it is not appropriate for this section to be applicable only to media and should also apply to signalling (e.g., sip-outbound or not, rport), and another dimension of the table should include profiles for this too. Again, my preference is to remove this "Solution Profiles" section as it adds no value to the document. - Section 4.1 The whole section 4.1 now seems completely redundant with the examples now described in draft-ietf-sip-outbound-13. All the examples included in here (and more) exist in draft-ietf-sip-outbound. I would therefore recommend that the whole section be eliminated and replaced with a pointer to draft-ietf-sip-outbound. I also have spotted a significant number of mistakes in the call flows (probably because it was based on earlier versions of draft-ietf-sip-outbound). Rather than spending time here to list the corrections, I will wait to see if the concensus of the group is to eliminate section 4.1 or not. - Section 5.2 This examples uses ANAT instead of ICE (which deprecated ANAT). Furthermore, it shows an example where TURN is done on RTP only and forgets to do RTCP. Also, the call flow is very incomplete (it doesn't have have the complete ICE procedures). What I have done below is rewritten completely the section to align with ICE, and I've removed the call flow (if you really want the call flow, it be be created, but it would be a lot longer and complex than what you had initially, and repetitive since you already have a similar one). 5.2 IPv4-IPv6 Transistion 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 TURN to obtain a set of public IPv4 address and port pairs from the relay (for RTP and RTCP). The mechanism that an IPv6 SIP user agent follows to obtain public IPv4 address and port pairs from a relay using TURN is the same as the one followed by a user agent with a private IPv4 address to obtain public IPv4 address and port pairs. The example below explains how a UA in an IPv6-only network can use ICE [I-D.ietf-mmusic-ice] to communicate with a SIP Phone in an IPv4-only network. Note that no server reflective addresses are used in this example. +----------+ | / \ | /SIP \ /Phone \ / \ ------------ | | | | 192.0.2.2:25000 | | 192.0.2.2:25123 RTP RTCP +-------------+ | TURN Server | +-------------+ IPv4 Network | | +---------+ | | ----------------------| NAT |--------------------- | | +---------+ IPv6 Network | | | | | | [2001:DB8::1]:30000 RTP RTCP [2001:DB8::1]:30001 +----------+ | IPv6 SIP | | UA | +----------+ Figure 17: IPv6-IPv4 transition scenario The IPv6 UA obtains a TURN-derived IPv4 address and port pair for its RTP port and another one for its RTCP port by issueing 2 TURN Allocate requests. The TURN server generates responses containing relayed IPv4 addresse and port pairs for both RTP and RTCP ports. These IPv4 addresses and port pairs map to the IPv6 source addresse and port pairs. The result of any UDP packets sent to the IPv4 address and port pairs provided by the TURN server (i.e., 192.0.2.2:25000 for RTP and 192.0.2.2:25123 for RTCP) with be redirected to the IPv6 IP address and port pairs of the SIP UA (i.e., [2001:DB8::1]:30000 for RTP and [2001:DB8::1]:30001 for RTCP). When the UA builds the original Offer, it includes 2 candidates: one for the host IPv6 address and another for the relay IPv4 address. When computing the priority for the candidate, we will use a type preference of 126 for the host address candidate, and of 0 for the relay address candidate, a local preference of 65535 for both candidates, and a component ID of 1 for RTP and 2 for RTCP for both candidates. This will generate a priority of 2130706431 for the host address, and of 16777215 for the relay address. The default candidate is the relay address condidate. The Offer will look as follows. v=0 o=test 2890844342 2890842164 IN IP6 2001:DB8::1 c=IN IP4 192.0.2.2 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 25000 RTP/AVP 0 a=rtcp:25123 a=candidate:1 1 UDP 2130706431 [2001:DB8::1] 30000 typ host a=candidate:1 2 UDP 2130706430 [2001:DB8::1] 30001 typ host a=candidate:2 1 UDP 16777215 192.0.2.2 25000 typ relay raddr [2001:DB8::1] rport 30000 a=candidate:2 2 UDP 16777214 192.0.2.2 25123 typ relay raddr [2001:DB8::1] rport 30001 The Offer is sent in an INVITE request which gets routed to the IPv4-only UA, which will choose the IPv4 candidate as per normal ICE procedures. Nits: ----- - Cover page does not show the Intended Status, i.e., "BCP". - Section 3.1: s/RECOMMEDED/RECOMMENDED - Section 3.1.2: Due to historical artifact, this section is labelled "Re-use of Connections". It should really be labelled "Client Initiated connections". - Section 3.2.5.2 The term "Consumer profile" it not very explanatory. I would suggest something like "Basic" profile or something along the lines. If the whole section 3.2.5 is eliminated as proposed above, then the point is moot. - Section 4.2.1.1.1 Message (4) should say "Map=NAT-PUB-1" instead of "XOR=NAT-PUB-1" to be consistent with the other examples. - Figures 10 & 11 & 12 There is some formatting problem with all the lines labelled with . - Section 4.2.1.2 s/TURN usage/TURN - Section 4.2.1.2.1 Figure 10 (pp. 42) s/local/host (2 instances in the candidate lines) PS:"host" is the new name for "local" in ICE The ICE Priorities values in the examples are all wrong and must be changed as follows: 3102938476 -> 2130706431 3010948635 -> 2130706430 2203948363 -> 1694498815 2172635342 -> 1694498814 1763546473 -> 16777215 1109384746 -> 16777214 - Section 4.2.1.2.1 Figure 11 (pp. 44) s/local/host (2 instances in the candidate lines) PS:"host" is the new name for "local" in ICE The ICE Priorities values in the examples are all wrong and must be changed as follows: 3303948573 -> 2130706431 3184756473 -> 2130706430 2984756473 -> 1694498815 2605968473 -> 1694498814 1453647488 -> 16777215 1183948473 -> 16777214 - Section 4.2.2.2 You are using terminology from a old version of TURN and STUN. Please change text as follows. (There are also other glitches I corrected, so please copy the whole paragraph). OLD: 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. NEW: 4.2.2.2 TURN Solution As identified in Section 4.2.1.1, STUN provides a useful tool for the traversal of the majority of NATs but fails with Port/Address Dependent NAT. The TURN extensions [I-D.ietf-behave-turn] address this scenario. TURN extends STUN to allow a client to request a relayed address at the TURN 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 TURN solves the previous failure when using STUN to traverse a 'Port/ Address Dependent' type NAT. - Section 4.2.2.3 s/STUN usage/STUN s/TURN usage/TURN <-- 2 instances: in fact, check the whole document - Section 5.2 s/the TURN usage/TURN