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

[Andrei Pelinescu-Onciul]

On Mar 12, 2008 at 23:57, Dan Pascu <dan at ag-projects.com> 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.

The caller will receive the 200, the difference is that it will receive
it after a 487.
There are 2 cases:
 - the transaction is already dead when the 200 arrives => the 200 reply
   is forwarded statelessly
 - the transaction is still alive (on the "wait" timer) => even in this
   case a 2xx reply will be forwarded (2xx after final reply). This is
   true in all ser versions and most likely in openser too (unless there
   were some major tm changes).

If the UA would send or not an ACK to this 200 after 487 I guess is
implementation dependent (the 200 will even have a different totag from
the 487 so the UA might even think it deals with different dialogs 
established due to forking). I think most UAs would drop the 200, but
you cannot rely on it.

[...]

Andrei