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

From: "Rohan Mahy" <[email-masked]>
Date: Mon, 23 Oct 2006 17:49:08 -0700

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-sip-outbound-05.txt
http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-ietf-sip-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

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 24 Oct 2006 09:52:57 +0300

rohan,

does this new draft take into account what jonathan prposed here:

draft-rosenberg-sip-outbound-discovery-mid-dialog-00.txt

for example, regarding discovery of outbound proxy set?

-- juha