[OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches

[Anatoly Pidruchny]

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.