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