[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:
>> If you want to isolate ingress and egress dialog state and bill user
>> only for what he has actually sees use b2bua. Then you will be able to
>> end ingress call with 487 immediately upon receiving CANCEL and don't
>> bill user for anything that happens on the other side after that,
>> letting egress calls to complete independently and not affect what user
>> sees in her bill.
> 
> I disagree. As I said it's not a matter of billing, it's a matter of 
> making a connection where you do not want to. Even if your b2bua 
> immediately ends your leg, it may still have the same issue on the 
> outbound leg and connect to the service you refused to connect to. While 
> the b2bua can chose not to emit a bill for that call because it knows the 
> context, it cannot isolate you from the potential legal bindings that 
> result from making a connection to that address. Rest assured that the 
> other side will consider the original caller as connected to that service 
> and that he has accepted all the terms and conditions since he has made 
> the connection and will have no clue that a b2bua is in the path and some 
> entity that cannot be made legally responsible (the b2bua) is connected 
> instead.
> 
> In the end it resumes to the fact that the protocol allows for another 
> entity in the network to have control over me canceling a call and that I 
> have no control over my own device's behavior, which is a shortcoming in 
> the protocol IMO.

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.

In fact I don't think there is real "binding" when you are using B2BUA, 
since you can prove that no actual session has been established between 
endpoints (originating device never sees that 200 OK). Billing issue is 
a different one, but again there could be never 100% accuracy in billing 
when signaling protocol involves some kind of delay.

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