[OpenSIPS-Devel] Limitations of dialog module

Thomas Gelf thomas at gelf.net
Mon Aug 3 15:46:33 CEST 2009


100% ACK - I'd consider making the dialog module branch-aware a really
important (even if difficult) task. As more and more modules are going
to rely on it, support for a such generic thing as multiple parallel
branches is IMO a must. But please don't ask me how to do so ;-)

As Iñaki mentioned, engage_media_proxy is such an example. And as people
with multiple registrations are not seldom I need to switch my config
back to manual Mediaproxy handling. Did not yet stumble over the PRACK
issue as I do not (yet) tear calls down at proxy side.

Right now I'm studying b2bua-docs, trying to understand how it works
and what it can do ;-)

Cheers,
Thomas


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