Subject: RE: [SIP] Re: About Proxy-Supported and Proxy-Unsupported

From: [email-masked]
Date: Fri, 9 Jun 2000 14:30:20 +0300

Hi,
> > This isn't quite symmetric to Require. Would proxies add or subtract
> > features from the "Proxy-Supported" and "Proxy-Unsupported" list?
> > (Presumably subtract and add, respectively...) Would only 
> those proxies
> > that are on the record-route be allowed to do this?
> 
> We discussed these and other issues in the past on the list 
> (in fact, I
> posted a note outlining every possible combination of who needs what
> features from who else); it turned out to be overly complicated, and
> there were no real applications for it. So, we solved the 
> basic problem
> which there was a clear need for.
> 
> You mention some application in 3G registration. Can you elaborate on
> that?
> 
> -Jonathan R.

I have been thinking that problem also. Initially, the idea behind
Proxy-Supported was that only one proxy (in the visited network) describes
the capabilites available in the visited domain (capabilities specific to
3G) and that REGISTER message is then forwarded into the home network.  

Other proxies should not be allowed to touch the Proxy-Supported header.

If Proxy-Supported/UnSupported are used to describe the capabilities of
several 
SIP proxies along the route, then subtract/add should be applied 
by each proxy (but then we end up with problems, e.g. proxies in 
different domains can not be trusted as much as local proxies etc).

Maybe the name of the proposed Proxy-Supported header should be changed 
to something like "Local-Proxy-Capabilities", or "3G-local-capabilities".

--
Petri

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Adam B. Roach" <[email-masked]>
Date: Fri, 9 Jun 2000 06:46:45 -0500 (CDT)

>to something like "Local-Proxy-Capabilities", or "3G-local-capabilities".

Perhaps. I beleive you're a bit confused about the semantics of
the Supported: header. It is used to denote that certain SIP extension
drafts are supported, not capability sets within a service architecture.

For example, you may want to define an extension (the name of
which would go in the "Supported" header) which defines how to
negotiate the version of a service triggering protocol (this information
would go in a new header defined by the above mentioned extension draft).

You can't really mix the ideas.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA