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

From: "Elwell, John" <[email-masked]>
Date: Thu, 30 Mar 2006 07:49:15 +0100

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

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 30 Mar 2006 10:37:45 +0200

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

> Yes, this is what one thread of the discussion was about, and you seem

> to agree with #2 below
> inappropriate as you indicate.
> What about feature tags a la callerprefs (RFC3841) in Path and 
> Record-Route headers?
> 
> 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
> 
> >> >> An attempt to summarize issues identified so far, in the form of

> >> >> closed questions:
> >> >> 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)
> >> 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

_______________________________________________
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: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 30 Mar 2006 12:22:15 +0200

Hi,

Via is of course one possibility, but that changes the whole concept of
Via. However, if we want to do that, I believe we should look at it from
a more generic perspecitve, allowing nodes to also indicate other types
of capabilities.

Another option would be that the edge proxy - ASSUMING it knows it's the
edge proxy - inserts a dedicated header value. For example, the
registrar and/or other proxies may insert "outbound", but the edge proxy
inserts "outbound-edge". Then the UA will know whether the edge proxy
really supports outbound. The UA would not know which of the other
proxies support outbound, but that is maybe not important. OR, the edge
proxy should be the only node inserting support for outbound. Why should
other proxies have to do it? But, again, this assumes the proxy knows if
it is acting as edge or not.

A third option is of course to send OPTIONS to the edge proxy, but that
of course causes more traffic.

Regards,

Christer

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: 30. maaliskuuta 2006 13:10
To: 'Elwell, John'; Christer Holmberg (JO/LMF); 'Jeroen van Bemmel';
[email-masked]

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]
> 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
> 
> > From: Christer Holmberg (JO/LMF)
> > [mailto:[email-masked]]
> > Sent: 30 March 2006 09:38
> > To: Elwell, John; Jeroen van Bemmel; [email-masked]
> > 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)?
> >
> > 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)?
> >
> > 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
> >
> >
> >
> >
> > 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.
> >
> > > 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
> > >
> > > >> >> 1. Configuration of outbound proxies - desire to avoid 
> > > >> >> manual configuration at the UAC. Do we agree that we want
this?
> > > >> >> static configuration (the current keepalive=stun flag). Do 
> > > >> >> we agree that we want this? (several options have been 
> > > >> >> discussed)
> > > >> 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