[sr-dev] improving the dialog module

[Timo Reimann]

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