2011/4/19 Iñaki Baz Castillo <[email protected]>: > Hi, according to RFC 3261 - 16.10 CANCEL Processing (Proxy) > > If a response context is not found, the element does not have any > knowledge of the request to apply the CANCEL to. It MUST statelessly > forward the CANCEL request (it may have statelessly forwarded the > associated request previously). > > > In my case I do know that my proxy doesn't behave as a stateless proxy > so I see no reason to forward a CANCEL if it doesn't match a server > transaction. Could then the proxy generate a 481 by its own? or should > it discard the CANCEL request and reply nothing?
Another related question: RFC 3261 - 16.10 CANCEL Processing says: While a CANCEL request is handled in a stateful proxy by its own server transaction, a new response context is not created for it. Instead, the proxy layer searches its existing response contexts for the server transaction handling the request associated with this CANCEL. If a matching response context is found, the element MUST immediately return a 200 (OK) response to the CANCEL request. In this case, the element is acting as a user agent server as defined in Section 8.2. Furthermore, the element MUST generate CANCEL requests for all pending client transactions in the context as described in Section 16.7 step 10. It doesn't check the server transaction state. I expect that a stateful proxy must only reply 200 for a CANCEL in case its associated INVITE server transaction is in Proceeding state (no final response has been sent yet). So, if a proxy receives a CANCEL for an INVITE transaction whose server transaction is in state Completed, Confirmed, Accepted or Terminated, should the proxy reply 200? or 481? or nothing? Thanks a lot. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
