4 Jun
2013
4 Jun
'13
4:39 p.m.
Hello,
On 6/4/13 3:14 PM, Eduardo Lejarreta wrote:
Good evening.
Playing with latest "dialog module" versions (3.2, 3.3 and 4.0) I
think there could be an open "issue" with regard to dialog state
management.
You can see on "dlg_handlers.c" on "dlg_onroute" function. On this
last when you receive a BYE message it fires some CallBacks.
I you receive a close second BYE, this last one destroys the dialog
because "dlg_release" function is called from a parallel process
avoiding the other processes callback execution.
I know a second BYE it's not a normal circumstance but you know, the
real world ...
I think dialog_ng doesn't have this issue but also it has no DB support.
can you give more specific details, like the lines of code you think may
have an open issue? A quick check, it seems dialog and dialog_ng have
the same processing of BYE request in dlg_onroute() and unref is done
only on transition state to terminate.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
* http://asipto.com/u/katu *
5 Jun
5 Jun
12:07 p.m.
New subject: Dialog onroute requests.
Good morning Daniel.
I cannot test this issue because I have no means, so I deduce what's
happening, and of course I could be mistaken.
1.- First BYE received, first listening process: dlg_onroute ->
..
/* run state machine */
switch ( req->first_line.u.request.method_value ) {
case METHOD_PRACK:
event = DLG_EVENT_REQPRACK; break;
case METHOD_ACK:
event = DLG_EVENT_REQACK; break;
case METHOD_BYE:
event = DLG_EVENT_REQBYE; break;
default:
event = DLG_EVENT_REQ;
}
next_state_dlg( dlg, event, &old_state, &new_state, &unref);
----------------------------------------------------------------------------
------------> new_state: DLG_STATE_DELETED ; old_state: DLG_STATE_CONFIRMED
2.- Second BYE received, second listening process: dlg_onroute ->
...
/* run state machine */
switch ( req->first_line.u.request.method_value ) {
case METHOD_PRACK:
event = DLG_EVENT_REQPRACK; break;
case METHOD_ACK:
event = DLG_EVENT_REQACK; break;
case METHOD_BYE:
event = DLG_EVENT_REQBYE; break;
default:
event = DLG_EVENT_REQ;
}
next_state_dlg( dlg, event, &old_state, &new_state, &unref);
----------------------------------------------------------------------------
------------> new_state: DLG_STATE_DELETED ; old_state: DLG_STATE_DELETED
...
done:
dlg_release(dlg); ---> before first process related callbacks are
executed by other processes like acc_cdr.c
return;
Thanks and best regards.
--
Eduardo Lejarreta.
De: sr-dev-bounces(a)lists.sip-router.org
[mailto:sr-dev-bounces@lists.sip-router.org] En nombre de Daniel-Constantin
Mierla
Enviado el: martes, 04 de junio de 2013 15:39
Para: Kamailio (SER) - Development Mailing List
Asunto: Re: [sr-dev] Dialog onroute requests.
Hello,
On 6/4/13 3:14 PM, Eduardo Lejarreta wrote:
Good evening.
Playing with latest "dialog module" versions (3.2, 3.3 and 4.0) I think
there could be an open "issue" with regard to dialog state management.
You can see on "dlg_handlers.c" on "dlg_onroute" function. On this
last
when you receive a BYE message it fires some CallBacks.
I you receive a close second BYE, this last one destroys the dialog because
"dlg_release" function is called from a parallel process avoiding the other
processes callback execution.
I know a second BYE it's not a normal circumstance but you know, the real
world .
I think dialog_ng doesn't have this issue but also it has no DB support.
can you give more specific details, like the lines of code you think may
have an open issue? A quick check, it seems dialog and dialog_ng have the
same processing of BYE request in dlg_onroute() and unref is done only on
transition state to terminate.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
* http://asipto.com/u/katu *
19 Jun
19 Jun
2:14 p.m.
New subject: Dialog onroute requests.
On 04.06.2013 15:39, Daniel-Constantin Mierla wrote:
Hello,
On 6/4/13 3:14 PM, Eduardo Lejarreta wrote:
We have since upgrading from Kamailio 1.5 to 3.2 had problems with the
dialog module, where dialogs have been "stuck" in state 5 and we must
restart Kamailio to remove them. Needless to say a bad thing...
So far we have mitigated it mostly with dropping duplicated INVITEs and
with the help of this mail, also dropping duplicated BYEs. Seems like
the duplicate-handling in the module is not handled well if they
are received within a too short interval.
We use:
modparam("htable", "htable",
"invcidhist=>size=8;autoexpire=30");
modparam("htable", "htable",
"byecidhist=>size=8;autoexpire=30");
and before route(WITHINDLG):
if (is_method("BYE")) {
lock($ci);
if($sht(byecidhist=>$ci) != $null) {
xlog("L_INFO", "BYE: We've already seen this
call-id before, we should drop this bye $ci\n");
unlock($ci);
exit;
} else {
xlog("L_INFO", "BYE: This is the first BYE for
this call, let's process it\n");
$sht(byecidhist=>$ci) = 1;
}
unlock($ci);
}
Later after route(AUTH) we do it similar for INVITE
if (is_method("INVITE")) {
if($sht(invcidhist=>$ci) != $null)
{
xlog("L_INFO", "INVITE: We've already seen
this
call-id before, we should drop this invite $ci\n");
unlock($ci);
exit;
} else
{
xlog("L_INFO", "INVITE: This is a new invite,
let's
start a dialog! $ci\n");
$sht(invcidhist=>$ci) = 1;
}
unlock($ci);
}
Our Kamailios are running 3.3.3 (i386/linux) 897939-dirty.
--
Øyvind
Good evening.
Playing with latest “dialog module” versions (3.2, 3.3 and 4.0) I
think there could be an open “issue” with regard to dialog state
management.
You can see on “dlg_handlers.c” on “dlg_onroute” function. On this
last when you receive a BYE message it fires some CallBacks.
I you receive a close second BYE, this last one destroys the dialog
because “dlg_release” function is called from a parallel process
avoiding the other processes callback execution.
I know a second BYE it’s not a normal circumstance but you know, the
real world …
I think dialog_ng doesn’t have this issue but also it has no DB support.
can you give more specific details, like the lines of code you think may
have an open issue? A quick check, it seems dialog and dialog_ng have
the same processing of BYE request in dlg_onroute() and unref is done
only on transition state to terminate.
6:35 p.m.
New subject: Dialog onroute requests.
Good evening Øyvind.
Nice workaround. We'll implement until dialog modules are improved.
Need help to kamctl ("hot") restart? Depending on which modules you develop
I could give you some ideas.
Thank you very much and best regards.
--
Eduardo Lejarreta.
-----Mensaje original-----
De: sr-dev-bounces(a)lists.sip-router.org
[mailto:sr-dev-bounces@lists.sip-router.org] En nombre de Øyvind Kolbu
Enviado el: miércoles, 19 de junio de 2013 13:15
Para: sr-dev(a)lists.sip-router.org
Asunto: Re: [sr-dev] Dialog onroute requests.
On 04.06.2013 15:39, Daniel-Constantin Mierla wrote:
Hello,
On 6/4/13 3:14 PM, Eduardo Lejarreta wrote:
We have since upgrading from Kamailio 1.5 to 3.2 had problems with the
dialog module, where dialogs have been "stuck" in state 5 and we must
restart Kamailio to remove them. Needless to say a bad thing...
So far we have mitigated it mostly with dropping duplicated INVITEs and with
the help of this mail, also dropping duplicated BYEs. Seems like the
duplicate-handling in the module is not handled well if they are received
within a too short interval.
We use:
modparam("htable", "htable",
"invcidhist=>size=8;autoexpire=30");
modparam("htable", "htable",
"byecidhist=>size=8;autoexpire=30");
and before route(WITHINDLG):
if (is_method("BYE")) {
lock($ci);
if($sht(byecidhist=>$ci) != $null) {
xlog("L_INFO", "BYE: We've already seen this
call-id before, we should drop this bye $ci\n");
unlock($ci);
exit;
} else {
xlog("L_INFO", "BYE: This is the first BYE for
this
call, let's process it\n");
$sht(byecidhist=>$ci) = 1;
}
unlock($ci);
}
Later after route(AUTH) we do it similar for INVITE
if (is_method("INVITE")) {
if($sht(invcidhist=>$ci) != $null)
{
xlog("L_INFO", "INVITE: We've already seen
this
call-id before, we should drop this invite $ci\n");
unlock($ci);
exit;
} else
{
xlog("L_INFO", "INVITE: This is a new invite,
let's
start a dialog! $ci\n");
$sht(invcidhist=>$ci) = 1;
}
unlock($ci);
}
Our Kamailios are running 3.3.3 (i386/linux) 897939-dirty.
--
Øyvind
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Good evening.
Playing with latest dialog module versions (3.2, 3.3 and 4.0) I
think there could be an open issue with regard to dialog state
management.
You can see on dlg_handlers.c on dlg_onroute function. On this
last when you receive a BYE message it fires some CallBacks.
I you receive a close second BYE, this last one destroys the dialog
because dlg_release function is called from a parallel process
avoiding the other processes callback execution.
I know a second BYE its not a normal circumstance but you know, the
real world
I think dialog_ng doesnt have this issue but also it has no DB support.
can you give more specific details, like the lines of code you think
may have an open issue? A quick check, it seems dialog and dialog_ng
have the same processing of BYE request in dlg_onroute() and unref is
done only on transition state to terminate.
4176
days inactive
4191
days old
3 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Eduardo Lejarreta -
Øyvind Kolbu