Subject: [Sip] Discussion: draft-hoeneisen-sip-proxy-supported-00.txt]

From: Dean Willis <[email-masked]>
Date: Thu, 19 Jul 2001 22:55:03 -0500

Ok, my turn to be obtuse. What's the difference between the goal of this 
draft and

draft-ietf-sip-serverfeatures-04.txt?

--
Dean

-------- Original Message --------
Subject: [Sip] I-D ACTION:draft-hoeneisen-sip-proxy-supported-00.txt
Date: Mon, 16 Jul 2001 07:01:31 -0400
From: [email-masked]
Reply-To: [email-masked]
To: IETF-Announce: ;
CC: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: The SIP Proxy-Supported header field
	Author(s)	: B. Hoeneisen et al.
	Filename	: draft-hoeneisen-sip-proxy-supported-00.txt
	Pages		: 11
	Date		: 13-Jul-01
	
The Session Initiation Protocol (SIP) provides a mechanism that
allows a User Agent Client (UAC) to request that a particular
protocol extension has to be used to process the request. The User
Agent Server (UAS) declines the request if it does not support the
extension. Recently also means have been defined for the User Agent
Server (UAS) to determine which extensions are supported by the User
Agent Client (UAC). Furthermore there are also means for requiring
proxy servers to understand certain features.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hoeneisen-sip-proxy-supported-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-hoeneisen-sip-proxy-supported-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-hoeneisen-sip-proxy-supported-00.txt".
	
NOTE: 
The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: 
<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-hoeneisen-sip-proxy-supported-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-hoeneisen-sip-proxy-supported-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: 
<[email-masked]>

--OtherAccess--

--NextPart--

_______________________________________________
Sip mailing list  http://www.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  http://www.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]
Date: Wed, 25 Jul 2001 19:12:02 +0300

Hi Christer!

>-----Original Message-----
>From: ext Christer Holmberg [mailto:[email-masked]]
>Sent: 23. July 2001 15:43
>To: [email-masked]
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: Re: [Sip] Discussion:
>draft-hoeneisen-sip-proxy-supported-00.txt]
>
>
>
>Hi,
>
>My comments...
>
>In general, I think it is a good idea if proxies somehow can indicate
>features that they support. For example, in the discussion about to be
>able to CANCEL a specific call-leg I mentined that the UAC could use
>that information to decide if to keep or cancel a call-leg etc etc. In
>the forward direction it can also be used by proxies to 
>decided where/if to fork a request (yes, this IS related to
>the caller preferences draft).

Thanks for your feedback.

>My opinion about your proposal (I DID understand the draft - I hope :),
>though, is that I think you try to make things too complicated.
>
>First, why do we need a new header (Proxy-Supported) for this? 
>Why can't
>the Supported header be used, and the proxies can then check the option
>tags and add Record-Route parameter(s) if needed.

Yes, we were thinking about Supported header as well.

However, we found some reasons against _redefining_ the Supported header
field:

- In a standard we'd need a clear separation of _User_Agent_supported_ and
_proxy_supported_ features. This to keep the protocol flexible and logical.

- Some features would only need support in the UA, whereas some would
require also support by proxies. There would need to be a way to distinguish
between the two as is the case with the separation of Require and
Proxy-Require. For example 100rel would only be a Supported tag, while
s100rel (as we proposed), would be a Proxy-Supported one.

>Second (and this is what I think makes it complicated) is the proposal
>that the proxies shall remove option tags from the header, and remove
>the whole header if there are no more option tags innit... I 
>don't think
>this is necessary. The UAS, and the UAC, simply have to check the
>Record-Route headers to check if all proxies support a 
>specific feature.
>Yes, it takes a little more time, but it is more simple.

In principle, this would be one way to go.
But we were thinking about implementations, which either encrypt or remove
the Record-Route header field(s) from the Request and store them locally, as
e.g. 3GPP wireless networks do. (This is not nice, but the chances are we
have to live with it.) If this is the case, a proxy server would have to
evaluate all the rr-entries (including its own) and put the result into its
own rr-entry. Such an entry would not look anymore logical, as it is a
mixture of "its own" entry and the entries it encrypts or removes.
Furthermore, in case, there are many features listed in Proxy-Supported and
many proxy servers, the message length increases quite much.

Using the approach described in the I-D, after one proxy server removes an
entry from Proxy-Supported (or the whole field), the UAS and the following
proxy servers do not have to care anymore about the whole issue. This can
save some time, if there are many proxy servers in a signalling path.

br,
 Bernie

>Regards,
>
>Christer Holmberg
>Ericsson Finland
>
>
>
>
>
>
>
>[email-masked] wrote:
>> 
>> Hi Sean!
>> 
>> >-----Original Message-----
>> >From: ext [email-masked] [mailto:[email-masked]]
>> >Sent: 20. July 2001 22:38
>> >To: [email-masked]; [email-masked]
>> >Cc: [email-masked]
>> >Subject: RE: [Sip] Discussion:
>> >draft-hoeneisen-sip-proxy-supported-00.txt]
>> >
>> >
>> >With Proxy-Require, it is clear what is intended:
>> >you require every proxy on the path to support/use
>> >a given extension. With Proxy-Supported, this is
>> >more difficult. You are querying for the (optional)
>> >support of a feature.
>> 
>> Could you please outline a bit further, what is
>> unclear with "Proxy-Supported"?
>> 
>> >What does it mean for 3 out of 4 proxies to support
>> >a given feature?
>> 
>> Sorry, but I don't understand this question.
>> Could you please describe the issue a bit further.
>> 
>> >The biggest problem I see with this approach is
>> >that it doesn't work for the initial request (e.g
>> >INVITE). Most features that come to mind need to
>> >be invoked on the initial request and possibly
>> >subsequent requests for a call.
>> 
>> First of all: "Proxy-Supported" is _not_ intended to
>> be a general replacement for "Proxy-Require".
>> (I wasn't sure, whether this has been misunderstood.)
>> 
>> With "Proxy-Supported" a proxy server knows latest
>> about the feature support in all proxies (which
>> remain in the signalling path for subsequent
>> requests), when the first (non-100Trying) response
>> to the INVITE is arriving at the proxy server.
>> For certain features this is early enough.
>> 
>> But the more important cases are, where certain
>> features are used only in subsequent requests.
>> One example is described in
>> http://www.ietf.org/internet-drafts/draft-kiss-sip-s100rel-00.txt,
>> which proposes a light way of the provisional
>> response acknowledgement.
>> 
>> The main goal of the "Proxy-Supported" proposal is,
>> that in those cases, where certain features are used
>> only in subsequent requests, an INVITE goes through
>> to the UAS even if one (or more) proxy servers do not
>> support one (or more) listed feature.
>> 
>> Furthermore it addresses only those proxy servers,
>> which remain in the signalling path for subsequent
>> requests.
>> 
>> Hope things got more clear now...
>> 
>> br,
>>  Bernie
>> 
>> >
>> >regards,
>> >sean olson
>> >
>> >>-----Original Message-----
>> >>From: [email-masked] 
>[mailto:[email-masked]]
>> >>Sent: Friday, July 20, 2001 11:30 AM
>> >>To: [email-masked]
>> >>Cc: [email-masked]
>> >>Subject: Re: [Sip] Discussion:
>> >>draft-hoeneisen-sip-proxy-supported-00.txt]
>> >>
>> >>
>> >>Hi Dean,
>> >>
>> >>Dean Willis wrote:
>> >>>
>> >>The main difference is, that with the Proxy-Supported mechanism
>> >>the intermediate _proxy_servers_ are queried for support of certain
>> >>features, whereas the draft-ietf-sip-serverfeatures-04
>> >>(Supported header field) describes a mechanism, where the
>> >>_User_Agent_ informs about features itself supports.
>> >>
>> >>This proposal (Proxy-Supported) somehow complements the 
>Proxy-Require
>> >>mechanism. With Proxy-Supported a request goes through even if one
>> >>(or more) of the intermediate proxy servers doesn't support an
>> >>indicated extension, whereas Proxy-Require results in an error
>> >>response in the proxy server.
>> >>
>> >>Hope this answers your question.
>> >>
>> >>br,
>> >> Bernie
>> >>
>> >>>
>> >>>--
>> >>>Dean
>> >>
>> >>------------ Original Message --------
>> >>Subject: [Sip] I-D 
>ACTION:draft-hoeneisen-sip-proxy-supported-00.txt
>> >>        Filename        : 
>draft-hoeneisen-sip-proxy-supported-00.txt
>> >>        Pages           : 11
>> >>        Date            : 13-Jul-01
>> >>
>> >>http://www.ietf.org/internet-drafts/draft-hoeneisen-sip-proxy-s
>> >upported-00.t
>> >xt
>> >
>> >        "FILE
>> >/internet-drafts/draft-hoeneisen-sip-proxy-supported-00.txt".
>> >