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:
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" ?
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.
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>>
> <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
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