On Thu, 2006-05-18 at 18:41 -0400, Paul Kyzivat wrote: > Because this is a bug where the fix hasn't been formally fixed, I don't > think it is safe to assume *either* that it has been fixed or it hasn't. > So I think a BCP should allow both, with an explanation.
As Venkatesh points out, fixing the bug wouldn't change the apparent behavior from the UAC's point of view, as CANCEL is hop-by-hop and a 200 response to it can only indicate that the next (stateful) hop has a record of the request in question, and cannot be guaranteed to tell about the UAS's state. But even without that point, it's clear that the interaction of CANCEL and a transaction is messy, and there's a lot of uncertainty and disagreement on the proper response codes for CANCEL, and implementations are likely to be inconsistent. So one should judge whether a CANCEL worked or not only by the response to the INVITE, which is something implementations are likely to get right. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
