2011/6/11 Joegen E. Baclor <[email protected]>: > I agree with this. Yes I followed this thread closely from the start. The > question was a "why" (not where it is stated in the RFC) for the sake of > those, including myself, understand how a very basic scenario such as call > cancellation gets this very lengthy discussions up to now. Clearly, > misinterpretation due to vagueness is the cause.
My first question in the thread was similar to your previous one: "does the server/client transaction *status* change in the proxy when a CANCEL is received by it (so algo generated by it)?". The answer is not, nothing changes in the proxy's server/client transactions. Instead, the UAS's are supposed to reply 487 upon receipt of the CANCEL, and such 487 will terminate client transaction(s) in the proxy, and at the end, will also terminate the server transaction in the proxy (when it forwards the winning final reply upstream). Later in the thread I asked about how a proxy should behave when receives a CANCEL but cannot cancel pending branches because no 1XX response has been received yet from them. In the exotic case in which some branch replies a later 1XX the proxy should automatically send the CANCEL downstream (but it should still forward the 1xx response to the UAC). -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
