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

[Maxim Sobolev]

Dan Pascu wrote:
> On Wednesday 12 March 2008, Maxim Sobolev wrote:
>> No, it's not. Any protocol involving communication delay would have
>> this problem. It's just the matter of how big the window of opportunity
>> actually is.
>>
>> And frankly I don't see how previous behavior is better in that
>> example. It still quite possible that the "other branch" mentioned
>> there would actually have received INVITE, sent provisional reply,
>> which simply got lost in transit, so that it happily answers the call
>> in 10 seconds afterwards. So that whatever legal "binding" could be
>> it's all here. In fact, the new behavior, which would continue INVITE
>> retransmits has a better chances to relay CANCEL to that branch in
>> time, due to the fact that it would stimulate retransmission of
>> provisional reply even after CANCEL has already been received.
> 
> With the current behavior, the caller never receives the 200 OK and 
> doesn't send an ACK to confirm it, so he can claim that he has not 
> accepted the call and his claim is sustained by the sip trace. and the 
> fact that the other side never receives a confirmation (ACK) for the 
> call.

You are contradicting yourself. In the previous message you have said 
that this doesn't matter as long as answering party has sent 200 OK. 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 is 
in fact hostile and deliberately not sending provisional replies. And 
the "hostile" issue has been addressed in another message of mine.

> With the new behavior, the user receives the 200 OK, it has to ACK it and 
> then close the call with a BYE, which by any measure means he accepted 
> the call, even though it was done by the device and the user may even be 
> unaware of what happened. Of course the device can chose to ignore the 
> 200 OK and not send an ACK, though I'm sure some purists will claim it is 
> not RFC conformant, but in the end we only move the behavior from the 
> proxy to the phone.

To continue your logic this should transfer responsibility
from user to his device so that the callee should sue the device 
instead. :)

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.

Regards,
-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sippysoft.com