Subject: RE: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK

From: "Arunachalam Venkatraman \(arunvenk\)" <[email-masked]>
Date: Wed, 24 May 2006 11:37:20 -0700

What if the Contact in the 2xx caused routing through a new proxy to the
UAS?
This could occur even if the proxies record-routed.
The Proxy_Require may not be acceptable to this new proxy. 

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Wednesday, May 24, 2006 8:55 AM
To: Michael Hammer (mhammer); Jonathan Rosenberg (jdrosen)
Cc: [email-masked]; Paul Kyzivat (pkyzivat)
Subject: Re: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK

Mike,

Yes, obviously the same "Proxy-Require: privacy" and "Privacy: header"
would need to be present in the INVITE. For this to work properly, any
proxy that accepts a Proxy-Require in an INVITE MUST Record-Route, else
the ACK would end up some place else and the scenario you describe would
occur.

For example, RFC3329 could be more explicit on this (section 4.1 message
4). 
I believe an update was being worked on?

Regards,
Jeroen

----- Original Message -----
From: "Michael Hammer (mhammer)" <[email-masked]>
To: "Jonathan Rosenberg (jdrosen)" <[email-masked]>
Cc: "Jeroen van Bemmel" <[email-masked]>; "Paul Kyzivat (pkyzivat)" 
<[email-masked]>; <[email-masked]>
Sent: Wednesday, May 24, 2006 3:51 PM
Subject: RE: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK

Maybe I misread it, but my impression was that he was adding something,
thus not a subset, thus the potential for the ACK to not reach as far as
the INVITE did.

Mike

> -----Original Message-----
> From: Jonathan Rosenberg (jdrosen)
> Sent: Wednesday, May 24, 2006 9:47 AM
> To: Michael Hammer (mhammer)
> Cc: Jeroen van Bemmel; Paul Kyzivat (pkyzivat); [email-masked]
> Subject: Re: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK
>
> You can't do that - I don't think Jeroen was suggesting it.
>
> The reason Require and Proxy-Require are allowed in ACK for
> 2xx is that there may in fact be extensions for which the ACK
> can only be processed if that extension is understood.
> However, since the ACK cannot be rejected, as Paul pointed
> out, the only Require/Proxy-Require that are permitted in the
> ACK are a subset of those in the INVITE. The theory is that
> since this set worked in the INVITE (the request was not
> rejected), the would be acceptable in the ACK, and thus there
> would never be a need to reject the ACK.
> Require/Proxy-Require in those requests are a flag that
> special treatment is required.
>
> Thanks,
> Jonathan R.
>
> Michael Hammer (mhammer) wrote:
>
> > Huh???  Why are you adding something new into the ACK that
> wasn't in the
> > original INVITE.  Seems like a good way to bugger up the
> state machine
> > by causing the transaction cleanup to go awry.  Why wouldn't the ACK
> > contain the same headers and share the same fate as the
> INVITE?  Please
> > explain.  It seems like you should wait for the retry
> INVITE to add such
> > things.
> >
> > Mike
> >
> >
> >>-----Original Message-----
> >>From: Jeroen van Bemmel [mailto:[email-masked]]
> >>Sent: Wednesday, May 24, 2006 2:33 AM
> >>To: Paul Kyzivat (pkyzivat)
> >>Cc: [email-masked]
> >>Subject: Re: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK
> >>
> >>Paul,
> >>
> >>At the very least, the current table is confusing with
> >>respect to the following text in section 8.2.2.3: "An ACK
> >>request for a 2xx response MUST contain only those Require
> >>and Proxy-Require values that were present in the initial request."
> >>
> >>Although this says "MUST contain *only*" and not "MUST
> >>contain", it seems to suggest that it is at least allowed to
> >>include a Proxy-Require in an ACK to 2xx.
> >>
> >>BTW, now that I notice: also the entry for 'Require'
> >>currently says '-' for ACK
> >>
> >>
> >>>I don't see how this makes any sense. Proxy-Require only
> >>
> >>makes sense if
> >>
> >>>a proxy that doesn't support the option can reject the
> >>
> >>request. Since
> >>
> >>>ACK gets no response there is no way to reject it.
> >>>
> >>>Paul
> >>
> >>In some cases 'Proxy-Require' is used to request certain
> >>behavior / processing from a proxy. For example in RFC3323,
> >>if "Privacy: header" is added to an ACK, the UA SHOULD add
> >>also a 'Proxy-Require: privacy' to ensure that the target
> >>supports this extension. Although the proxy would not be able
> >>to respond to the ACK, an element not supporting the
> >>extension should probably discard the ACK rather than
> >>forwarding it (without stripping the Via header as required
> >>by the extension in this case).
> >>
> >>I agree that proxy behavior for 'Proxy-Require' in ACK is
> >>different from Proxy-Require in normal requests (again: not
> >>clearly described, I'm speculating that the ACK should be
> >>dropped if not supported here). So either we disallow
> >>Proxy-Require / Require in ACK and update the text in
> >>8.2.2.3, or we modify table 2/3 and clarify proxy/UAS
> >>behavior for ACK containing these headers
> >>
> >>Regards,
> >>
> >>Jeroen
> >>
> >>
> >>
> >>>Jeroen van Bemmel wrote:
> >>>
> >>>>Table 2 in RFC3261 disallows Proxy-Require in ACK requests
> >>
> >>(i.e. it
> >>
> >>>>has a '-'). Some standards (e.g. RFC3323, RFC3329) seem
> to rely on
> >>>>the ability to include a Proxy-Require in an ACK to a 2xx
> >>
> >>response,
> >>
> >>>>although they are not very explicit on this.
> >>>> RFC3261 explicitly says that Proxy-Require MUST NOT be used for
> >>>>CANCEL or ACK to non-2xx (which are hop by hop), but I
> believe the
> >>>>intention was to allow it for ACK to 2xx. Therefore, table
> >>
> >>2 should
> >>
> >>>>say 'o' here  Regards,  Jeroen
> >>>>
> >>>>
> >>>>
> >>
> >>------------------------------------------------------------
> ---------
> >>
> >>>>---
> >>>>
> >>>>_______________________________________________
> >>>>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
> >>
> >
> >
> > _______________________________________________
> > 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
> Cisco Fellow                                   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