20 Sep
2011
20 Sep
'11
8:06 a.m.
Hey Phillip,
On 20.09.2011 13:48, Phillman25 Kyriacou wrote:
Thanks for your email.
Yes dlg_manage(); has to now be called on INVITE and BYE/CANCEL messages.
Where would i have to call loose_route()? Only on INVITE?
On *all* in-dialog requests, i.e., all requests which contain a To tag.
This may include Re-INVITEs too (but not initial INVITEs).
My configuration did not change between 3.1.2 and
3.1.5.
Call flow example:
==============
Cisco PGW ===> Kamailio 3.1.5 ===> VOIP PROVIDER or ASTERISK PABX
The below is my configuration.
Let's take a look at it:
#!KAMAILIO
#
[...]
if(is_method("BYE|CANCEL"))
{
dlg_manage();
# per request initial checks
route(REQINIT);
# NAT detection
route(NAT);
# handle requests within SIP dialogs
route(WITHINDLG);
[...]
# Handle requests within SIP dialogs
route[WITHINDLG] {
if (has_totag()) {
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
[...]
So route[WITHINDLG] contains the logic to track in-dialog requests.
However, you seem to call that route only from BYE and CANCEL requests,
missing out ACKs, which is likely the reason why things go wrong. So
make sure you run all in-dialog requests through that route, and you
should be fine (hopefully).
Cheers,
--Timo
20 Sep
20 Sep
9:23 a.m.
New subject: Dialog module showing calls that have already been terminated
Hey Timo
Thanks for your email.
I apologise i never copied the config properly. I missed a } to close the
if statement.
You can see that the route(WITHINDLG); is called for all requests from this
config.
# MANAGE ALL DIALOGS
#===================================================
if (is_method("INVITE"))
{
if(is_method("INVITE") && !has_totag())
{
$dlg_ctx(timeout_route) = 12;
$dlg_ctx(timeout_bye) = 1;
}
dlg_manage();
}
if(is_method("BYE|CANCEL"))
{
dlg_manage();
}
# per request initial checks
route(REQINIT);
# NAT detection
route(NAT);
# handle requests within SIP dialogs
route(WITHINDLG);
### only initial requests (no To tag)
# CANCEL processing
if (is_method("CANCEL"))
{
if (t_check_trans())
t_relay();
exit;
}
t_check_trans();
# authentication
route(AUTH);
# record routing for dialog forming requests (in case they are
routed)
# - remove preloaded route headers
remove_hf("Route");
if (is_method("INVITE|SUBSCRIBE"))
record_route();
Thanks again for your help.
Phillip
On Tue, Sep 20, 2011 at 3:06 PM, Timo Reimann <timo.reimann(a)1und1.de> wrote:
Hey Phillip,
On 20.09.2011 13:48, Phillman25 Kyriacou wrote:
Thanks for your email.
Yes dlg_manage(); has to now be called on INVITE and BYE/CANCEL messages.
Where would i have to call loose_route()? Only on INVITE?
On *all* in-dialog requests, i.e., all requests which contain a To tag.
This may include Re-INVITEs too (but not initial INVITEs).
My configuration did not change between 3.1.2 and
3.1.5.
Call flow example:
==============
Cisco PGW ===> Kamailio 3.1.5 ===> VOIP PROVIDER or ASTERISK PABX
The below is my configuration.
Let's take a look at it:
#!KAMAILIO
#
[...]
if(is_method("BYE|CANCEL"))
{
dlg_manage();
# per request initial checks
route(REQINIT);
# NAT detection
route(NAT);
# handle requests within SIP dialogs
route(WITHINDLG);
[...]
# Handle requests within SIP dialogs
route[WITHINDLG] {
if (has_totag()) {
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
[...]
So route[WITHINDLG] contains the logic to track in-dialog requests.
However, you seem to call that route only from BYE and CANCEL requests,
missing out ACKs, which is likely the reason why things go wrong. So
make sure you run all in-dialog requests through that route, and you
should be fine (hopefully).
Cheers,
--Timo
1:07 p.m.
New subject: Dialog module showing calls that have already been terminated
Hey,
On 20.09.2011 15:23, Phillman25 Kyriacou wrote:
Hey Timo
Thanks for your email.
I apologise i never copied the config properly. I missed a } to close
the if statement.
You can see that the route(WITHINDLG); is called for all requests from
this config.
# MANAGE ALL DIALOGS
#===================================================
if (is_method("INVITE"))
{
if(is_method("INVITE") && !has_totag())
{
$dlg_ctx(timeout_route) = 12;
$dlg_ctx(timeout_bye) = 1;
}
dlg_manage();
}
if(is_method("BYE|CANCEL"))
{
dlg_manage();
}
[...]
# handle requests within SIP dialogs
route(WITHINDLG);
[...]
# authentication
route(AUTH);
Ok, this looks better now. Still, I cannot explain why dialog tracking
doesn't work for you. I tried to reproduce your setup, including the
dialog module parameters you are using. However, things keep working for
me the way they should.
A few people have had issues when starting to track dialogs before the
INVITE was authenticated. In that case, the caller could receive a 407
which isn't properly handled by the dialog module in all cases. (There's
a bug report filed on the tracker already.) Could you try moving that
"if(is_method("INVITE") && !has_totag()) {...}" part including
the call
to dlg_manage() past the location where "route(AUTH)" is called and see
if it helps?
Cheers,
--Timo
21 Sep
21 Sep
7:53 a.m.
New subject: Dialog module showing calls that have already been terminated
Hi Timo
I tried what you told me below, however i'm still getting the same result.
Just to give you more details on my scenario i have 2 kamailio servers
running heartbeat for high availability on a virtual ip as well as mysql
MASTER-MASTER replication setup. All traffic is sent on this virtual ip.
You think that this might be the reason?
Regards
Phillip
On Tue, Sep 20, 2011 at 8:07 PM, Timo Reimann <timo.reimann(a)1und1.de> wrote:
Hey,
On 20.09.2011 15:23, Phillman25 Kyriacou wrote:
Hey Timo
Thanks for your email.
I apologise i never copied the config properly. I missed a } to close
the if statement.
You can see that the route(WITHINDLG); is called for all requests from
this config.
# MANAGE ALL DIALOGS
#===================================================
if (is_method("INVITE"))
{
if(is_method("INVITE") && !has_totag())
{
$dlg_ctx(timeout_route) = 12;
$dlg_ctx(timeout_bye) = 1;
}
dlg_manage();
}
if(is_method("BYE|CANCEL"))
{
dlg_manage();
}
[...]
# handle requests within SIP dialogs
route(WITHINDLG);
[...]
# authentication
route(AUTH);
Ok, this looks better now. Still, I cannot explain why dialog tracking
doesn't work for you. I tried to reproduce your setup, including the
dialog module parameters you are using. However, things keep working for
me the way they should.
A few people have had issues when starting to track dialogs before the
INVITE was authenticated. In that case, the caller could receive a 407
which isn't properly handled by the dialog module in all cases. (There's
a bug report filed on the tracker already.) Could you try moving that
"if(is_method("INVITE") && !has_totag()) {...}" part
including the call
to dlg_manage() past the location where "route(AUTH)" is called and see
if it helps?
Cheers,
--Timo
8:02 a.m.
New subject: Dialog module showing calls that have already been terminated
Hey Phillip,
On 21.09.2011 13:53, Phillman25 Kyriacou wrote:
I tried what you told me below, however i'm still
getting the same result.
Just to give you more details on my scenario i have 2 kamailio servers
running heartbeat for high availability on a virtual ip as well as mysql
MASTER-MASTER replication setup. All traffic is sent on this virtual ip.
You think that this might be the reason?
Not 100% sure but you need to guarantee that *all* messages belonging to
a specific dialog reach the same Kamailio instance. (There is no notion
of distributed dialog management; the database just helps with restoring
dialogs on startup.) Is that the case for you?
Cheers,
--Timo
On Tue, Sep 20, 2011 at 8:07 PM, Timo Reimann
<timo.reimann(a)1und1.de
<mailto:timo.reimann@1und1.de>> wrote:
Hey,
On 20.09.2011 15:23, Phillman25 Kyriacou wrote:
Hey Timo
Thanks for your email.
I apologise i never copied the config properly. I missed a } to close
the if statement.
You can see that the route(WITHINDLG); is called for all requests from
this config.
# MANAGE ALL DIALOGS
#===================================================
if (is_method("INVITE"))
{
if(is_method("INVITE") && !has_totag())
{
$dlg_ctx(timeout_route) = 12;
$dlg_ctx(timeout_bye) = 1;
}
dlg_manage();
}
if(is_method("BYE|CANCEL"))
{
dlg_manage();
}
[...]
# handle requests within SIP dialogs
route(WITHINDLG);
[...]
# authentication
route(AUTH);
Ok, this looks better now. Still, I cannot explain why dialog tracking
doesn't work for you. I tried to reproduce your setup, including the
dialog module parameters you are using. However, things keep working for
me the way they should.
A few people have had issues when starting to track dialogs before the
INVITE was authenticated. In that case, the caller could receive a 407
which isn't properly handled by the dialog module in all cases. (There's
a bug report filed on the tracker already.) Could you try moving that
"if(is_method("INVITE") && !has_totag()) {...}" part
including the call
to dlg_manage() past the location where "route(AUTH)" is called and see
if it helps?
Cheers,
--Timo
8:16 a.m.
New subject: Dialog module showing calls that have already been terminated
Hey Timo
Yes the mysql replication is basically used to update the standby server of
new mysql entries in case of a switchover the secondary server will be
updated in terms of dialog restoration, dialplan update, CDR's etc...
I'm pretty sure that all messages belonging to a specific dialog reach the
same Kamailio instance.
Regards
Phillip
On Wed, Sep 21, 2011 at 3:02 PM, Timo Reimann <timo.reimann(a)1und1.de> wrote:
Hey Phillip,
On 21.09.2011 13:53, Phillman25 Kyriacou wrote:
tracking
I tried what you told me below, however i'm
still getting the same
result.
Just to give you more details on my scenario i
have 2 kamailio servers
running heartbeat for high availability on a virtual ip as well as mysql
MASTER-MASTER replication setup. All traffic is sent on this virtual ip.
You think that this might be the reason?
Not 100% sure but you need to guarantee that *all* messages belonging to
a specific dialog reach the same Kamailio instance. (There is no notion
of distributed dialog management; the database just helps with restoring
dialogs on startup.) Is that the case for you?
Cheers,
--Timo
On Tue, Sep 20, 2011 at 8:07 PM, Timo Reimann
<timo.reimann(a)1und1.de
<mailto:timo.reimann@1und1.de>> wrote:
Hey,
On 20.09.2011 15:23, Phillman25 Kyriacou wrote:
> Hey Timo
>
> Thanks for your email.
> I apologise i never copied the config properly. I missed a } to
close
> the if statement.
> You can see that the route(WITHINDLG); is called for all requests
from
this
config.
# MANAGE ALL DIALOGS
#===================================================
if (is_method("INVITE"))
{
if(is_method("INVITE") && !has_totag())
{
$dlg_ctx(timeout_route) = 12;
$dlg_ctx(timeout_bye) = 1;
}
dlg_manage();
}
if(is_method("BYE|CANCEL"))
{
dlg_manage();
}
[...]
# handle requests within SIP dialogs
route(WITHINDLG);
[...]
# authentication
route(AUTH);
Ok, this looks better now. Still, I cannot explain why dialog doesn't work for you. I tried to
reproduce your setup, including the
dialog module parameters you are using. However, things keep working
for
me the way they should.
A few people have had issues when starting to track dialogs before
the
INVITE was authenticated. In that case, the
caller could receive a
407
which isn't properly handled by the
dialog module in all cases.
(There's
a bug report filed on the tracker already.)
Could you try moving that
"if(is_method("INVITE") && !has_totag()) {...}" part
including the
call
to dlg_manage() past the location where
"route(AUTH)" is called and
see
if it helps?
Cheers,
--Timo
8:41 a.m.
New subject: Dialog module showing calls that have already been terminated
Hey,
On 21.09.2011 14:16, Phillman25 Kyriacou wrote:
Yes the mysql replication is basically used to update
the standby server
of new mysql entries in case of a switchover the secondary server will
be updated in terms of dialog restoration, dialplan update, CDR's etc...
I'm pretty sure that all messages belonging to a specific dialog reach
the same Kamailio instance.
Sounds fine to me then.
There's not much I can think of now apart from trying to get more data
on the issue. Are you able to reproduce the problem such that you could
create a trace of a call affected by the problem and provide me with
that? Even better, could you increase log verbosity to "debug" level
while you do the trace?
Cheers,
--Timo
On Wed, Sep 21, 2011 at 3:02 PM, Timo Reimann
<timo.reimann(a)1und1.de
<mailto:timo.reimann@1und1.de>> wrote:
Hey Phillip,
On 21.09.2011 13 <tel:21.09.2011%2013>:53, Phillman25 Kyriacou wrote:
tracking
I tried what you told me below, however i'm
still getting the same
result.
Just to give you more details on my scenario i
have 2 kamailio
servers
running heartbeat for high availability on a
virtual ip as well as
mysql
MASTER-MASTER replication setup. All traffic is
sent on this
virtual ip.
You think that this might be the reason?
Not 100% sure but you need to guarantee that *all* messages belonging to
a specific dialog reach the same Kamailio instance. (There is no notion
of distributed dialog management; the database just helps with restoring
dialogs on startup.) Is that the case for you?
Cheers,
--Timo
On Tue, Sep 20, 2011 at 8:07 PM, Timo Reimann
<timo.reimann(a)1und1.de <mailto:timo.reimann@1und1.de>
<mailto:timo.reimann@1und1.de
<mailto:timo.reimann@1und1.de>>> wrote:
Hey,
On 20.09.2011 15:23, Phillman25 Kyriacou wrote:
> Hey Timo
>
> Thanks for your email.
> I apologise i never copied the config properly. I missed a
} to
close
> the if statement.
> You can see that the route(WITHINDLG); is called for all
requests
from
this
config.
# MANAGE ALL DIALOGS
#===================================================
if (is_method("INVITE"))
{
if(is_method("INVITE") && !has_totag())
{
$dlg_ctx(timeout_route) = 12;
$dlg_ctx(timeout_bye) = 1;
}
dlg_manage();
}
if(is_method("BYE|CANCEL"))
{
dlg_manage();
}
[...]
# handle requests within SIP dialogs
route(WITHINDLG);
[...]
# authentication
route(AUTH);
Ok, this looks better now. Still, I cannot explain why dialog doesn't work for you. I tried to
reproduce your setup,
including the
dialog module parameters you are using.
However, things keep
working for
me the way they should.
A few people have had issues when starting to track dialogs
before the
INVITE was authenticated. In that case, the
caller could
receive a 407
which isn't properly handled by the
dialog module in all
cases. (There's
a bug report filed on the tracker already.)
Could you try
moving that
"if(is_method("INVITE")
&& !has_totag()) {...}" part including
the call
to dlg_manage() past the location where
"route(AUTH)" is
called and see
> if it helps?
>
>
> Cheers,
>
> --Timo
8:58 a.m.
New subject: Dialog module showing calls that have already been terminated
Hey Timo
How can i increase log verbosity to "debug" level? Do i change the below
debug values?
####### Global Parameters #########
#!ifdef WITH_DEBUG
debug=2
log_stderror=yes
#!else
debug=2
log_stderror=no
#!endif
memdbg=5
memlog=5
Can i use the module sip trace to produce a trace or would you rather prefer
i use "ngrep -d any -P '*' -W byline -T port 5060" ?
Thanks
Phillip
On Wed, Sep 21, 2011 at 3:41 PM, Timo Reimann <timo.reimann(a)1und1.de> wrote:
Hey,
On 21.09.2011 14:16, Phillman25 Kyriacou wrote:
to
tracking
Yes the mysql replication is basically used to
update the standby server
of new mysql entries in case of a switchover the secondary server will
be updated in terms of dialog restoration, dialplan update, CDR's etc...
I'm pretty sure that all messages belonging to a specific dialog reach
the same Kamailio instance.
Sounds fine to me then.
There's not much I can think of now apart from trying to get more data
on the issue. Are you able to reproduce the problem such that you could
create a trace of a call affected by the problem and provide me with
that? Even better, could you increase log verbosity to "debug" level
while you do the trace?
Cheers,
--Timo
On Wed, Sep 21, 2011 at 3:02 PM, Timo Reimann
<timo.reimann(a)1und1.de
<mailto:timo.reimann@1und1.de>> wrote:
Hey Phillip,
On 21.09.2011 13 <tel:21.09.2011%2013>:53, Phillman25 Kyriacou
wrote:
I tried
what you told me below, however i'm still getting the same
result.
Just to give you more details on my scenario i
have 2 kamailio
servers
running heartbeat for high availability on a
virtual ip as well as
mysql
MASTER-MASTER replication setup. All traffic is
sent on this
virtual ip.
You think that this might be the reason?
Not 100% sure but you need to guarantee that *all* messages belonging a specific dialog reach the same Kamailio
instance. (There is no
notion
of distributed dialog management; the
database just helps with
restoring
dialogs on startup.) Is that the case for
you?
Cheers,
--Timo
wrote:
On Tue, Sep 20, 2011 at 8:07 PM, Timo Reimann
<timo.reimann(a)1und1.de <mailto:timo.reimann@1und1.de>
> <mailto:timo.reimann@1und1.de <mailto:timo.reimann@1und1.de>>>
Hey,
On 20.09.2011 15:23, Phillman25 Kyriacou wrote:
> Hey Timo
>
> Thanks for your email.
> I apologise i never copied the config properly. I missed a
} to
close
> the if statement.
> You can see that the route(WITHINDLG); is called for all
requests
from
this
config.
# MANAGE ALL DIALOGS
#===================================================
if (is_method("INVITE"))
{
if(is_method("INVITE") && !has_totag())
{
$dlg_ctx(timeout_route) = 12;
$dlg_ctx(timeout_bye) = 1;
}
dlg_manage();
}
if(is_method("BYE|CANCEL"))
{
dlg_manage();
}
[...]
# handle requests within SIP dialogs
route(WITHINDLG);
[...]
# authentication
route(AUTH);
Ok, this looks better now. Still, I cannot explain why dialog doesn't work for you. I tried to
reproduce your setup,
including the
dialog module parameters you are using.
However, things keep
working for
me the way they should.
A few people have had issues when starting to track dialogs
before the
INVITE was authenticated. In that case, the
caller could
receive a 407
which isn't properly handled by the
dialog module in all
cases. (There's
a bug report filed on the tracker already.)
Could you try
moving that
"if(is_method("INVITE")
&& !has_totag()) {...}" part including
the call
to dlg_manage() past the location where
"route(AUTH)" is
called and see
> if it helps?
>
>
> Cheers,
>
> --Timo
2:48 p.m.
New subject: Dialog module showing calls that have already been terminated
Hey,
On 21.09.2011 14:58, Phillman25 Kyriacou wrote:
How can i increase log verbosity to "debug"
level? Do i change the below
debug values?
You just need to change the "debug" parameter. It's gotta be "3"
in SIP
Router to get DBG-level verbosity (the most noisy level).
You can also change the debug level on-the-fly using sercmd; this is
quite useful as you do not need to restart the server. Please see the
official documentation here:
http://sip-router.org/wiki/cookbooks/core-cookbook/devel?s[]=debug#debug
As the documentation says, a very verbose and busy Kamailio can easily
flood your logs. If that's a potential issue to you, keep verbose times
as short as possible, i.e., change the debug level [on-the-fly] only for
the duration of trace generation and revert back to a safer setting
right afterwards.
Can i use the module sip trace to produce a trace or
would you rather
prefer i use "ngrep -d any -P '*' -W byline -T port 5060" ?
ngrep would be perfect!
Thanks a lot and
cheers,
--Timo
On Wed, Sep 21, 2011 at 3:41 PM, Timo Reimann
<timo.reimann(a)1und1.de
<mailto:timo.reimann@1und1.de>> wrote:
Hey,
On 21.09.2011 14 <tel:21.09.2011%2014>:16, Phillman25 Kyriacou wrote:
#===================================================
Yes the mysql replication is basically used to
update the standby
server
of new mysql entries in case of a switchover the
secondary server will
be updated in terms of dialog restoration, dialplan update, CDR's
etc...
I'm pretty sure that all messages belonging to a specific dialog reach
the same Kamailio instance.
Sounds fine to me then.
There's not much I can think of now apart from trying to get more data
on the issue. Are you able to reproduce the problem such that you could
create a trace of a call affected by the problem and provide me with
that? Even better, could you increase log verbosity to "debug" level
while you do the trace?
Cheers,
--Timo
On Wed, Sep 21, 2011 at 3:02 PM, Timo Reimann
<timo.reimann(a)1und1.de <mailto:timo.reimann@1und1.de>
<mailto:timo.reimann@1und1.de
<mailto:timo.reimann@1und1.de>>> wrote:
Hey Phillip,
On 21.09.2011 13 <tel:21.09.2011%2013>
<tel:21.09.2011%2013>:53, Phillman25 Kyriacou wrote:
> I tried what you told me below, however
i'm still getting
the same
result.
well as
Just to give you more details on my scenario i
have 2 kamailio
servers
> running heartbeat for high availability on a virtual ip as mysql
belonging to
MASTER-MASTER replication setup. All traffic is
sent on this
virtual ip.
You think that this might be the reason?
Not 100% sure but you need to guarantee that *all* messages a specific dialog reach the same Kamailio
instance. (There is
no notion
of distributed dialog management; the
database just helps with
restoring
dialogs on startup.) Is that the case for
you?
Cheers,
--Timo
<mailto:timo.reimann@1und1.de <mailto:timo.reimann@1und1.de>>
On Tue, Sep 20, 2011 at 8:07 PM, Timo Reimann
<timo.reimann(a)1und1.de <mailto:timo.reimann@1und1.de> > <mailto:timo.reimann@1und1.de
<mailto:timo.reimann@1und1.de>
<mailto:timo.reimann@1und1.de
<mailto:timo.reimann@1und1.de>>>> wrote:
Hey,
On 20.09.2011 15:23, Phillman25 Kyriacou wrote:
> Hey Timo
>
> Thanks for your email.
> I apologise i never copied the config properly. I missed a
} to
close
> the if statement.
> You can see that the route(WITHINDLG); is called for all
requests
from
> > this config.
> >
> >
> >
> > # MANAGE ALL DIALOGS
> > > > if
(is_method("INVITE"))
> > {
> > if(is_method("INVITE") && !has_totag())
> > {
> > $dlg_ctx(timeout_route) = 12;
> > $dlg_ctx(timeout_bye) = 1;
> > }
> >
> > dlg_manage();
> >
> > }
> >
> >
> > if(is_method("BYE|CANCEL"))
> >
> > {
> >
> > dlg_manage();
> >
> >
> > }
>
> [...]
>
> > # handle requests within SIP dialogs
> > route(WITHINDLG);
>
> [...]
>
> > # authentication
> > route(AUTH);
>
> Ok, this looks better now. Still, I cannot explain why
dialog
tracking
including
> the call
> > to dlg_manage() past the location where "route(AUTH)" is
> called and see
> > if it helps?
> >
> >
> > Cheers,
> >
> > --Timo doesn't work for you. I tried to
reproduce your setup,
including the
dialog module parameters you are using.
However, things keep
working for
me the way they should.
A few people have had issues when starting to track dialogs
before the
INVITE was authenticated. In that case, the
caller could
receive a 407
which isn't properly handled by the
dialog module in all
cases. (There's
a bug report filed on the tracker already.)
Could you try
moving that
> "if(is_method("INVITE") && !has_totag()) {...}"
part
4630
days inactive
4631
days old
8 comments
2 participants
participants (2)
-
Phillman25 Kyriacou -
Timo Reimann