On Mar 12, 2008 at 23:57, Dan Pascu <[EMAIL PROTECTED]> 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 _______________________________________________ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
