[OpenSIPS-Devel] Limitations of dialog module

[Bogdan-Andrei Iancu]

Hi Inaki,

I finally manage to find a larger time slot to read and digest your 
email. so here I'm coming back with some comments.

First of all, the dialog module was not design to care about the early 
stage of the dialog, but to care only about the "mature"/confirmed 
dialogs. Because of this, there is no real support for early dialogs, 
but I do agree it is the time to reconsider and implement this.

The cases you raised are perfectly valid (some are addressing bugs - 
like the PRACK stuff, other limitations of the module - support for 
early dialogs).

But bottom line, I see two classes of things to be addressed:
    1) support for early dialogs
    2) more sanity checking on the sequential requests (routing 
(Route+Contact) , Cseq validity, etc).

I will start looking into the code to see how to deal with this...

Thanks for your work on this!

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.
>
>
>
>
>
>
>
>
>