Hey Iñaki, Iñaki Baz Castillo wrote: I don't think that it leaks. Please have a look at the get_expired_dlgs(unsigned int time) function in dlg_timer.c: The loop condition to get all expired dialogs is while( tl!=end && tl->timeout <= time) { ^^^^^^^^^^^^^^^^^^^ [...] } The unit of "time" is ticks, so the while-loop picks those dialogs for cleanup whose timeout value is lower or equal the current number of ticks. Certainly, this is true for a timeout of zero. I think it makes sense this way because dlg_end_dlg isn't supposed to change the dialog state in case of failure (and checking mi_terminate_dlg(), I believe it doesn't), so a subsequent, UAC-initiated CANCEL shouldn't be any different from such a CANCEL not involving a call to dlg_end_dlg(). A leak in this case would have been detected already, hopefully. Nevertheless, I think the current dialog module should be hotfixed such that dlg_end_dlg doesn't end dialogs in the "early" state simply because it's not capable of doing so. The upcoming, refurbished dialog module should do better though. Cheers, --Timo

2010/7/9 Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;et>: I mean "in my case". -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

2010/7/9 Timo Reimann &lt;timo.reimann(a)1und1.de&gt;de>: :) Yes, the code you show seems to work but I suspect that something "bad" occurs in the step 2 of my experiment (trying to terminate an early-dialog with still no remote-target as there is no Contact in the 180). Perhaps after that the dialog information is changed somehow, or un-indexed from a list or whatever. But the fact is that after the dialog is terminated (CANCEL by teh UAC) it remains forever in state 5. Thanks a lot. BTW I'm using kamailio 1.5.4. -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

2010/7/12 Timo Reimann &lt;timo.reimann(a)1und1.de&gt;de>: Thanks a lot for your work. Opsss, and this is why it gives an error when there is no remote-target (no Contact in the UAS's responses yet). Definitely, 'dialog' module is the most weakest piece in Kamailio. Hopefully your work will change it :) Best regards. -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

Hey Iñaki, Iñaki Baz Castillo wrote: Yep, exactly. Done with forensic. This is why the leak happens for early dialogs: (1) dlg_end_dlg triggers generation of a BYE request for the caller which succeeds because the caller's Contact address was stored during processing of the initial INVITE. (2) The reference counter is increased by one and supposed to be decremented again during processing of the BYE response (in bye_reply_cb()) from the caller. (3) The BYE request is send to the caller. However, it replies with "481 Call Leg/Transaction Does Not Exist" because the request is missing the callee's To tag which is not stored in the dialog module prior to the call's transition to the confirmed state. (4) The caller's 481 response is dialog-handled in bye_reply_cb(). What this function basically does is on reception of a final response, run the proxy-initiated BYE request (not the response) through the state machine and decrease the reference counter *if the new dialog state is "terminated" after completion of the state machine*. However, because BYE requests in the early state do not trigger state transitions due to the fact that the dialog module cannot tell yet whether a single branch or the entire call was terminated the "early" state is maintained and, in consequence, the reference counter *not decremented*. (5) Generation of a BYE request for the callee is triggered. However, it fails because no callee Contact is available. The reference counter will not be touched either though. (6) When the UAC sends out a CANCEL request the call is torn down. However, the dialog structure will not be deleted because the reference counter can not drop lower than one. The bottom line of this is that the dialog module leaks because it cannot handle in-early-dialog BYE requests accordingly. The way to deal with this at the moment is to deny proxy-initiated dialog termination unless the call is in the "confirmed" state because that's the only state it may manage to succeed. I say *may* because if a flawed or crashed UA is not able to process such a BYE properly it will reply with a non-2xx response or not at all, respectively, by which the proxy should consider its termination attempt to have failed and, subsequently, not delete the dialog IMHO. Even worse, you could have a situation where only one of the call participants shuts down the session while the other doesn't, leading to a weird kind of one-sided dialog. In order to avoid this, I believe the proxy should have UA response codes affect the state machinery and not rely on its BYE requests only. However, the latter is something to be done in future dialog module. To prevent any kind of leakage in the current implementation, my proposed fix would be to (1) Deny proxy-initiated dialog termination unless the call is in the "confirmed" state and (2) always decrement the reference counter during BYE response handling. Let me know what you think of this. Cheers, --Timo

2010/7/12 Henning Westerholt &lt;henning.westerholt(a)1und1.de&gt;de>: I think so. AFAIU ("U" = understand X-D) he means that after the proxy generates the BYE it should inmediately decrease the reference counter without waiting for the response. Good question. Let me ask another question (the same in other words): When a BYE is received in Kamailio, is the dialog terminated when the BYE is processed? or when the BYE receives a 2XX? what about if the BYE receives a [3456]XX response (or no response at all)? -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

2010/7/12 Timo Reimann &lt;timo.reimann(a)1und1.de&gt;de>: I strongly believe (as RFC 3261 states) that a proxy SHOULD NOT generate in-dialog requests. In fact, 'dialog' module is a bit "hack" ;) IMHO when a proxy-generated BYE is sent (to both caller and callee) that should be enough to set the dialog in 'terminated' state. There is no reason to behave different than when handling a UA-initiated BYE. Ok, I also need a break to see the goal again and again XDDD -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

2010/7/13 Henning Westerholt &lt;henning.westerholt(a)1und1.de&gt;de>: It's better 1-0, 1-0, 1-0 than 4-1, 4-0, 0-1. Opsss, sorry... :) -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

2010/7/13 Henning Westerholt &lt;henning.westerholt(a)1und1.de&gt;de>: Humm, the question would be: how many times have you celebrated it? (I mean being adult to drink beer) :) -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

2010/7/13 Henning Westerholt &lt;henning.westerholt(a)1und1.de&gt;de>: Germany will have its time (again) in Brazil 2014, I'm sure of that. -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

2010/7/13 Timo Reimann &lt;timo.reimann(a)1und1.de&gt;de>: I'm sorry, but in 2012 all the spanish players winning the world cup are still "available". You must wait a bit more ;) SIP/2.0 503 Service Unavailable From: sip:germany To: sip:win-something Retry-After: 4 years

Hola, Henning Westerholt wrote: Agreed. Putting it on the agenda for the new improved implementation should suffice for the moment. I will soon note down in the wiki dialog proposal what we have discussed so far. Iñaki's law: "As an sr-dev thread grows longer, the probability of him teasing others with the fact that the Spanish national football team won the 2010 world cup approaches 1." :) ¡Viva diálogo! --Timo

Heya, Iñaki Baz Castillo wrote: Yes. I didn't consider the case where an in-dialog request created by one of the UAs could shadow a proxy-induced BYE but it's worth remembering. Agreeing with you, I will update the wiki page on this aspect tomorrow. Cheers, --Timo