>>I repeat the same I already said:
>>A CANCEL is not routed, not forwarded. CANCEL is hop-by-hop
>>so CANCEL destination is the proxy itself. So all the assumpitions
>>and behaviours for "request forwarding" are not necessarily true
>>for a CANCEL (in stateful proxy).
I see what you're saying but...
I still think the forwarding rules apply.
If you have a fork and the fork is CANCELed, then it
is truly the proxy that has triggered the CANCEL.
So in that case, the proxy can do what it whats.
But in other cases, the CANCEL has been triggered by
a CANCEL further down the line.
Like if a UA has started a CANCEL, then I would
expect unknown headers to get forwarded.
Consider a stateless proxy - it definitely wouldn't
strip out any header it didn't understand - for CANCEL or
any other request.
Stateful proxies are more complicated but still, I
would unknown expect headers to persist.
That is my expectation - I can't see anything
that explicitly says any of this - but this feels right
to me.
Regards,
Attila
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Iñaki Baz
Castillo
Sent: 09 February 2009 11:18
Cc: [email protected]
Subject: Re: [Sip-implementors] "Reason-Header" inCANCELthroughvariousproxies
2009/2/9 Attila Sipos <[email protected]>:
> here we go... from the "Proxy Behaviour" section
>
> 16.3 Request Validation
>
> 1. Reasonable syntax check
>
> The request MUST be well-formed enough to be handled with a server
> transaction. Any components involved in the remainder of these
> Request Validation steps or the Request Forwarding section MUST be
> well-formed. Any other components, well-formed or not, SHOULD be
> ignored and remain unchanged when the message is forwarded. For
> instance, an element would not reject a request because of a
> malformed Date header field. Likewise, a proxy would not remove a
> malformed Date header field before forwarding a request.
>
> This protocol is designed to be extended. Future extensions may
> define new methods and header fields at any time. An element MUST
> NOT refuse to proxy a request because it contains a method or
> header field it does not know about.
I repeat the same I already said:
A CANCEL is not routed, not forwarded. CANCEL is hop-by-hop so CANCEL
destination is the proxy itself. So all the assumpitions and behaviours for
"request forwarding" are not necessarily true for a CANCEL (in stateful proxy).
--
Iñaki Baz Castillo
<[email protected]>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
