2010/3/12 Timo Reimann <[email protected]>: > 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 <[email protected]> -- Iñaki Baz Castillo <[email protected]> _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
