Dan Pascu wrote: > What I would find useful in this case is that once a CANCEL has arrived, > all call setup activities should cease on all branches, with or without > provisional replies and if a 200 OK comes later it should be ignored and > instead a CANCEL should be forwarded to indicate that the 200 OK is late > and is no longer accepted by the originator. Maybe this is not specified > by the RFC, but I believe it to be a much better choice than to forward > the 200 OK, then ACK it and then send a BYE to close the call. >
Sending CANCEL to UAS after receiving 200 OK from the UAS will not accomplish anything because it is a no-op according to the RFC. The UAS will just ignore the CANCEL request. After UAS starts sending 200 OK your only choice is to send ACK and BYE, or not to send anything and let the INVITE transaction timeout in the UAS. I have another proposal/question. If the proxy receives CANCEL from the UAC before it received a provisional reply from the UAS, why not stop re-sending INVITEs and start sending CANCELs to the UAS? Yes, I know it is explicitly prohibited to do this in the RFC. But I do not understand the reason why. If the INVITE is lost and the UAS does not receive the INVITE and just receives CANCEL, it will just reply with 481 Transaction Does Not Exist. If the UAS received the INVITE, but the provisional response is lost then CANCEL will cancel the INVITE transaction. And this is exactly what we want. Regards, Anatoly. _______________________________________________ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel