Subject: RE: [Sip] outbound: summary of issues

From: "Elwell, John" <[email-masked]>
Date: Thu, 30 Mar 2006 10:16:37 +0100

Christian,

Yes, you are right, Supported will not work, because an edge proxy that
doesn't support it cannot be expected to remove it! It seems that a new
header might be best.

John 

> -----Original Message-----
> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: 30 March 2006 09:38
> To: Elwell, John; Jeroen van Bemmel; [email-masked]
> Subject: RE: [Sip] outbound: summary of issues
> 
> 
> Hi,
> 
> Will there be some other kind of information, related to 
> outbound, that
> we need to transport? Anything related to the NAT keep-alive (timer
> values etc)?
> 
> Since we are defining a new extension, we could also define a new
> header, which could carry the information.
> 
> OR, as I wrote in another mail, do we want a more generic 
> mechanism how
> nodes can indicate support for extensions and capabilities (other than
> outbound)? 
> 
> Because, in future there may be an extension which requires similar
> knowledge as now...
> 
> Of course, one option is to modify the Supported header. But, then
> again, would it really work? Assume the registrar indicates that it
> supports outbound, but the proxy(s) between the UA and the 
> registrar do
> not. The proxy(x), however, still insert a Path header, which 
> means they
> will be in the path. But, how does the UA know which of the proxies
> (including the registrar) really supports outbound?
> 
> Regards,
> 
> Christer 
> 
> 
>  
> 
> -----Original Message-----
> From: Elwell, John [mailto:[email-masked]] 
> Sent: 30. maaliskuuta 2006 9:49
> To: Jeroen van Bemmel; [email-masked]
> Subject: RE: [Sip] outbound: summary of issues
> 
> Jeroen,
> 
> I think it is important that the mechanism used by the UA to determine
> support for outbound be independent of whether there is a 
> proxy present
> between the UA and the Registrar. The UA should not have to care about
> this.
> As I understand it, the Path header would be used only if there is an
> edge proxy present, so if the Path header were used to 
> indicate support
> for outbound, then some other mechanism would be needed for when there
> is no proxy.
> 
> Personally I prefer to use Supported, even if by manipulating the
> outbound tag at the proxy it violates normal use of Supported.
> 
> John
> 
> > -----Original Message-----
> > From: Jeroen van Bemmel [mailto:[email-masked]]
> > Sent: 29 March 2006 22:13
> > To: Elwell, John; [email-masked]
> > Subject: Re: [Sip] outbound: summary of issues
> > 
> > John,
> > 
> > Yes, this is what one thread of the discussion was about, 
> and you seem
> 
> > to agree with #2 below
> > 
> > Proxies inserting Supported: I think that would indeed be 
> > inappropriate as you indicate.
> > What about feature tags a la callerprefs (RFC3841) in Path and 
> > Record-Route headers?
> > 
> > Path: <sip:out.proxy.domain.com;lr>;extensions="outbound"
> > 
> > This would imply that proxies cannot indicate extensions without 
> > Record-Routing, but since the information is only relevant when the 
> > proxy stays in the path for next requests, this somehow feels 
> > appropriate to me
> > 
> > Regards,
> > 
> > jeroen
> > 
> > ----- Original Message -----
> > From: "Elwell, John" <[email-masked]>
> > To: "Jeroen van Bemmel" <[email-masked]>; <[email-masked]>
> > Sent: Wednesday, March 29, 2006 10:05 PM
> > Subject: RE: [Sip] outbound: summary of issues
> > 
> > 
> > > Jeroen,
> > >
> > > Thanks for your explanation. However, could we not limit
> > use of Supported
> > > outbound to the edge proxy. Since an edge proxy would not
> > connect to the
> > > registrar using outbound (I assume connect-reuse would be
> > used instead),
> > > then there is no reason for the registrar to place
> > Supported outbound in
> > > the
> > > REGISTER response. This could be left for the edge proxy to
> > insert. If it
> > > is
> > > felt inappropriate for a proxy to insert a Supported header
> > tag, then
> > > perhaps there is something else it can insert. This would
> > seem much more
> > > reliable than depending on configuration.
> > >
> > > John
> > >
> > >> -----Original Message-----
> > >> From: Jeroen van Bemmel [mailto:[email-masked]]
> > >> Sent: 29 March 2006 20:36
> > >> To: Elwell, John; [email-masked]
> > >> Subject: Re: [Sip] outbound: summary of issues
> > >>
> > >> John,
> > >>
> > >> see inline
> > >>
> > >>
> > >> ----- Original Message -----
> > >> From: "Elwell, John" <[email-masked]>
> > >> To: "Jeroen van Bemmel" <[email-masked]>; <[email-masked]>
> > >> Sent: Wednesday, March 29, 2006 9:23 PM
> > >> Subject: RE: [Sip] outbound: summary of issues
> > >>
> > >>
> > >> >
> > >> >
> > >> >> -----Original Message-----
> > >> >> From: Jeroen van Bemmel [mailto:[email-masked]]
> > >> >> Sent: 29 March 2006 19:49
> > >> >> To: [email-masked]
> > >> >> Subject: [Sip] outbound: summary of issues
> > >> >>
> > >> >> An attempt to summarize issues identified so far, in 
> the form of
> 
> > >> >> closed questions:
> > >> >>
> > >> >> 1. Configuration of outbound proxies - desire to avoid manual 
> > >> >> configuration at the UAC. Do we agree that we want this?
> > >> >> 1a If yes, in the outbound draft or as a separate draft?
> > >> >> 2. Detection of outbound/keepalive support - desire 
> for dynamic 
> > >> >> discovery of support instead of (or perhaps in addition to) 
> > >> >> static configuration (the current keepalive=stun flag). Do we 
> > >> >> agree that we want this? (several options have been discussed)
> > >> > [JRE] I can't recall what was wrong with just an option
> > tag in the
> > >> > Supported
> > >> > header of the REGISTER response.
> > >>
> > >> That would indicate that the registrar supports 
> outbound, but says 
> > >> nothing about the edge proxy. The risk is that the UAC starts 
> > >> poking it with STUN requests while it is not supported.
> > >>
> > >> An outbound proxy URI with keepalive=stun would indicate proxy 
> > >> support, but that would only be an informed guess - there is the 
> > >> possibility for misconfiguration. To avoid this, it 
> would be good 
> > >> if the
> > proxy would
> > >> actively indicate that it supports outbound (in particular STUN).
> > >>
> > >> Jeroen
> > >>
> > >> >
> > >> > John
> > >> 
> > 
> 
> _______________________________________________
> 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: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 30 Mar 2006 05:09:36 -0500

Have you checked Brett Tate's idea of via-params?  He emailed it to the list
on Tuesday.  It's elegant, I think.

It's the following, snipped
---------------------------
UAC adds Via parameter "outbound".
And when the proxy/UAS observes it and supports receiving stun on this
port/connection, it adds a parameter like "outbound=supported" or
"outbound=required".
----------------------------

We may want to think about splitting it into two via-params: outb=yes, and
ka=stun (or some such).  First means you support outbound, second means you
support stun keepalive.  They could be mutually inclusive.  If you can do
outbound, you set the former.  If you can do stun in this socket, you set
latter.  If you can do both you set both.  And thus they're usable in future
drafts independently.  (For example if someone does a proxy-proxy draft and
if it decided to use the same ka mechanism)

-hadriel

> Sent: Thursday, March 30, 2006 4:17 AM
> To: Christer Holmberg (JO/LMF); Jeroen van Bemmel; [email-masked]