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

[Dan Pascu]

On Thursday 13 March 2008, Maxim Sobolev wrote:
> My
> point is that with the new behavior you will get better chances to not
> get into this issue at all in the first place, unless answering party

This new behavior is exactly what gets you in this situation. Maybe we 
refer to different things when we say "get into this situation". Thus to 
avoid any ambiguities, the situation I'm referring to is the fact that 
with the new behavior a CANCEL no longer immediately terminates the call. 
Even if a CANCEL arrives, a call may still be setup with a 200 OK + and 
ACK and then immediately closed by a BYE, which is a conceptually a 
completely different beast that a simple CANCEL that terminates the call 
without it being setup.

> is in fact hostile and deliberately not sending provisional replies.
> And the "hostile" issue has been addressed in another message of mine.

Or by having network packet loss, which is not under your control, 
nor "hostile".

> On a serious note, though, I am not a lawyer myself, and as such I
> can't make any professional judgments, but in my purely common sense
> view should the issue arise the fact that the proxy has received CANCEL
> indicating that user has actually hanged up should be enough to resolve
> the case. You can bring technical expert who would testify in court
> that this sequence of SIP messages actually means that the call has not
> completed. Judges doesn't read RFCs and protocol logs and rely on
> independent expert opinion to decode and explain those things in plain
> words, so that I am pretty sure the whole "binding" point is moot as
> any technical expert who knows SIP will be able to decode this
> properly.

We can dance around the wording as much as you like, but the fact remains 
that a canceled call may still be connected just to be immediately 
closed, which is not what the user has asked for when he canceled the 
call.

If I'm told by my provider that me putting the phone on hook before it is 
answered may result in the call still being setup and connected, but that 
he has a team of technical experts ready to help me prove I didn't make 
the call, I will not bother to use that service because I do not want to 
waste time to prove I wasn't at fault in some situation. He didn't take 
measures to eliminate the problem, and while he helping me to prove I'm 
not at fault may help, it doesn't help me not to get into the situation 
in the first place.

I rest my case here, because we can argue like this forever and I said all 
I had to say. I'd like to see that if such a thing is implemented, that 
we have a choice not to enable it.

-- 
Dan