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

[Dan Pascu]

On Wednesday 12 March 2008, Jan Janak wrote:
> Dan Pascu wrote:
> > 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.
>
>   The same can happen even if you receive a 180 and hangup while the
>   phone is ringing. I, as a user, would expect not to be charged, but
> if a 200 OK made it to the server then I would probably see it on my
> bill.
>

That is not the case. If a 200 OK happens to come at the same time with 
the CANCEL and there is a race condition and the call does get setup and 
charged, I can explain my subscriber that he happened to put the call on 
hook at the same time it was answered by the other side and it was just 
the fact that it was answered while he was placing it on hook. He can 
understand that.

But if I tell my subscriber that he has put the phone on hook effectively 
canceling the call, but a 200 OK came out of nowhere 10 seconds later and 
did setup a session despite the user indicating it has no intention to 
carry on with it, that there was no race condition, but simply the system 
ignored his request because there was packet loss and the RFC mandates 
that it has to wait for some timers to expire, that he won't understand.

Try to tell your subscribers that your wonderful next generation VoIP 
system takes away their ability to cancel a call, that it may randomly 
(based on network packet loss) decide to setup a call at a later time 
despite the user canceling it, and do this based not on an understandable 
race condition situations, but on purpose, and see how many of them would 
want to use your system.

The new issue that is introduced by this approach is that it takes away 
control from the user when canceling the call. There is a fundamental 
difference between a canceled call and a call that is answered and closed 
immediately. If that would have not been the case, then this would have 
not been an issue, but unfortunately it is. And the feeling a user has 
from the system behaving under these (RFC conforming) rules, is that it 
doesn't matter that he decided to cancel the call, the system may still 
decide to go through with it, not based on some race condition, but on 
purpose.

>   So the race condition is there in anyway. If you want to be just to
>   your users then you probably should charge the high setup fee only if
>   the call took at least a few seconds.

All these workarounds do not address the real problem (the fact that my 
ability to cancel a call is taken away) and they may not even help (see 
below).

>
>   Seeing a high setup fee on your bill and a call duration of 0 looks
>   strange in any case, no matter what was going on in signalling.

That's my point exactly. But we are operating here under the assumption 
that we have packet loss. Which means that the BYE may not go trough 
immediately, but will also start a series of retransmissions and in the 
end the call will appear to have taken a few seconds.

-- 
Dan