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
Hey,
Sounds fine to me then.
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.
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
> 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 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@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