Hi!
I have not followed the whole discussion. I just had an idea which might be useful: Why not hook up dialog module with tm module? Tm module already knows the state of forked INVITE transaction, which ones are in early states, and which branch is the winner.
regards klaus
Am 15.03.2010 14:00, schrieb Iñaki Baz Castillo:
2010/3/12 Timo Reimanntimo.reimann@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?