Subject: RE: [Sip] Ready for WGLC on Outbound?

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 5 Jul 2006 11:24:48 +0100

(As chair)

Right now both Dean and myself believe outbound is blocked.

We asked the question a month or so ago about whether outbound could proceed without a discovery mechanism (either included or normatively referenced), and there was a significant number of people who apparently said no (we do have difficulties on this list who respond to a direct question from the chairs by going away and discussing something completely different).

It appears that for these people, outbound could proceed if we have a normative reference to a discovery mechanism, but in that case, is that one mechanism or several, and do all or any of these require mandatory support.

Conversely we have a set of people who appear to be saying "use any mechanism you like" and therefore no normative reference is needed.

Now obviously, we would like to get this resolved one way or the other. We will quite probably be conducting hums on this issue in the SIP WG session in Montreal, having failed to achieve concensus on the list - unless in the next two or three days we see a breaking of this impasse.

And remember, if outbound is blocked, then GRUU is dependent on outbound, so at the end of the day that will also be blocked, even if we progress it to the RFC editor's queue.

We are formulating the questions we need to ask the WG on this issue, so any guidance from those involved would be useful. It would be nice to get the problem stated as clearly as possible so that the WG is able to give an intelligent answer.

regards

Keith

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: 05 July 2006 05:10
> To: Cullen Jennings
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Sip] Ready for WGLC on Outbound?
> 
> 
> I've been a  bystander, but will jump in here. Comment below:
> 
> On Jul 4, 2006, at 3:37 PM, Cullen Jennings wrote:
> 
> >
> > I think people have stopped posting on this because they can't say  
> > anything that they have not already said. Don't take that as they  
> > agree.
> >
> > We got very strong feed back on one point - don't send STUN  
> > messages to a proxy unless you know it supports them. People felt  
> > strongly about that - I don't know why - but there was lots of  
> > people that agreed with that.
> >
> > I imagine people have sent me around 10 options on how to get the  
> > stun supported information and the set of outbound proxy URIs -  
> > certainly DNS and DHCP are some of them. We can write some drafts  
> > on various ways to do it. Right now my concern is making sure that  
> > no matter which of these many ways the WG decided to move forward  
> > with, outbound will work. So far every one of the possibilities I  
> > have heard would be possible with the current outbound. 
> Given that,  
> > I'm not sure what we need to change in outbound. I'm not even sure  
> > what you are proposing that we change in outbound - I think what  
> > you are proposing is we need to hold up outbound until we choose  
> > which one of the 10 we will use and furthermore you feel very  
> > strongly on which one of the 10 we should use. I'm not keen 
> on this  
> > - I think we have shown they are separable problems. The WG 
> decided  
> > on this separation of problems awhile back - I think it was in  
> > Vancouver - and many people supported it. I think it was a good  
> > idea  - we have shown we can move outbound forward before we have  
> > determined all the ways that this configuration information is  
> > delivered to the UA. I would be very hesitant to reverse this  
> > decision now.
> 
> I strongly agree with Cullen. We do not need to block the outbound  
> mechanism draft on figuring out the discovery stuff. The separation  
> was a good idea. If for no other reason, it lets us get work done.
> 
> 
> 
> 
> >
> > I don't think Dean's posts were sent as decries of the 
> requirements  
> > from the chair but purely as his opinion in trying to help bring  
> > the discussion to consensus. But I do think the draft meets the  
> > requirements and ideas he was outlining - I think the 
> current draft  
> > does meet the requirements he outlines. It does have a way for the  
> > "discovering whether a proxy supports the extensions of outbound"  
> > and on the topic of "there are two ways we can establish  
> > compatibility with an extensions", the WG rejected option 2 and we  
> > have gone with 1.
> >
> > Cullen (with my outbound author hat on)
> >
> >
> > On Jul 4, 2006, at 3:50 AM, <[email-masked]>  
> > <[email-masked]> wrote:
> >
> >>
> >> Hi Rohan,
> >>
> >> Sorry to be persistent with this issue, but what you say
> >> seems to conflict with what was discussed in March.
> >>
> >>> The only time a UAC sends a STUN request as directed by
> >>> outbound -04 is when the URI in the outbound-proxy-set
> >>> includes the keepalive=stun parameter. That DHCP does not
> >>> provide URI is a limitation of the SIP DHCP configuration
> >>> mechanism, not outbound. If you want to write a draft on
> >>> how to "shift-up" to using keepalives from some SIP or
> >>> external stimulus, you can still do this.
> >>
> >> What you say seems to suggest that you agree there is a problem
> >> when using DHCP SIP server option (as it is currently defined)
> >> for finding out if the discovered proxy supports outbound and
> >> STUN keepalives, but the solution is not in scope of Outbound
> >> draft itself.
> >>
> >> However I came to a different understanding based on the emails
> >> seen in the list earlier. For instance this email from Dean
> >> Willis (SIP WG chair) seems to suggest that the problem should
> >> be in scope of the outbound draft:
> >> http://www1.ietf.org/mail-archive/web/sip/current/msg13667.html
> >>
> >> "Ok, I think we've boiled this down to a new requirement:
> >>
> >> for the "outbound" technique to work, we MUST have a means of
> >> discovering whether a proxy supports the extensions of outbound.
> >>
> >> While we could do that by doing a REGISTER exchange that includes
> >> an appropriate option-tag in Require:, it would be more efficient
> >> if the proxy discovery mechanism informed us of this detail. So,
> >> we posit that the Outbound draft SHOULD select and discuss such a
> >> mechanism."
> >>
> >> And in yet another email
> >> http://www1.ietf.org/mail-archive/web/sip/current/msg13692.html
> >> Dean tells this:
> >>
> >> "There are two ways we can establish compatibility with an  
> >> extensions:
> >>
> >> 1) By foreknowledge
> >> 2) By experimentation -- try it and see if it works.
> >>
> >> Both have limitations:
> >>
> >> In the case of #1, we might have incorrect knowledge. So we'll  
> >> probably
> >> end up testing anyhow . . .
> >>
> >> In the case of #2, the experiment might cause a meltdown. So the  
> >> "probe
> >> for discovery" must be made completely safe. Also, we can  
> >> eventually end
> >> up with so many wierd hooks and idiosyncratic 
> implementations that we
> >> end up doing a BUNCH of probing before we do any real  
> >> communicating. And
> >> it's possible for the conditions to deteriorate so much that  
> >> probes for
> >> two different possible conditions are mutually exclusive -- if one
> >> condition applies, the probe for another will cause a meltdown.
> >>
> >> So what happens if we start STUN-probing a proxy on its SIP port  
> >> and it
> >> doesn't support STUN? My guess is, it's random.
> >>
> >> ...
> >>
> >> One approach to "forward compatibility" design is to make sure  
> >> that we
> >> can use both foreknowledge and experimentation -- the "trust but  
> >> verify"
> >> model.
> >>
> >> ...
> >>
> >> While it's easy to decide whether a configured registrar URI has a
> >> keepalive parameter, what happens to proxies we select based on
> >> something besides direct configuration?
> >>
> >> Specifically,
> >>
> >> 1) Can the DHCP option for default proxy present the keepalive
> >> parameter?"
> >> ----
> >>
> >> During these three months after seeing those comments in the list
> >> I have been expecting the outbound draft to provide answer to
> >> the question how UA could (within SIP signalling exchange)
> >> safely to check whether or not a proxy supports STUN keepalive.
> >> Two mechanims have been suggested how the UA could do this in
> >> a simple way:
> >>
> >> 1. The UA to check that the Path header in 200 OK returned for
> >>    REGISTER would contain keepalive=stun parameter for the 
> proxy URI
> >>
> >> 2. The UA to add Proxy-Reequire: stun-keepalive parameter into
> >>    the REGISTER request and the proxy to remove this tag from
> >>    the request before forwarding it towards the registrar
> >>
> >> For me, any of those mechanisms would sound feasible and for
> >> safety reasons I would hope the draft to deny the UA for sending
> >> STUN keepalives to the proxy which did not pass such a test.
> >>
> >>> the same problem exists for the "comp" parameter for example.
> >>
> >> Yes but please bear in mind that for comp=sigcomp URI parameter
> >> RFC 3486 Compressing SIP gives several solutions how the UA
> >> would be able to check if the proxy supports SigComp while
> >> outbound does not define any other than relying on configuration.
> >> A cite from RFC 3486:
> >>
> >> 4.1   Obtaining a SIP or SIPS URI with comp=sigcomp
> >>
> >>    For requests within a dialog, a next-hop URI with the 
> comp=sigcomp
> >>    parameter is obtained from a Record-Route header field when the
> >>    dialog is established.  A client sending a request outside a  
> >> dialog
> >>    can also obtain SIP URIs with comp=sigcomp in a Contact header  
> >> field
> >>    in a 3xx or 485 response to the request.
> >>
> >>    However, clients establishing a session will not typically be  
> >> willing
> >>    to wait until the dialog is established in order to begin  
> >> compressing
> >>    messages.  One of the biggest gains that SigComp can bring to  
> >> SIP is
> >>    the ability to compress the initial INVITE of a dialog, when  
> >> the user
> >>    is waiting for the session to be established.  
> Therefore, clients
> >>    need a means to obtain a comp=sigcomp URI from their outbound  
> >> proxy
> >>    before the user decides to establish a session.
> >>
> >>    One solution to this problem is manual configuration.  However,
> >>    sometimes it is necessary to have clients configured in an  
> >> automatic
> >>    fashion.  Unfortunately, current mechanisms for SIP client
> >>    configuration (e.g., using DHCP [6]) do not allow to provide the
> >>    client with URI parameters.  In this case, the client SHOULD  
> >> send an
> >>    uncompressed OPTIONS request to its outbound proxy.  
> The outbound
> >>    proxy can provide an alternative SIP URI with the comp=sigcomp
> >>    parameter in a Contact header field in a 200 OK response to the
> >>    OPTIONS.  The client can use this URI for subsequent 
> requests that
> >>    are sent through the same outbound proxy using compression.
> >>
> >>    RFC 3261 [1] does not define how a proxy should respond to an  
> >> OPTIONS
> >>    request addressed to itself.  It only describes how servers  
> >> respond
> >>    to OPTIONS addressed to a particular user.  Section 
> 11.2 of RFC  
> >> 3261
> >>    says:
> >>
> >>       Contact header fields MAY be present in a 200 (OK) 
> response and
> >>       have the same semantics as in a 3xx response.  That 
> is, they  
> >> may
> >>       list a set of alternative names and methods of reaching the  
> >> user.
> >>
> >>    We extend this behavior to proxy servers responding to OPTIONS
> >>    addressed to them.  They MAY list a set of alternative URIs to
> >>    contact the proxy.
> >>
> >> What has been called for is that outbound draft would also
> >> specify one solution how the UA could check the STUN keepalive
> >> support of a proxy. In my opinion good proposals seem
> >> to exist how to do it in a reasonable way.
> >>
> >> Regards,
> >>
> >> Erkki
> >>
> >>> -----Original Message-----
> >>> From: ext Rohan Mahy [mailto:[email-masked]]
> >>> Sent: 04.July.2006 03:10
> >>> To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki)
> >>> Cc: [email-masked]; [email-masked]; Rohan Mahy;
> >>> [email-masked]; [email-masked]
> >>> Subject: Re: [Sip] Ready for WGLC on Outbound?
> >>>
> >>> Hi Erkki,
> >>>
> >>> The only time a UAC sends a STUN request as directed by
> >>> outbound -04 is
> >>> when the URI in the outbound-proxy-set includes the keepalive=stun
> >>> parameter.  This is 100% backwards safe.  We don't need 
> any text to
> >>> prevent existing implementations from getting a bunch of STUN  
> >>> requests.
> >>>
> >>> That DHCP does not provide URI is a limitation of the SIP DHCP
> >>> configuration mechanism, not outbound.  The same problem
> >>> exists for the
> >>> "comp" parameter for example.  If you want to write a draft on  
> >>> how to
> >>> "shift-up" to using keepalives or using compression from 
> some SIP or
> >>> external stimulus, you can still do this.  No text in outbound
> >>> prevents
> >>> that from happening.
> >>>
> >>> thanks,
> >>> -rohan
> >>>
> >>>
> >>> On Jun 29, 2006, at 23:10, <[email-masked]> wrote:
> >>>>
> >>>> Hi Rohan,
> >>>>
> >>>>>> Also, the issue is that what may be configured (no 
> matter how you
> >>>>>> configure it) may not be a URI. It may simply be an IP
> >>> address/FQDN,
> >>>>>> which is then used to build a SIP-URI. I think we shall
> >>>>>> allow that, and make it more clear in the spec. [/CHH]
> >>>>>
> >>>>> the outbound spec defines a piece of configurable data (the
> >>>>> 'outbound-proxy-set'), which is a list of URIs.  This list
> >>> of URIs may
> >>>>> never have a one-to-one correspondence to a user or 
> administrator
> >>>>> manually configurable field.  That piece of configurable data  
> >>>>> may be
> >>>>> derived from several fields, manually configurable, 
> discovered via
> >>>>> DHCP, DNS, the config package, P-Whatchamacallit headers, HTTP
> >>>>> download, or via a random character generator seeded by the  
> >>>>> phase of
> >>>>> the moon.
> >>>>>
> >>>>> The outbound-proxy-set was defined as a list of URIs because  
> >>>>> the UA
> >>>>> acts on each item in the list, because each URI is 
> expected to be
> >>>>> places in a Route header, and because each URI is expected to
> >>>>> typically have a keepalive URI parameter in it.
> >>>>
> >>>> Like mentioned in other recent emails the problem is 
> that if the UA
> >>>> derives the proxy URI(s) from DHCP SIP server option or 
> e.g. the  
> >>>> AOR
> >>>> of the user, in those cases the derived URI will NOT contain the
> >>>> keepalive URI parameter in it. DHCP just returns IP addresses or
> >>>> domain names instead of URIs with parameters.
> >>>>
> >>>> Thus in those cases it would be critical for the UA to be able
> >>>> to ensure in REGISTER - 200 OK sequence that the contacted proxy
> >>>> supports Outbound and can handle STUN requests sent to its SIP
> >>>> port (not to cause any damage to an uncompliant proxy). I fully
> >>>> agree with this proposal from Jeroen:
> >>>>
> >>>> --
> >>>> The text should then say "the UAC MUST wait for a 200 OK to  
> >>>> REGISTER
> >>>> before
> >>>> it starts sending STUN packets. If the last Path header of the  
> >>>> 200 OK
> >>>> does
> >>>> not contain keepalive=stun, the UAC MUST NOT use STUN
> >>> towards this URI.
> >>>> If
> >>>> there are no Path headers and no "Supported: outbound", the UAC  
> >>>> also
> >>>> MUST
> >>>> NOT use STUN towards the registrar.". It could still use TCP
> >>> keepalive
> >>>> if it
> >>>> supports that
> >>>> --
> >>>>
> >>>> Please excuse me if I am just repeating myself and what 
> e.g. Jeroen
> >>>> has said but I believe the importance of this issue 
> justifies some
> >>>> redundancy :-)
> >>>>
> >>>> Regards,
> >>>>
> >>>> Erkki
> >>>
> >>>
> >
> > _______________________________________________
> > 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
> 

_______________________________________________
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: Juha Heinanen <[email-masked]>
Date: Wed, 5 Jul 2006 23:25:23 +0300

Drage, Keith (Keith) writes:

 > We asked the question a month or so ago about whether outbound could
 > proceed without a discovery mechanism (either included or normatively
 > referenced), and there was a significant number of people who
 > apparently said no (we do have difficulties on this list who respond
 > to a direct question from the chairs by going away and discussing
 > something completely different). 

yes, i was one of those who said that outbound MUST reference DNS based
discovery in the same way as RFC3261 does.

 > It appears that for these people, outbound could proceed if we have a
 > normative reference to a discovery mechanism, but in that case, is
 > that one mechanism or several, and do all or any of these require
 > mandatory support.

there must be one that every UA MUST implement.  otherwise there is no
interoperability and outbound turn out to be useless in real world.

 > Conversely we have a set of people who appear to be saying "use any
 > mechanism you like" and therefore no normative reference is needed.

this would be a disaster to proxy operator.

 > And remember, if outbound is blocked, then GRUU is dependent on
 > outbound, so at the end of the day that will also be blocked, even if
 > we progress it to the RFC editor's queue.

i don't mind the delay if the result is a deployable package.  it makes
no sense to ietf to release outbound rfc without discovery reference and
pretend that it has accomplished something.  there is already now FAR
TOO MANY sip related rfcs that very few or nobody have implemented.

-- juha