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)" <mhammer cisco.com>
To: "Jonathan Rosenberg (jdrosen)"
<jdrosencisco.com>
Cc: "Jeroen van Bemmel" <jbemmelzonnet.nl>; "Paul Kyzivat (pkyzivat)"
<pkyzivatcisco.com>; <sipietf.org>
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); sipietf.org
> 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:jbemmelzonnet.nl]
> >>Sent: Wednesday, May 24, 2006 2:33 AM
> >>To: Paul Kyzivat (pkyzivat)
> >>Cc: sipietf.org
> >>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://ww
w1.ietf.org/mailman/listinfo/sip
> >>>>This list is for NEW development of the
core SIP Protocol Use
> >>>>sip-implementorscs.columbia.edu for
questions on current sip Use
> >>>>sippingietf.org for new
developments on the application of sip
> >>
> >>
> >>_______________________________________________
> >>Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
> >>This list is for NEW development of the core
SIP Protocol Use
> >>sip-implementorscs.columbia.edu for
questions on current sip
> >>Use sippingietf.org for new
developments on the application of sip
> >>
> >
> >
> > _______________________________________________
> > Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP
Protocol
> > Use sip-implementorscs.columbia.edu for
questions on current sip
> > Use sippingietf.org for new developments on the
application of sip
> >
>
> --
> Jonathan D. Rosenberg, Ph.D. 600
Lanidex Plaza
> Cisco Fellow
Parsippany, NJ
> 07054-2711
> Cisco Systems
> jdrosencisco.com FAX: (973)
952-5050
> http://www.jdrosen.net
PHONE: (973) 952-5000
> http://www.cisco.com
>
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|