Hey Timo<br><br>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...<br>
<br>I'm pretty sure that all messages belonging to a specific dialog reach the same Kamailio instance.<br><br>Regards<br>Phillip<br><br><br><div class="gmail_quote">On Wed, Sep 21, 2011 at 3:02 PM, Timo Reimann <span dir="ltr"><<a href="mailto:timo.reimann@1und1.de">timo.reimann@1und1.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hey Phillip,<br>
<div class="im"><br>
<br>
On <a href="tel:21.09.2011%2013" value="+12109201113">21.09.2011 13</a>:53, Phillman25 Kyriacou wrote:<br>
> I tried what you told me below, however i'm still getting the same result.<br>
> Just to give you more details on my scenario i have 2 kamailio servers<br>
> running heartbeat for high availability on a virtual ip as well as mysql<br>
> MASTER-MASTER replication setup. All traffic is sent on this virtual ip.<br>
> You think that this might be the reason?<br>
<br>
</div>Not 100% sure but you need to guarantee that *all* messages belonging to<br>
a specific dialog reach the same Kamailio instance. (There is no notion<br>
of distributed dialog management; the database just helps with restoring<br>
dialogs on startup.) Is that the case for you?<br>
<br>
<br>
Cheers,<br>
<font color="#888888"><br>
--Timo<br>
</font><div class="im"><br>
<br>
<br>
> On Tue, Sep 20, 2011 at 8:07 PM, Timo Reimann <<a href="mailto:timo.reimann@1und1.de">timo.reimann@1und1.de</a><br>
</div><div><div></div><div class="h5">> <mailto:<a href="mailto:timo.reimann@1und1.de">timo.reimann@1und1.de</a>>> wrote:<br>
><br>
> Hey,<br>
><br>
><br>
> On 20.09.2011 15:23, Phillman25 Kyriacou wrote:<br>
> > Hey Timo<br>
> ><br>
> > Thanks for your email.<br>
> > I apologise i never copied the config properly. I missed a } to close<br>
> > the if statement.<br>
> > You can see that the route(WITHINDLG); is called for all requests from<br>
> > this config.<br>
> ><br>
> ><br>
> ><br>
> > # MANAGE ALL DIALOGS<br>
> > #===================================================<br>
> > if (is_method("INVITE"))<br>
> > {<br>
> > if(is_method("INVITE") && !has_totag())<br>
> > {<br>
> > $dlg_ctx(timeout_route) = 12;<br>
> > $dlg_ctx(timeout_bye) = 1;<br>
> > }<br>
> ><br>
> > dlg_manage();<br>
> ><br>
> > }<br>
> ><br>
> ><br>
> > if(is_method("BYE|CANCEL"))<br>
> ><br>
> > {<br>
> ><br>
> > dlg_manage();<br>
> ><br>
> ><br>
> > }<br>
><br>
> [...]<br>
><br>
> > # handle requests within SIP dialogs<br>
> > route(WITHINDLG);<br>
><br>
> [...]<br>
><br>
> > # authentication<br>
> > route(AUTH);<br>
><br>
> Ok, this looks better now. Still, I cannot explain why dialog tracking<br>
> doesn't work for you. I tried to reproduce your setup, including the<br>
> dialog module parameters you are using. However, things keep working for<br>
> me the way they should.<br>
><br>
> A few people have had issues when starting to track dialogs before the<br>
> INVITE was authenticated. In that case, the caller could receive a 407<br>
> which isn't properly handled by the dialog module in all cases. (There's<br>
> a bug report filed on the tracker already.) Could you try moving that<br>
> "if(is_method("INVITE") && !has_totag()) {...}" part including the call<br>
> to dlg_manage() past the location where "route(AUTH)" is called and see<br>
> if it helps?<br>
><br>
><br>
> Cheers,<br>
><br>
> --Timo<br>
</div></div></blockquote></div><br>