Subject: Re: [Sipping] [RAI] RAI-ART review ofdraft-ietf-sipping-nat-scenarios-08

From: "Dan Wing" <[email-masked]>
Date: Wed, 4 Jun 2008 14:14:16 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Francois Audet
> Sent: Thursday, May 29, 2008 9:30 AM
> To: Philip Matthews; Chris Boulton
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sipping] [RAI] RAI-ART review 
> ofdraft-ietf-sipping-nat-scenarios-08
> 
>  
> > 3) I haven't been following the Outbound and GRUU work 
> > closely, but my imperfect understanding is that both of these 
> > are part of the NAT traversal solution for SIP. Don't you 
> > need to include Outbound and GRUU in the solution profiles?  
> > Similarly, shouldn't GRUU be discussed in the first part of 
> section 3?
> 
> I actually had exactly the same comment in my review.
> 
> My preference would be to get rid of the "profile" concept altogether,
> i.e. remove section 3.2.5, since itoffers very little value 
> and much confusion.
> 
> If we must keep the concept of profiles, then it needs to be 
> expanded to
> cover draft-ietf-sip-outbound.
> 
> As a side note: you don't need GRUU at all anymore for NAT 
> traversal of
> SIP. What you need is the +sip.instance id which is described in SIP
> outbound (and yes, GRUU refers back to outbound). But you don't need
> support for GRUU per say.
> 
> This is one of the many problems that I alluded in section 
> 4.1 which is
> now quite out-of-synch with outbound. There are others. For example,
> usage of Supported and Required is incorrect. The tokens in 
> the Path header
> don't conform to the recomendations in outbound. The Route 
> header usage is
> not described properly. Furthermore, there are still remnants 
> of pre-outbound
> days in the text (e.g., innapropriate references to rport and 
> connect-reuse).
> 
> I am planning to propose the changes to fix this section in a 
> seperate email.

What is the value of two documents (outbound and nat-scenarios)
which both have call flows, examples, and discussion around how SIP
is supposed to work over NATs?  It seems a recipe for unintended 
disagreement and errata to re-align them.

Is the value that nat-scenarios would be a BCP and outbound is
standards-track?

-d

_______________________________________________
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: Wed, 4 Jun 2008 16:59:52 -0500

> Is the value that nat-scenarios would be a BCP and outbound is

I that's that's probably a good description.

I can assure you that I have done a very thorough review of the Signalling
section to ensure that it aligns with sip-outbound, because I had the exact same
concern as you. Remember my intial proposal was to remove the section but the
group decided otherwise.

So I was left with the alternative of actually doing the work on the section myself...

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 13 Jun 2008 17:35:27 +0100

Francois,

Just catching up on some old email - I feel I must challenge a statement
you made below.

> Sent: 29 May 2008 17:30
...
> support for GRUU per say.
[JRE] Why don't you need GRUU? UA A has a private IP address and forms a
contact URI from it, instead of using a GRUU. UA A sends it in the
Contact header field of a dialog-forming request or response to UA B. UA
B then sends it in a REFER request to UA C. UA C is in public address
space. How does the dereferenced request get from UA C to UA A?

John

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 13 Jun 2008 11:44:20 -0500

Because the part of GRUU that you are using, i.e., the +sip.instance, has been
moved to draft-ietf-sip-outbound.

You do not need to send Supported: gruu when you register. You just add the
+sip.instance.

All this is described in draft-ietf-sip-outbound. 

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Friday, June 13, 2008 09:35
> To: Audet, Francois (SC100:3055); Philip Matthews; Chris Boulton
> Subject: RE: [Sipping] [RAI] RAI-ART review 
> Just catching up on some old email - I feel I must challenge 
> a statement you made below.
> 
> 
> traversal 
> > of SIP. What you need is the +sip.instance id which is described in 
> > SIP outbound (and yes, GRUU refers back to outbound). But you don't 
> > need support for GRUU per say.
> [JRE] Why don't you need GRUU? UA A has a private IP address 
> and forms a contact URI from it, instead of using a GRUU. UA 
> A sends it in the Contact header field of a dialog-forming 
> request or response to UA B. UA B then sends it in a REFER 
> request to UA C. UA C is in public address space. How does 
> the dereferenced request get from UA C to UA A?
> 
> John
>