3 Mar
2010
3 Mar
'10
6:21 p.m.
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.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
4 Mar
4 Mar
5:17 p.m.
New subject: [Kamailio-Users] [dialog module] dialog is not terminated when no ACK is received
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.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
5:28 p.m.
New subject: [Kamailio-Users] [dialog module] dialog is not terminated when no ACK is received
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ó:
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
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.
--
Daniel-Constantin Mierla
Kamailio SIP Router Masterclass, Berlin, March 22-26, 2010
* http://www.asipto.com/index.php/sip-router-masterclass/
5:51 p.m.
New subject: [Kamailio-Users] [dialog module] dialog is not terminated when no ACK is received
El Jueves, 4 de Marzo de 2010, Daniel-Constantin Mierla escribió:
Hello,
On 03/04/2010 04:17 PM, Iñaki Baz Castillo wrote:
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.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
El Miércoles, 3 de Marzo de 2010, Iñaki Baz
Castillo escribió:
there might be a detele timer delay. 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?
16 Mar
16 Mar
2:16 p.m.
New subject: [Kamailio-Users] [dialog module] dialog is not terminated when no ACK is received
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ó:
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
--
Daniel-Constantin Mierla
Kamailio SIP Router Masterclass, Berlin, March 22-26, 2010
* http://www.asipto.com/index.php/sip-router-masterclass/
Hello,
On 03/04/2010 04:17 PM, Iñaki Baz Castillo wrote:
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.
El Miércoles, 3 de Marzo de 2010, Iñaki Baz
Castillo escribió:
there might be a detele timer delay.
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?
2:36 p.m.
New subject: [Kamailio-Users] [dialog module] dialog is not terminated when no ACK is received
2010/3/16 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
3:23 p.m.
New subject: [Kamailio-Users] [dialog module] dialog is not terminated when no ACK is received
On 03/16/2010 01:36 PM, Iñaki Baz Castillo wrote:
2010/3/16 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
sorry, I misunderstood.
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).
But isn't there a BYE coming from callee after 32sec? Callee should end
the dialog in its side if no ACK is received.
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.
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
--
Daniel-Constantin Mierla
Kamailio SIP Router Masterclass, Berlin, March 22-26, 2010
* http://www.asipto.com/index.php/sip-router-masterclass/
3:29 p.m.
New subject: [Kamailio-Users] [dialog module] dialog is not terminated when no ACK is received
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.
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.
3:44 p.m.
New subject: [Kamailio-Users] [dialog module] dialog is not terminated when no ACK is received
2010/3/16 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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 :(
ok, understood then. Thanks.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
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).
But isn't there a BYE coming from callee after 32sec? Callee should end the
dialog in its side if no ACK is received. 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.
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.
5368
days inactive
5381
days old
8 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Ovidiu Sas