Subject: RE: [Sip] Update to outbound draft: draft-ietf-sip-outbound-05

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Wed, 25 Oct 2006 01:02:33 +0200

Now we have finally got this document, I want you all to wind yourself
back the discussions we were having three months ago.

Does this update reflect what you think you were discussing. If so say
so on the list. If it doesn't then also say so on the list.

This has an agenda slot in IETF#67. I want to see the content of that
agenda slot reflecting issues of current concern to the WG.

This work is meant to be high priority. It should be finished. It has
been in WGLC for a long time. Let's work to get it out of the door.

Regards

Keith

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]] 
> Sent: 24 October 2006 01:49
> To: sip
> Cc: Rohan Mahy
> Subject: [Sip] Update to outbound draft: draft-ietf-sip-outbound-05
> 
> Hi Folks,
> 
> Yesterday I did an extremely belated, but very detailed 
> update to outbound.  I believe that I have incorporated all 
> the changes we discussed at the Montreal meeting and the 
> consenus reached on the mailing list regarding STUN.  I also 
> incorporated a new short section explaining how STUN 
> keepalives would work with SigComp, as well as many 
> clarifications from private comments.
> 
> There are a few new changes which are listed as potential 
> issues at the bottom of this email.  I introduced a new 
> status code instead of using 480 or 410, I added a new timer 
> to determine when a flow is stable to make sure that the 
> avalanche restart prevention really works, and I changed the 
> text about which nodes have to add a Path header or store the 
> previous hop flow information.  Please especially read 
> through these.  If you like these changes please send me a 
> quick email to that effect.  If not please send proposed changes.
> 
> Until the draft appears in the archives, you can get it here:
> 
> http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-ietf-si
> p-outbound-05.txt
> http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-ietf-si
> p-outbound-05.html
> 
> thanks,
> -rohan
> 
> Changes from outbound-04 to -05:
> 
> STUN-related changes:
> Moved STUN Keepalive description to a separate section (section 8).
> Referenced this section from within the relevant sections in 
> the rest of the document.
> 
> Added language clarifying that UA MUST NOT send STUN without 
> an explicit indication the server supports STUN, and that a 
> UA MUST stop sending STUN if it appears the server does not 
> support it (ex:initial STUN request fails).
> 
> Defined a 'sip-stun' option tag. UAs can optionally probe 
> servers for it with OPTIONS. Clarified that UAs SHOULD NOT 
> put this in a Proxy-Require. Explain that the first-hop MUST 
> support this option-tag.
> 
> Clarify that STUN done in conjuction with SIP over TLS is on 
> the "inside" of the TLS record-layer.
> 
> Added a new section explaining the how STUN keepalives are 
> used with Sigcomp-compressed SIP messages. STUN is "outside" 
> the compression layer for UDP, but wrapped inside the 
> well-known shim header for TCP-based transports.
> 
> Non-STUN changes:
> Change a MUST to SHOULD based on consensus at last meeting.  
> The UAC SHOULD register a flow for each member of the 
> outbound-proxy-set.
> 
> Added comment about reregistration typically happening over 
> same flow as original registration.
> 
> Consistent with my email proposal about Slides 9 and 10 from 
> IETF66, I added text about the 'ob' parameter which is used 
> in Path header field URIs to make sure that the previous 
> proxy that added a Path understood outbound processing. The 
> registrar doesn't include Supported: outbound unless it could 
> actually do outbound processing (ex: any Path headers have to 
> have the 'ob' parameter).
> 
> Added some text describing what a registration means when 
> there is an instance-id, but no reg-id.  This is necessary to 
> make GRUU work for example.
> 
> Reworded registrar and proxy in some places (introduce the 
> term "Authoritative Proxy"). Several folks pointed out that 
> we were being sloppy with the proxy accepting register 
> requests and the registrar forward requests.  I think these 
> are all fixed now.
> 
> ISSUE:
> Changed 410 Gone to new response code 430 Flow Failed. Based 
> on consensus at the last meeting, I was going to change this 
> to 480 Temporarily Unavailable. Unfortunately this would not 
> work.  A phone that uses 480 today for the suggested purpose 
> of saying "Do Not Disturb" would trigger the authoritative 
> proxy to delete all the flows of that phone. Oops!  I'm 
> hoping this is fine with everyone.
> 
> ISSUE:
> Clarified how to decide what a consecutive registration timer is.
> Proposal in the draft is that a flow must be stable for some 
> time (default 120 seconds) otherwise previous registration is 
> not considered successful.  Are folks OK with this?
> 
> ISSUE:
> Loosened restrictions on always storing a complete Path 
> vector back to the registrar/authoritative proxy if a 
> previous hop in the path vector is reachable. This was one of 
> the biggest problems with the draft.
> Now it is pretty clear how you can build an archtiecture 
> where the registrar is separate from the authoritative proxy, 
> and also clear how you can visit several edge proxies, but 
> not all of them have to be in the Path.  Please read this 
> wording carefully in Section 5.1 and Section 6.  Is this OK?
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip 
> Use [email-masked] for new developments on the application of sip
> 

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

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Thu, 26 Oct 2006 12:08:32 +0200

(As WG chair)

Please remember to read outbound and comment to the list.

However the main purpose of this mail is to indicate that we intend to
conduct a process similar to that currently in progress for GRUU to get
it out of the door.

Thus in parallel to revitalising the WGLC we will be seeking people who
are actively working in this area to review the document and participate
in review calls to resolve the issues. This is not an exclusive team,
but we are actively looking for people who have or will be working with
the document in IETF or in other SDOs, to people from outside SIP who
need to do reviews (e.g. security) and to people who are implementing
this stuff.

We cannot guarantee when this will start (we do need to do it in the
next meeting cycle).

I will be trawling for people at IETF#67, but if you think you should be
involved, don't make me come looking for you. Shout up, either by mail
or coming up and saying hello.

Even if you cannot commit the cycles to be on this team, all comments
will be addressed and results made public - so please do not feel
precluded from making comments in the normal fashion - i.e. to authors
and list.

Regards

Keith

> From: Drage, Keith (Keith) [mailto:[email-masked]] 
> Sent: 25 October 2006 00:03
> To: sip
> Subject: RE: [Sip] Update to outbound draft: 
> draft-ietf-sip-outbound-05
> 
> Now we have finally got this document, I want you all to wind 
> yourself back the discussions we were having three months ago.
> 
> Does this update reflect what you think you were discussing. 
> If so say so on the list. If it doesn't then also say so on the list.
> 
> This has an agenda slot in IETF#67. I want to see the content 
> of that agenda slot reflecting issues of current concern to the WG.
> 
> This work is meant to be high priority. It should be 
> finished. It has been in WGLC for a long time. Let's work to 
> get it out of the door.
> 
> Regards
> 
> Keith
> 
> > Yesterday I did an extremely belated, but very detailed update to 
> > outbound.  I believe that I have incorporated all the changes we 
> > discussed at the Montreal meeting and the consenus reached on the 
> > mailing list regarding STUN.  I also incorporated a new 
> short section 
> > explaining how STUN keepalives would work with SigComp, as well as 
> > many clarifications from private comments.
> > 
> > There are a few new changes which are listed as potential issues at 
> > the bottom of this email.  I introduced a new status code 
> instead of 
> > using 480 or 410, I added a new timer to determine when a flow is 
> > stable to make sure that the avalanche restart prevention really 
> > works, and I changed the text about which nodes have to add a Path 
> > header or store the previous hop flow information.  Please 
> especially 
> > read through these.  If you like these changes please send 
> me a quick 
> > email to that effect.  If not please send proposed changes.
> > 
> > Referenced this section from within the relevant sections 
> in the rest 
> > of the document.
> > 
> > Added language clarifying that UA MUST NOT send STUN without an 
> > explicit indication the server supports STUN, and that a UA 
> MUST stop 
> > sending STUN if it appears the server does not support it 
> (ex:initial 
> > STUN request fails).
> > 
> servers for 
> > it with OPTIONS. Clarified that UAs SHOULD NOT put this in a 
> > Proxy-Require. Explain that the first-hop MUST support this 
> > option-tag.
> > 
> > Clarify that STUN done in conjuction with SIP over TLS is on the 
> > "inside" of the TLS record-layer.
> > 
> used with 
> > Sigcomp-compressed SIP messages. STUN is "outside"
> > Consistent with my email proposal about Slides 9 and 10 
> from IETF66, I 
> > added text about the 'ob' parameter which is used in Path 
> header field 
> > URIs to make sure that the previous proxy that added a Path 
> understood 
> > outbound processing. The registrar doesn't include 
> Supported: outbound 
> > unless it could actually do outbound processing (ex: any 
> Path headers 
> > have to have the 'ob' parameter).
> > 
> there is an 
> > instance-id, but no reg-id.  This is necessary to make GRUU 
> work for 
> > example.
> > 
> > Reworded registrar and proxy in some places (introduce the term 
> > "Authoritative Proxy"). Several folks pointed out that we 
> were being 
> > sloppy with the proxy accepting register requests and the registrar 
> > forward requests.  I think these are all fixed now.
> > 
> > ISSUE:
> > Changed 410 Gone to new response code 430 Flow Failed. Based on 
> > consensus at the last meeting, I was going to change this to 480 
> > Temporarily Unavailable. Unfortunately this would not work. 
>  A phone 
> > that uses 480 today for the suggested purpose of saying "Do Not 
> > Disturb" would trigger the authoritative proxy to delete 
> all the flows 
> > of that phone. Oops!  I'm hoping this is fine with everyone.
> > 
> > ISSUE:
> > Proposal in the draft is that a flow must be stable for some time 
> > (default 120 seconds) otherwise previous registration is not 
> > considered successful.  Are folks OK with this?
> > 
> > ISSUE:
> vector back to 
> > the registrar/authoritative proxy if a previous hop in the 
> path vector 
> > is reachable. This was one of the biggest problems with the draft.
> > Now it is pretty clear how you can build an archtiecture where the 
> > registrar is separate from the authoritative proxy, and 
> also clear how 
> > you can visit several edge proxies, but not all of them 
> have to be in 
> > the Path.  Please read this wording carefully in Section 5.1 and 
> > Section 6.  Is this OK?
> > 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
>