[OpenSIPS-Devel] Limitations of dialog module

Bogdan-Andrei Iancu bogdan at voice-system.ro
Tue Aug 4 04:25:17 CEST 2009


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.

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




More information about the Devel mailing list