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

From: "Mary Barnes" <[email-masked]>
Date: Fri, 2 May 2008 17:44:36 -0500

Hi folks,

This is to announce a Working Group Last Call on the following document
to be published a Best Current Practice (BCP):
http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-08.
txt

The review period will end on 23 May 2008 (3 weeks time). 

Note that I have cross-posted to the BEHAVE and MMUSIC WGs, but ask that
you please send your comments only to the SIPPING WG and author(s). 

The following reviewers have already volunteered:  Vijay Gurbani,
Spencer Dawkins, Francois Audet, and Dan Wing  (thanks guys!)

However, we do encourage others to review and make any final comments on
the document at this time.  

Thanks,
Mary
SIPPING WG co-chair

As a reminder, the SIPPING WG review guidelines are available at:
https://softarmor.com/sipping/process/wg-review/sipping-review-guideline
s.html

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

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 15 May 2008 17:09:56 -0500

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

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 22 May 2008 09:56:23 +0100

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

[Chris Boulton]I'm easy on this one.  I would really like to hear what
Jonathan has to say as it was originally his input into the draft.  I
personally don't think the section is 'harmful' but if it's not
considered useful enough (in this or any other form) then so be it.  Any
one else?

Chris.

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 22 May 2008 10:00:55 +0100

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

[Chris Boulton] OK - while I agree there is duplication I personally
would like to keep these examples.  Such a thorny topic benefits from
not having to send a 'newbie' to another yet document to read more
flows.  I like the fact that as a BCP we can provide a simple example
that is self contained in the document.  On the other hand, as editor, I
am more than happy to remove and simply put a reference to Outbound -
makes my life easier :-).

What do other folks think? 

Chris.

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 22 May 2008 10:04:54 +0100

[Chris Boulton] Yes - this had already been noted and was being worked
by Gonzalo.  Thank you very much for the text - I will leave Gonzalo to
comment as he is due to provide this changed section.

Thanks.

Chris.

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

   (for RTP and RTCP).  The mechanism that an IPv6 SIP user agent
follows 

                             +----------+
                             |   /  \   |
                                /SIP \
                               /Phone \
                              /        \
                             ------------
                              |      |
                              |      |

   Allocate requests. The TURN server generates responses containing
relayed 
   addresses and port pairs map to the IPv6 source addresse and port
pairs. 

   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.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 22 May 2008 08:16:13 -0500

> What do other folks think? 

FWIW, for self-containment purpose, I would second the duplication
in the nat-scenarios BCP.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 22 May 2008 10:41:25 -0500

Well, it's harmful because it has many technical mistakes in it...
So we would have to correct them. I can do that IF we decide to 
keep it (I have it all in red-ink on paper right now).

But then it would be near identical to section 9/draft-ietf-sip-outbound... 

> -----Original Message-----
> From: Chris Boulton [mailto:[email-masked]] 
> Sent: Thursday, May 22, 2008 01:56
> To: Audet, Francois (SC100:3055); Barnes, Mary (RICH2:AR00); 
> [email-masked]
> Cc: [email-masked]; Jonathan Rosenberg
> Subject: WG Review: draft-ietf-sipping-nat-scenarios-07 - 
> Francois Major Comment 1
> 
> - Section 3.2.5
> 
> [Chris Boulton]I'm easy on this one.  I would really like to 
> hear what Jonathan has to say as it was originally his input 
> into the draft.  I personally don't think the section is 
> 'harmful' but if it's not considered useful enough (in this 
> or any other form) then so be it.  Any one else?
> 
> Chris.
>  
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 22 May 2008 10:48:32 -0500

I though duplication was bad because it leads to errors?

(Which is obviously the case here). 

> From: Vijay K. Gurbani [mailto:[email-masked]] 
> Sent: Thursday, May 22, 2008 06:16
> To: Chris Boulton
> Cc: Audet, Francois (SC100:3055); Barnes, Mary (RICH2:AR00); 
> [email-masked]; [email-masked]
> Subject: Re: [Sipping] WG Review: 
> draft-ietf-sipping-nat-scenarios-07 - Francois Major Comment 2
> 
> Chris Boulton wrote:
> > that is self contained in the document.  On the other hand, 
> as editor, 
> > I am more than happy to remove and simply put a reference 
> to Outbound 
> > - makes my life easier :-).
> > 
> FWIW, for self-containment purpose, I would second the 
> duplication in the nat-scenarios BCP.
> 
> Thanks,
> 
> - vijay
> --

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 22 May 2008 11:02:38 -0500

> (Which is obviously the case here). 

The underlying assumption, of course, is that the portions
being duplicated across documents are similar.  So, if
sip-outbound is the source of the duplication stream,
then nat-scenarios should simply ensure that it is consistent
with sip-outbound.

Normally yes, duplication is bad for the reason you mention.
But the corpus of SIP documents is so large that if we manage
to create a self-contained document -- especially an
informative/BCP one such as nat-scenarios -- we should at
least give it a shot.  Future readers of the documents may
be grateful to read only one informative document.

Thanks,

- vijay

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 22 May 2008 11:08:02 -0500

My vote is to keep the existing examples, exactly for the reasons stated
here. Any example can make better sense of generic text.

Henry

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 22 May 2008 12:01:13 -0500

Let me be more precise.

The main difference between the examples in nat-scenarios for signalling
and the ones in outbound are:
- oubound has examples for TCP only: no UDP. nat-scenarios has both.
- nat-scenarios has examples for registration where Proxy and Registrar
  are co-located: outbound only has the non-colocated case
- nat-scenarious shows the 401/407 challenge which I think is just
  a distraction and should be removed for simplicity: it adds unecessary
  bulk to the call flows
- outbound includes an "proxy crash" example for incoming calls. 
  nat-scenarios does not.
- There is some weird TCP-mixed-with-UDP in the call flows in nat-scenarios. 
  I hope this is a mistake.
- There are many technical errors in nat-scenarios that need to be fixed.

So, the sections that are duplicated are:

- 4.1.2 Registration over TCP with non-colocated proxy/reg: see outbound/9.2
- 4.1.3.2 Outgoing session over TCP: note that this section is essentially
          empty in nat-scenarios: it should point to outbound/9.5
- 4.1.4.2 Incoming session over TCP: note that this section is essentiually
          empty in nat-scenarios: it should point to outbound/9.3

The other sections are NOT duplicated and could be kept.

So, if we decide to keep the non-duplicated examples, we need to at a minimum
fix them to align with outbound (at the technical level). I'd also would like
to align them at the "superficial" level (i.e., names used for components)
to make it easier to the reader to work with both. If that is what we decide to
do, I'm willing to help.

> Sent: Thursday, May 22, 2008 09:03
> To: Audet, Francois (SC100:3055)
> Cc: Chris Boulton; Barnes, Mary (RICH2:AR00); 
> sip-outbound is the source of the duplication stream, then 
> nat-scenarios should simply ensure that it is consistent with 
> sip-outbound.
> 
> least give it a shot.  Future readers of the documents may be 
> grateful to read only one informative document.
> 
> Thanks,
> 
> - vijay
> --

---

From: Dan York <[email-masked]>
Date: Thu, 22 May 2008 16:41:50 -0400

> be grateful to read only one informative document.

+1

We need documents that are as explanatory as possible to make it  
*easy* for people to implement SIP. Right now implementors often have  
to got on a document chase to figure out what all they need to do.   
I'm not a fan of duplication, either, but in cases like this I think  
it's extremely helpful.  (Obviously, the examples need to be  
*correct*, as well.)

My 2 cents,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 22 May 2008 15:49:53 -0500

Just to be clear: 

In this case, you are not going to implement anything without
sip-outbound, ICE, STUN-BIS and TURN. 

> From: Dan York [mailto:[email-masked]] 
> Sent: Thursday, May 22, 2008 13:42
> To: Vijay K. Gurbani
> Cc: Audet, Francois (SC100:3055); [email-masked]; Barnes, 
> Mary (RICH2:AR00); [email-masked]
> > But the corpus of SIP documents is so large that if we manage to 
> > create a self-contained document -- especially an 
> informative/BCP one 
> > such as nat-scenarios -- we should at least give it a shot.  Future 
> > readers of the documents may be grateful to read only one 
> informative 
> > document.
> 
> 
> +1
> 
> I'm not a fan of duplication, either, but in cases like this 
> I think it's extremely helpful.  (Obviously, the examples 
> need to be *correct*, as well.)
> 
> My 2 cents,
> Dan
> 
> --

---

From: "Chris Boulton" <[email-masked]>
Date: Fri, 23 May 2008 09:41:33 +0100

This seems good to me - any objections before I put it on the change
list?

Chris.

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: 22 May 2008 18:01
To: Chris Boulton
Cc: Mary Barnes; [email-masked]; [email-masked]
Subject: RE: [Sipping] WG Review: draft-ietf-sipping-nat-scenarios-07 -
Francois Major Comment 2

Let me be more precise.

- There is some weird TCP-mixed-with-UDP in the call flows in
nat-scenarios. 
- There are many technical errors in nat-scenarios that need to be
fixed.

- 4.1.2 Registration over TCP with non-colocated proxy/reg: see
outbound/9.2
- 4.1.3.2 Outgoing session over TCP: note that this section is
essentially
          empty in nat-scenarios: it should point to outbound/9.5
- 4.1.4.2 Incoming session over TCP: note that this section is
essentiually
          empty in nat-scenarios: it should point to outbound/9.3

So, if we decide to keep the non-duplicated examples, we need to at a
minimum
fix them to align with outbound (at the technical level). I'd also would
like
to align them at the "superficial" level (i.e., names used for
components)
to make it easier to the reader to work with both. If that is what we
decide to
do, I'm willing to help.