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

[Maxim Sobolev]

There is no ambiguity and no B2B functionality is needed. The call is 
only "officially cancelled" when originating UA gets final negative 
reply to INVITE transaction. Sending CANCEL is not guaranteed to result 
in final negative reply to INVITE, RFC is very specific on that and any 
device/software that assumes otherwise is broken.

In the situation that you are describing, the proxy should forward 
INVITE's final positive 200 OK to the originating party and forget about 
outgoing CANCEL (initiating this transaction obviously makes no sense 
since the UAC INVITE transaction is already completed).

The originating UA at this point should have not received any final 
reply on its UAC INVITE transaction (that's the very reason why fake 487 
should never be generated when branches are pending), so that it is 
prepared to receive INVITE's 200 OK, send end-to-end ACK and follow up 
with BYE if it still wants to end up dialog.

This case is no different than when UA sends INVITE, gets provisional 
reply, sends CANCEL, but gets 200 OK to the INVITE transaction before 
CANCEL gets to its final destination due to network/processing delay. 
Any RFC-compliant device/software should be able to deal it already.

And there is no problem in the accounting either, since answering party 
actually has answered the call, so that technically it went through. If 
you think about it a little longer such situation is unavoidable in any 
signaling network that has non-zero signal propagation/processing delay, 
which basically means any physical network. There will always be 
possibility that answering party answers when initiating party has 
already hanged up but that signal is still in the transit. In fact 
situation with the previously discussed behaviour relying on no-ACK 
timeout was much worse, since in that case originating party would 
consider call as successfully canceled, while for the answering it would 
be established with non-zero duration required for the no-ACK timeout to 
fire, which is usually 30 seconds.

Dan Pascu wrote:
> What it is not clear to me in this case, is what does the proxy do if 
> there is no 1xx reply but the 200 OK comes in directly (after the CANCEL 
> was received and the INVITE continued to be retransmitted). In this case 
> it cannot send a CANCEL, or can it? Can a CANCEL be sent after a 200 OK 
> but before confirming it with the ACK, or after a 200 OK it must send an 
> ACK followed by a BYE? What about accounting in the later case, because 
> the call will appear as one that was successfully setup and with 0 second 
> duration while in reality it was canceled. The later case also implies 
> that the proxy is no longer a proxy but a b2bua since it initiates 
> dialogs on its own, dialogs that differ from what the call originator has 
> sent to the proxy.

Regards,
-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sippysoft.com