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

[Dan Pascu]

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