It makes sense, however I still have reservations that accounting is handled as one would expect in this case. While all the approach you details here makes sense from a technical point of view as per RFC requirements, then end user experience is different.
Consider the case where I call a number that has a high setup fee, say 5 euros only to connect even if the call duration is 0. While I wait for this call to setup, I receive no provisional reply, so my phone is not ringing. Then I change my mind and hang-up the phone. My end user expectation is that the call was not setup and I have nothing to pay for. But in reality, if there is network packet loss and a scenario like the one described before happens, the call will actually be setup and show up like a 0 second call with a 5 euro price, not as a canceled call. On Wednesday 12 March 2008, Maxim Sobolev wrote: > 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, -- Dan _______________________________________________ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel