[SR-Users] Dialog module showing calls that have already been terminated
Timo Reimann
timo.reimann at 1und1.de
Wed Sep 21 20:48:01 CEST 2011
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 at 1und1.de
> <mailto:timo.reimann at 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 at 1und1.de <mailto:timo.reimann at 1und1.de>
> > <mailto:timo.reimann at 1und1.de <mailto:timo.reimann at 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 at 1und1.de <mailto:timo.reimann at 1und1.de>
> <mailto:timo.reimann at 1und1.de <mailto:timo.reimann at 1und1.de>>
> > > <mailto:timo.reimann at 1und1.de <mailto:timo.reimann at 1und1.de>
> <mailto:timo.reimann at 1und1.de <mailto:timo.reimann at 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
More information about the sr-users
mailing list