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

From: [email-masked]
Date: Mon, 23 Jul 2001 14:22:31 +0300

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:
>>>
>>>Ok, my turn to be obtuse. What's the difference between the 
>>goal of this 
>>>draft and
>>>
>>>draft-ietf-sip-serverfeatures-04.txt?
>>
>>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
>>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-s
>upported-00.t
>xt
>
>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".
>
>_______________________________________________
>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: Christer Holmberg <[email-masked]>
Date: Mon, 23 Jul 2001 15:42:50 +0300

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).

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.

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.

Regards,

Christer Holmberg
Ericsson Finland