THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has been changed. The changes are listed below. For full information about what has changed, visit the URL and click the History tab. FS#154 - tracked initial requests ended prematurely by stateless responses are not cleaned up User who did this: Timo Reimann (tr) Task details edited: ------- If the initial request to a dialog tracked using dlg_manage() is not delivered further downstream but ended by a stateless response from the proxy the associated dialog will not be cleaned up properly. Example flow: Caller ---> INVITE ---> Proxy Caller <--- 4xx(s-less) --- Proxy The reason for this behavior is that the dialog module expects a transaction to conclude when a call is being tracked. By returning the failure response statelessly, no transaction will be created and thus, the dialog structure never removed. Possible fixes to the problem: (1) On return of a stateless response, let the sl module call a function in the dialog module to clean up such dialogs. This is an ugly approach because it touches two modules and increases inter-module dependency; on the other side, it is expected to work. (2) Within the dialog module, register a to-be-implemented function on completed execution of the configuration script which is to detect and cleanup all "unconfirmed" dialogs that were ended prematurely by means of stateless responding. While this is a more elegant approach than (1), a method needs to be determined which is capable of detecting the problematic state. Introducing a new dialog state (e.g., DLG_STATE_UNCONFIRMED_SENT) could be one way to do this. Workarounds: (1) Refrain from tracking dialogs using dlg_manage() until you are sure no stateless response will be emitted. (2) Return responses statefully, i.e., call t_newtran() followed by t_reply(). (3) Track dialogs using the dialog flag instead of dlg_manage(). Although I haven't verified this solution, it should work. ------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=154 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.