[OpenSIPS-Devel] Limitations of dialog module

[Dan Pascu]

On Tuesday 04 August 2009, Bogdan-Andrei Iancu wrote:
> Hi Iñaki,
> 
> thanks for putting all these together. I will start looking over and see 
> what needs to be fixed and how can be fixed.

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.

The nat_traversal module already does something similar. It keeps track of all 
endpoints from all branches while the dialog is in a provisional state, then 
when the 200 OK is received it will discard the endpoints from the unanswered 
branches. If the dialog module would do this, then every other module could 
benefit from the same logic.

IMO the way to do this would be to keep a linked list of the "virtual dialogs" 
inside the dialog (or a list of potential dialogs if you want). Eventually 
allow access to this in case a higher module needs some info from it and then 
provide a pair of callbacks: dialog_branch_created and dialog_branch_destroyed 
to notify a module using the dialog module of what is happening.
Maybe more callbacks would be necessary to notify provisional replies inside 
these virtual dialogs, or maybe we can use what we already have but just add 
some extra branch id to the callback data to indicate to which of the virtual 
dialogs the provisional reply belongs. Same for methods sent during the 
provisional state, like PRACK or UPDATE.

> 
> Thanks and regards,
> Bogdan
> 
> Iñaki Baz Castillo wrote:
> > Hi, some threads ago I talked about dialog module limitations and how
> > those limitations are inherited in modules on top of it. I will list
> > them here again as a separate thread (as Bogdan asked). Note that most
> > probably I'll say nothing new.
> >
> >
> > - Parallel forking:
> > dialog module just creates a "dialog" entry for each incoming request,
> > even if the proxy forkes the request to varios destinations in
> > parallel.
> >
> > - PRACK and CSeq:
> > Dialog module stores the local and remote cseq for a dialog, but cseq
> > can also change during an early dialog (PRACK and UPDATE methods). In
> > fact, each early dialog can have a different local/remote cseq if
> > PRACK and/or UPDATE occurs for that *early* dialog.
> > Since dialog modules jsut creates one entry for that dialog, the value
> > of local/remote cseq is unreliable. If this value is used to generate
> > a local BYE it could be incorrect. Example:
> >
> >   UAC              PROXY               UAS1       UAS2
> >
> > - UAC sends the INVITE with CSeq 1.
> > - PROXY does parallel forking to UAS1 and UAS2.
> > - dialog entry has "local_cseq = 1".
> > - UAS1 replies 180.
> > - UAS2 requires PRACK.
> > - UAC sends in-dialog PRACK to UAS1 (CSeq = 2).
> > - UAS2 replies 200 OK
> > - UAC sends ACK to UAS2 (CSeq = 2).
> > - Dialog timeout so the proxy generates a BYE to UAS2 with CSeq =
> > local_cseq + 1 = 2.
> > - UAS2 rejects the BYE because it has a wrong CSeq = 2 (it should be
> > at least 3).
> >
> >
> > - Call Control:
> > For a PSTN gateway, an established or in progress call is similar
> > (both requires similar resources in the gw). If a request is forked to
> > 5 different SIP URI's, and all of them are sent to the same GW, the
> > dialog module just counts "1 dialog" for that gateway.
> >
> >
> > - CSeq spoofing:
> > If a top level module relies on the existance of an active dialog, it
> > could suffer if the caller/callee does CSeq spoofing. Example:
> >
> > - Alice calls BOB (Alice CSeq = 1).
> > - Alice sends a spoofed BYE wth CSeq = 1.
> > I don't know if dialog module will automatically end or requires to
> > receive a 200 for that BYE:
> >
> > a) Suppose dialog entry is terminated:
> > - But Bob rejects the BYE (bad CSeq).
> > - If Bob doesn't end the dialog by itself, it remains active even if
> > dialog module terminated it.
> >
> > b) Suppose dialog entry is not terminated until receipt of 200 for the 
BYE.
> > - Bob rejects the BYE (bad CSeq).
> > - Perhaps Bob owuld automatically end the dialog without sending a BYE
> > so dialog module doesn't realize of it.
> >
> >
> > - Media Proxy  engage_media_proxy()
> > A method on top of dialog module. In case you want rewrite the SDP
> > just in case the receiver is behind NAT, it's cannot be done if the
> > request is forked and receives various responses, some from natted
> > clientes and some from non natted clients. This is, it must be
> > modified (or not modified) for all the branches. This wouldn't occur
> > if the dialog module would create an entry for each *early dialog*
> > (this is the core missing feature of all this report).
> >
> >
> >
> > Now I read about new b2bua module and wonder if the above would also 
occur.
> >
> >
> > Regards.
> >
> >
> >
> >
> >
> >
> >
> >
> >   
> 
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
> 
> 


-- 
Dan