[OpenSIPS-Devel] Limitations of dialog module

[Dan Pascu]

On Tuesday 04 August 2009, Iñaki Baz Castillo wrote:
> 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"?

Not if we confirm the dialog with the ACK instead of the 200 OK.

-- 
Dan