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

[Dan Pascu]

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.

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.

>
> 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

I think we can argue about this forever and it doesn't have a straight 
answer as it may depend on legislation in various parts of the world, but 
I think it can be argued that the b2bua makes a call in your stead since 
it uses your username at domain so you have transfered your responsibilities 
to the b2bua agent in the middle.
Besides I fail to see how a b2bua in the middle, of which you as an user 
may not even be aware of, can shield you from the consequences of your 
actions.

The problem however is when such an agent in the middle (be it a proxy or 
b2bua) acts in a different manner than the one you have asked for and 
does something you specifically asked it not to do.

> a different one, but again there could be never 100% accuracy in
> billing when signaling protocol involves some kind of delay.
>
> Regards,



-- 
Dan