4 Mar
2011
4 Mar
'11
5:42 p.m.
Hi,
with respect to this thread on SR-Users
http://lists.sip-router.org/pipermail/sr-users/2011-March/067696.html
asking why set_dlg_profile() doesn't work in failure_route, I figured
out that the problem is related to dlg_manage() usage. Conceptually,
tracking dialogs on-demand via that function and using the dialog flag
should work equally well. However, the dialog creation process differs
regarding the parameters passed to dlg_new_dialog() (located in
dlg_handlers.c and called by both approaches) whose signature is
int dlg_new_dialog(struct sip_msg *msg, struct cell *t)
When using dlg_manage(), a NULL pointer is passed instead of an existing
transaction cell. The pointer is subsequently passed to two tm module
callback registrations where one for the callback type TMCB_MAX is meant
as a "temporary workaround of missing dialog_ctx field" as noted by
Daniel in commit f6a66b42. However, that very registration call is bound
to a check that the transaction exists, i.e., parameter t is not NULL:
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob;f=modules_…
Consequently, no callback of type TMCB_MAX will be carried out for
dialogs generated from dlg_manage(). This poses to be a problem for a
bunch of dialog profiling-related exported functions as well as
is_known_dlg() since they rely on the get_current_dialog() function. For
non-REQUEST routes, that function accesses the current dialog by means
of iterating through all of the current transaction's callbacks looking
for one of type TMCB_MAX that was previously registered in
dlg_create_dialog(). However, as that registration never occurs in case
of dlg_manage()-based tracking for reasons lined out above, the set of
mentioned, exported functions cannot work. Refer to
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob;f=modules_…
to see how get_current_dialog() does it.
So how do we fix this?
My idea is to simply remove the not-NULL-check against the transaction t
prior to callback registration. If the transaction doesn't exists, the
tm module makes sure that it will be created lazily. This is how the
first callback registration for types TMCB_RESPONSE_READY and
TMCB_RESPONSE_FWDED in dlg_create_dialog() already works, apparently
with no issues. I also did a quick, simple test with the check left out
that proved to work fine.
As this looks like a fix to a work-around, however, I'd like to ask for
some feedback first.
Thanks and
cheers,
--Timo