[sr-dev] improving the dialog module

[Daniel-Constantin Mierla]

On 03/16/2010 08:39 PM, Timo Reimann wrote:
> Hey Iñaki,
>
>
> Iñaki Baz Castillo wrote:
>    
>> 2010/3/12 Timo Reimann<timo.reimann at 1und1.de>:
>>
>>      
>>> If so, my major concern with this approach is that it will break dialog
>>> callback functionality. If a dialog user, upon creation of an
>>> unconfirmed dialog (initial request received), registers for further
>>> callbacks associated with that dialog (for instance, DLGCB_CONFIRMED),
>>> it won't get any further callbacks in the scenario outlined above. The
>>> reason for this is that when the dialog is terminated due to the 5xx
>>> response, all associated callbacks will be swept out too, and the
>>> re-created dialog's structure will not contain any callbacks yet.
>>>        
>> A suggestion to cover all the cases:
>>
>> There could be two kinds of dialog entries in the module:
>>
>> - dialog-in: It's a *single* dialog entry generated upon receipt of
>> the INVITE. No info about To-tag is stored with it. It has a status
>> field (none, early, confirmed, terminated), but this status is handled
>> carefully (see below). This entry exists until the dialog or
>> early-dialog is terminated. Callbacks are inserted *here*.
>>
>> - dialog-out: It's a single or multiple entries pointing to a single
>> dialog-in entry. It contains a To-tag and status fields. A dialog-out
>> is generated when a response for same Call-ID and From-tag is received
>> and contains a new To-tag. Status for each dialog-out is updated
>> according to the status of the response (early, confirmed,
>> terminated). No callbacks are inserted here.
>>
>> When a dialog-out is generated (provisional response received) it
>> updates the dialog-in status to "early" (so callback is raised), but
>> just in case the dialog-in status was "none".
>>
>> When a dialog-out receives a (200 it also updates the dialog-in status
>> to "confirmed" (so callback is raised), just in case it was in "none"
>> or "early" status.
>>
>> When a dialog-out is terminated ([3456]XX response received) it *just*
>> updates the dialog-in status to "terminated" in case there are no more
>> alive dialog-outs  (for parallel forking cases) and *also* in case the
>> INVITE transaction has terminated (for serial forking cases in which
>> still there is no new branches).
>>
>>
>> I think that with this approach all the cases are covered. Opinions?
>>      
> Interesting idea. Let me ask two questions:
>
> (1) I re-checked when dialog state is modified exactly for responses
> (and believe I have to doubt what I initially claimed to be true):
>
> According to dlg_handlers.c, dlg_onreply() is called right before a
> response is forwarded, after it was forwarded, and when the associated
> transaction is terminated. (tm callbacks TMCB_RESPONSE_PRE_OUT,
> TMCB_RESPONSE_FWDED, and TMCB_TRANS_DELETED, respectively, in Kamailio
> 1.5. The 3.x branch seems to have renamed TMCB_RESPONSE_PRE_OUT to
> TMCB_RESPONSE_READY and TMCB_TRANS_DELETED to TMCB_DESTROY. Correct me
> if this wasn't just for the looks.

yes, those renaming happened.

To comment the rest I have to find the time to read whole thread, which 
got quite big for now :-)

Cheers,
Daniel

> ) So, taking into account that (serial
> and parallel) forking proxies will *forward* responses only when all
> forking attempts have finally failed or one succeeded, wouldn't that
> automatically implement your "dialog-outs will properly adjust
> dialog-in's state" approach and render dialog-outs unnecessary? Or am I
> wrong on the assumption how forking works?
>
>
> (2) How would your approach deal with unconfirmed requests traversing
> the same proxy multiple times, i.e., what has been denoted as
> "spiraling" in this thread, as in this example:
>
> UA1 -->  P1 -->  P2 -->  P1 -->  UA2
>
> Will that result in the creation of two dialog(-in)s?
>
>
> Cheers,
>
> --Timo
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>    

-- 
Daniel-Constantin Mierla
Kamailio SIP Router Masterclass, Berlin, March 22-26, 2010
* http://www.asipto.com/index.php/sip-router-masterclass/