[OpenSIPS-Devel] Limitations of dialog module

[Bogdan-Andrei Iancu]

I agree that having support for multi-early dialogs will be the best 
approach.

Internally, I think that following the TM approach (one caller multiple 
callee) will also fit, so creating for the callee part an array of 
variables (instead of a single set) will do the trick. There is not need 
to actually duplicate the whole dialog for each early dialog.

Regards,
Bogdan

Dan Pascu wrote:
> 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
>>
>>
>>     
>
>
>