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 _______________________________________________ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel