[sr-dev] improving the dialog module

[Iñaki Baz Castillo]

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

To simplify it: the dialog-in entry gets "terminated" status just in
case the incoming INVITE transaction gets a final negative response
(this covers parallel and serial forking).

So, from the point of view of the client (how many calls it has and
their status) just the "dialog-in" table must be inspected.
In order to get working callbacks when the dialog status changes, just
the unique dialog-in entry must be used (this exists forever until the
(early-)dialog(s) fully terminate).

Also with this approach there is no need to create a new dialog entry
when forking, but just when receiving a response with a new To tag (it
could occur due to local forking or due to remote forking generated by
a proxy behind us, it doesn't matter).


I think that with this approach all the cases are covered. Opinions?


--
Iñaki Baz Castillo
<ibc at aliax.net>



-- 
Iñaki Baz Castillo
<ibc at aliax.net>