[sr-dev] dialog module: callbacks with FAKED_REPLY response message

[Timo Reimann]

Hi all,

I got a question regarding dialog module handling of tm callbacks where
the SIP response message is set to FAKED_REPLY. Specifically, dialog's
dlg_onreply() takes the response message given in the tmcb_params
structure and passes it onwards to all dialog callbacks. One major
problem with this in case of a FAKED_REPLY (e.g., 408) is that dialog
callback users cannot access PVs anymore which, to my knowledge,
requires access to a transaction's message, either request- or
response-wise. Moreover, dialog users will have to check for FAKED_REPLY
to prevent seg-faulting, a tm detail that should be hidden on the dialog
level IMHO.

I (and Marius) have been thinking about ways to resolve this. Here's a
list of what we have come up with:

(1) Instead of passing FAKED_REPLY, pass the response that would be sent
to the caller (e.g., 408). I took a look at the tm module to see if this
is even remotely possible, but frankly, that module is voodoo to me.
Hopefully, someone else can provide some feedback.

(2) Similar to tm callbacks, store both request and response messages in
dialog's analog of tmcb_params (called dlg_cb_params). The dialog
callback user then gets to pick the message to be appropriate for his
use case.

(3) In cases where the response is FAKED_REPLY, pass the request to
dialog callbacks instead.


The last solution is probably the least favorable as it changes the
semantics of the callback: Where you expected a (possibly FAKED_REPLY)
response to be given when the callback is executed, it may now be a
request in certain situations. (2) is easy to implement but still
requires the callback user to be aware of the existence of FAKED_REPLY.
(1) makes most sense to me but I wonder if there were good reasons why
it wasn't done like this in the first place.

Ideas?


Cheers,

--Timo