15 Mar
2010
15 Mar
'10
7:05 p.m.
2010/3/12 Timo Reimann <timo.reimann(a)1und1.de>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(a)aliax.net>
--
Iñaki Baz Castillo
<ibc(a)aliax.net>