[OpenSIPS-Devel] Limitations of dialog module

[Bogdan-Andrei Iancu]

Hi Iñaki,

I just added on trunk support for early dialogs and proper handling of 
PRACK requests (cseq handling).

This solves most of the problems you described here, but of course, the 
modules on top of dialog module (like callcontrol, mediaproxy, etc) 
needs to be also tuned to use the early dialog support.

What is left to do (from my perspective):

- multi 200 OK answers - this require support for sort of dialog cloning 
(when more than one 200 OK is received) - I prefer to split the current 
dialog and to let the UAC to decide what dialog to keep alive and which 
to BYE

- a new function for dialog sanity checks - for sequential requests, to 
check the cseq and the routing information (contact + route hdrs) to be 
sure that the request is not spoofed.

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