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 _______________________________________________ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
