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@1und1.de wrote:
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@1und1.de mailto:timo.reimann@1und1.de> wrote:
Hey Phillip, On 21.09.2011 13 <tel:21.09.2011%2013>:53, Phillman25 Kyriacouwrote:
> 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 belongingto
a specific dialog reach the same Kamailio instance. (There is nonotion
of distributed dialog management; the database just helps withrestoring
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