Hi, using Kamailio 1.5.4.
I use dlg_manage() for an INVITE. 200 Ok is replied by the callee but the UAC doesn't send the ACK (due to a crash).
The dialog remains in Kamailio dialog memory/table in state 3 and would expire after default_timeout (which usually is 3600 seconds or more, unsuitable for this case).
Yes, it could occur that the proxy is not doing loose_routing, but in that case it doesn't make sense to use dialog module, so shouldn't dialog module expire dialogs in state 3 after ~32 seconds?
I'm using profiles_with_value to limit the number of calls per user, so this issue is a bit important, as a UAC not sending the ACK for a 200 means one less available channel for this user during dialog module default_timeout.
El Miércoles, 3 de Marzo de 2010, Iñaki Baz Castillo escribió:
Hi, using Kamailio 1.5.4.
I use dlg_manage() for an INVITE. 200 Ok is replied by the callee but the UAC doesn't send the ACK (due to a crash).
The dialog remains in Kamailio dialog memory/table in state 3 and would expire after default_timeout (which usually is 3600 seconds or more, unsuitable for this case).
Yes, it could occur that the proxy is not doing loose_routing, but in that case it doesn't make sense to use dialog module, so shouldn't dialog module expire dialogs in state 3 after ~32 seconds?
I'm using profiles_with_value to limit the number of calls per user, so this issue is a bit important, as a UAC not sending the ACK for a 200 means one less available channel for this user during dialog module default_timeout.
Another issue: when a call is cancelled the dialog remains in memory for ~4 seconds more.
This is: - INVITE received and any provisional response => dialog in state 2. - CANCEL received => dialog in state 5 for ~4 seconds.
Is there any reason for that? This means that get_profile_size() still computes the cancelled call during ~4 seconds.
Thanks for any comment.
Hello,
On 03/04/2010 04:17 PM, Iñaki Baz Castillo wrote:
El Miércoles, 3 de Marzo de 2010, Iñaki Baz Castillo escribió:
Hi, using Kamailio 1.5.4.
I use dlg_manage() for an INVITE. 200 Ok is replied by the callee but the UAC doesn't send the ACK (due to a crash).
The dialog remains in Kamailio dialog memory/table in state 3 and would expire after default_timeout (which usually is 3600 seconds or more, unsuitable for this case).
Yes, it could occur that the proxy is not doing loose_routing, but in that case it doesn't make sense to use dialog module, so shouldn't dialog module expire dialogs in state 3 after ~32 seconds?
I'm using profiles_with_value to limit the number of calls per user, so this issue is a bit important, as a UAC not sending the ACK for a 200 means one less available channel for this user during dialog module default_timeout.
Another issue: when a call is cancelled the dialog remains in memory for ~4 seconds more.
This is:
- INVITE received and any provisional response => dialog in state 2.
- CANCEL received => dialog in state 5 for ~4 seconds.
Is there any reason for that?
there might be a detele timer delay. I will read your emails and check the sources asap, having some busy days with some public events related to project.
Cheers, Daniel
This means that get_profile_size() still computes the cancelled call during ~4 seconds.
Thanks for any comment.
El Jueves, 4 de Marzo de 2010, Daniel-Constantin Mierla escribió:
Hello,
On 03/04/2010 04:17 PM, Iñaki Baz Castillo wrote:
El Miércoles, 3 de Marzo de 2010, Iñaki Baz Castillo escribió:
Hi, using Kamailio 1.5.4.
I use dlg_manage() for an INVITE. 200 Ok is replied by the callee but the UAC doesn't send the ACK (due to a crash).
The dialog remains in Kamailio dialog memory/table in state 3 and would expire after default_timeout (which usually is 3600 seconds or more, unsuitable for this case).
Yes, it could occur that the proxy is not doing loose_routing, but in that case it doesn't make sense to use dialog module, so shouldn't dialog module expire dialogs in state 3 after ~32 seconds?
I'm using profiles_with_value to limit the number of calls per user, so this issue is a bit important, as a UAC not sending the ACK for a 200 means one less available channel for this user during dialog module default_timeout.
Another issue: when a call is cancelled the dialog remains in memory for ~4 seconds more.
This is:
- INVITE received and any provisional response => dialog in state 2.
- CANCEL received => dialog in state 5 for ~4 seconds.
Is there any reason for that?
there might be a detele timer delay.
I've checked and the same occurs when the INVITE transaction is terminated with a final [3456]XX response. In any case it remains in memory in state 5 for ~4 seconds.
Hello Inaki,
On 03/04/2010 04:51 PM, Iñaki Baz Castillo wrote:
El Jueves, 4 de Marzo de 2010, Daniel-Constantin Mierla escribió:
Hello,
On 03/04/2010 04:17 PM, Iñaki Baz Castillo wrote:
El Miércoles, 3 de Marzo de 2010, Iñaki Baz Castillo escribió:
Hi, using Kamailio 1.5.4.
I use dlg_manage() for an INVITE. 200 Ok is replied by the callee but the UAC doesn't send the ACK (due to a crash).
The dialog remains in Kamailio dialog memory/table in state 3 and would expire after default_timeout (which usually is 3600 seconds or more, unsuitable for this case).
Yes, it could occur that the proxy is not doing loose_routing, but in that case it doesn't make sense to use dialog module, so shouldn't dialog module expire dialogs in state 3 after ~32 seconds?
I'm using profiles_with_value to limit the number of calls per user, so this issue is a bit important, as a UAC not sending the ACK for a 200 means one less available channel for this user during dialog module default_timeout.
Another issue: when a call is cancelled the dialog remains in memory for ~4 seconds more.
This is:
- INVITE received and any provisional response => dialog in state 2.
- CANCEL received => dialog in state 5 for ~4 seconds.
Is there any reason for that?
there might be a detele timer delay.
I've checked and the same occurs when the INVITE transaction is terminated with a final [3456]XX response. In any case it remains in memory in state 5 for ~4 seconds.
took me a bit to get back to this one.
From what you describe this seems to be related to transaction life in delete state. If the dialog is not answered, it is not inserted in dialogs list. It is kept attached to invite transaction.
I agree that state 3 should stay no longer than 32sec, normally this should be clear by caller sending BYE due to non-ACK. You said you are not doing record routing, how the bye gets then to the proxy so the dialog is cleared from memory?
Cheers, Daniel
2010/3/16 Daniel-Constantin Mierla miconda@gmail.com:
I agree that state 3 should stay no longer than 32sec, normally this should be clear by caller sending BYE due to non-ACK. You said you are not doing record routing, how the bye gets then to the proxy so the dialog is cleared from memory?
Humm no, I didn't mean it, I'm using record route (I just said that without record route dialog module makes no sense).
The issues are two:
1) INVITE, 200 but no ACK received. The dialog remains in state 3 for dialog module default_timeout value (long time usually). IMHO as no ACK is received the dialog should be deleted after 32 seconds (the time the TM module waits for the ACK).
2) When the INVITE transaction is terminated by a final [3456]XX response, the dialog remains in memory in state 5 for ~4 seconds. I've inspected the code and couldn't find a timer or whatever that could make the dialog information to be kept for such time.
Regards.
On 03/16/2010 01:36 PM, Iñaki Baz Castillo wrote:
2010/3/16 Daniel-Constantin Mierlamiconda@gmail.com:
I agree that state 3 should stay no longer than 32sec, normally this should be clear by caller sending BYE due to non-ACK. You said you are not doing record routing, how the bye gets then to the proxy so the dialog is cleared from memory?
Humm no, I didn't mean it, I'm using record route (I just said that without record route dialog module makes no sense).
sorry, I misunderstood.
The issues are two:
- INVITE, 200 but no ACK received.
The dialog remains in state 3 for dialog module default_timeout value (long time usually). IMHO as no ACK is received the dialog should be deleted after 32 seconds (the time the TM module waits for the ACK).
But isn't there a BYE coming from callee after 32sec? Callee should end the dialog in its side if no ACK is received.
- When the INVITE transaction is terminated by a final [3456]XX
response, the dialog remains in memory in state 5 for ~4 seconds. I've inspected the code and couldn't find a timer or whatever that could make the dialog information to be kept for such time.
Not in dialog module, but it is tm module. IIRC, the last reference to such dialog is destroyed when the transaction is deleted from memory. That should happen aprox 2sec after the transaction is completed and reply sent. To be sure it is this one, you can play with tm parameter delete_timer or so. I am going to dig in more as well.
Cheers, Daniel
- When the INVITE transaction is terminated by a final [3456]XX
response, the dialog remains in memory in state 5 for ~4 seconds. I've inspected the code and couldn't find a timer or whatever that could make the dialog information to be kept for such time.
Not in dialog module, but it is tm module. IIRC, the last reference to such dialog is destroyed when the transaction is deleted from memory. That should happen aprox 2sec after the transaction is completed and reply sent. To be sure it is this one, you can play with tm parameter delete_timer or so. I am going to dig in more as well.
This is correct. The transaction deletion triggers an unref in the dialog context and when the ref counter comes down to zero, the dialog is deleted.
Regards, Ovidiu Sas
2010/3/16 Daniel-Constantin Mierla miconda@gmail.com:
- INVITE, 200 but no ACK received.
The dialog remains in state 3 for dialog module default_timeout value (long time usually). IMHO as no ACK is received the dialog should be deleted after 32 seconds (the time the TM module waits for the ACK).
But isn't there a BYE coming from callee after 32sec? Callee should end the dialog in its side if no ACK is received.
That's right. Let me check because I think there was one more issue with this (perhaps in case the BYE got no reply or couldn't be sent via TCP...). Not sure now. Anyhow there are some devices (wrong devices) not sending BYE if ACK doesn't arrive after 32 seconds. They just release the RTP :(
- When the INVITE transaction is terminated by a final [3456]XX
response, the dialog remains in memory in state 5 for ~4 seconds. I've inspected the code and couldn't find a timer or whatever that could make the dialog information to be kept for such time.
Not in dialog module, but it is tm module. IIRC, the last reference to such dialog is destroyed when the transaction is deleted from memory. That should happen aprox 2sec after the transaction is completed and reply sent. To be sure it is this one, you can play with tm parameter delete_timer or so. I am going to dig in more as well.
ok, understood then. Thanks.
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Ovidiu Sas