Re: [Sipping] [BEHAVE] WG Review: draft-ietf-sipping-nat-scenarios-07

["Francois Audet" <[e-mail]>]

Here are my WGLC comments on sipping NAT scenarios. I have found quite a few 
technical and editorial problems with alignment with ICE which leads me to
believe that it needs more review (at least for alignment with ICE). 
Some of these changes are because of the various iterations of ICE itself.



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 <allOneLine>. 

- 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

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP