Subject: RE: [Sip] RFC 3261 supported header in 1xx responses

From: [email-masked]
Date: Tue, 22 Nov 2005 18:23:50 +0530

Is this different for 'Require', because in the case of session timers
proxy can add a 'Require' to request/response depending on UAC/UAS not
supporting session timers. 

-Ramakrishna

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Rosenberg
Sent: Monday, November 21, 2005 8:30 PM
To: Arunachalam Venkatraman (arunvenk)
Cc: sip-ietf; Brett Tate
Subject: Re: [Sip] RFC 3261 supported header in 1xx responses

If a proxy genreates the 1xx itself, it is effectively acting as a UAS,
in which case insertion of Supported is fine. This won't confuse a UAC
since any 1xx generated by the proxy itself will have different tags
from a 2xx or other responses generated by the actual UA, and thus
represent a different (early) dialog.

A proxy cannot insert or modify a Supported header in a response that
passes by it (i.e., one for which it is proxying).

-Jonathan R.

Arunachalam Venkatraman (arunvenk) wrote:

> Can a proxy add Supported? Is this disallowed?
> If proxy may do so, the Supported cannot be interpreted as UAS 
> capabilities, even if the 1xx is reliable (consider INVITE with 
> Require:100rel).
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> Jonathan Rosenberg (jdrosen)
> Sent: Friday, November 18, 2005 5:39 PM
> To: Brett Tate
> Cc: sip-ietf
> Subject: Re: [Sip] RFC 3261 supported header in 1xx responses
> 
> It makes sense to include them in a dialog forming response. A normal 
> 1xx is not dialog forming. My suspicion (though I didn't check if this

> was true) is that it went away when 100rel moved out of 3261. It can't

> hurt to send them, of course, but it would be ignored unless its 
> reliable.
> 
> -Jonathan R.
> 
> Brett Tate wrote:
> 
> 
>>Within early versions of draft-ietf-sip-rfc2543bis, the Supported 
>>header could be expected within 1xx responses.  However within
>>draft-ietf-sip-rfc2543bis-06 it was removed and remains so within RFC
> 
> 3261.
> 
>>Is there a reason why it is undesirable to indicate supported 
>>extensions within a 1xx?  Or was it just an oversight when changing 
>>the "Summary of header fields" table to indicate 2xx instead of all
> 
> responses?
> 
>>
>>
>>
>>_______________________________________________
>>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
>>
> 
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 22 Nov 2005 14:29:14 -0500

Yes, its different from Require. Require is not an indication of 
capabilities of a UA - its an indication that a particular extension 
needs to be applied.

-Jonathan R.

[email-masked] wrote:

> Confidentiality Notice
> The information contained in this electronic message and any attachments to this message are intended
> for the exclusive use of the addressee(s) and may contain confidential or privileged information. If
> you are not the intended recipient, please notify the sender at Wipro or [email-masked] immediately
> and destroy all copies of this message and any attachments.
>