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

Dan Pascu dan at ag-projects.com
Wed Mar 12 21:39:49 CET 2008


On Wednesday 12 March 2008, Maxim Sobolev wrote:
> Dan Pascu wrote:
> > 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.
>
> All this has nothing to do with the SIP, really. 

I would say it has everything to do with SIP, being part of the SIP call 
setup negotiation. Which is more than I can say for solving network 
packet loss problems at the SIP protocol level.

If you would have paid attention to all the examples I mentioned, you'd 
have seen that the main issue is not some miscalculated accounting entry, 
but the fact that the user is stripped of his ability to cancel a call he 
does not want to make because he doesn't agree with the terms and 
conditions that result from making that call. The consequences that 
result from the user being forcefully connected to the destination 
despite his refusal to do so are far more problematic that a 
miscalculated accounting entry and can even result in users being legally 
bounded to something they do not want or accept.

> It just illustrates the 
> point that SIP proxy is bad choice for real-time VoIP accounting. If you 
> use B2BUA, all those concerns go away, as you will get two separate SIP 
> calls, so that your ingress call is isolated from any issues with 
> egress, such as packet loss and so on.

While I notice the subtle advertisemet of a b2bua solution here, let's 
focus on solving the issues that would be introduced in openser by 
implementing this new CANCEL handling (something that you proposed in the 
first place). While I can see that the proposed change satisfies RFC 
requirements and is endorsed by SIP experts, I cannot ignore the fact 
that it changes the end user experience in a fundamental and undesired 
way.

-- 
Dan



More information about the Devel mailing list