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
