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

[Dan Pascu]

On Wednesday 12 March 2008, Klaus Darilion wrote:
> Dan Pascu schrieb:
> > 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.
>
> You are right!

There are even other cases where this can create trouble. For those who 
find the previous example as not very likely, consider some company who 
offers support by phone. I dial to their support number and the call is 
forked to 2 destinations. One sends a provisional 183 and opens an audio 
channel where I'm informed that the call will be connected to the support 
team and I'm informed that this also implies that the connection once 
accepted will imply a support fee I have to pay or the fact that the 
conversation will be recorded or any other condition I have to willingly 
accept. The prompt then informs me that after the prompt ends, the call 
will ring for 10 seconds before being connected to the support team and 
if I do no agree with any of the terms I should hang up before that time, 
while accepting to connect means that I agree with the conditions (pay 
the fee, be recorded, whatever other conditions are specified). This 
would very much work like the current accept/reject web forms, only here 
letting the call connect is equivalent with accepting the conditions.
Now assume I do not accept the conditions and decide to hang up the call, 
thus canceling it. But the other branch than the one that has sent the 
183, has not sent any provisional reply or it got lost so it did not 
receive my CANCEL. Then it sends the 200 OK which sets up the call, even 
though I did not accept it.

Even more this can be abused. Imagine someone sets up such an environment 
where it deliberately doesn't send any provisional reply on a branch 
which is connected to some highly priced PSTN destination, that when 
ringed adds money to some bank account belonging to the person who is 
abusing this. The he may inform you over the other branch that opens a 
media session using a 183, that you have to pay a high price for the call 
(because he may be obligated to do so under law constraints), but then 
the branch answering the call may simulate network failures and not send 
any provisional replies but send the 200 OK which will connect the call 
even if meanwhile there was a CANCEL. The 2 devices in this setup may 
even communicate between them and the one that sends the 200 OK may even 
know from the other if the user has sent a CANCEL or not (because the one 
which sent a provisional 183 will receive the CANCEL).

Anyway, examples are many and I'm sure people can even find more practical 
ones. The main reason for all of them being possible, is the fact that a 
CANCEL is no longer really canceling the call under these circumstances, 
and that the user is stripped from it's ability to control if a call 
should end or not before being setup, by random conditions (network 
packet loss) or purposeful abuses of the protocol behavior.

>
> > 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.
>
> Dan, you should post this example on the SIP-implementors mailing list.
> I wonder what the SIP experts will say to this examples.

Klaus, I'm not subscribed to that list. Can you please forward there 
whatever you think can help to get a better resolution for the 
discussion?

-- 
Dan