[OpenSIPS-Devel] Limitations of dialog module

[Iñaki Baz Castillo]

2009/8/4 Dan Pascu <dan at ag-projects.com>:
> The easiest way to fix them would be for the dialog module to keep around
> "virtual dialogs", for as long as it's in a provisional state. Such a virtual
> dialog will keep track of a branch and when a final reply is received, it will
> destroy all of them except for the one on the branch that got the final 200 OK
> reply, which will become the real dialog from that point on. This way each
> branch can live on its own and have the CSeq updated independently of the
> others.

That makes sense but, what would occur in the exotice RFC3261 case in
which  two (or more) 200 OK replies are received at the same time?
AFAIK for now OpenSIPS terminates the INVITE transaction (not 100%
true since it matches the following ACK) when the first 200 arrives,
so the second 200 is bypassed stateless to the UAC. In this moment the
UAC has two active dialogs and "should" terminate the second one
(sending an ACK followed by a BYE).

However, there is a draft
(http://tools.ietf.org/html/draft-sparks-sip-invfix) updating this
behaviour so the proxy keeps the transaction in memory after receipt
of the first 200 and absorvbs other 200 replies. I added a tm
parameter in Kamailio for this purpose (it basically drops any reply
matching no transaction):
  http://kamailio.org/docs/modules/1.6.x/tm.html#id2530689

But if this behaviour is not implemented, could it affect the design
you suggest for "virtual dialogs"?

Regards.


-- 
Iñaki Baz Castillo
<ibc at aliax.net>