Hey Timo
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.
Regards Phillip
On Wed, Sep 21, 2011 at 3:02 PM, Timo Reimann timo.reimann@1und1.de wrote:
Hey Phillip,
On 21.09.2011 13: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> 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 } toclose
> the if statement. > You can see that the route(WITHINDLG); is called for all requestsfrom
> 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 dialogtracking
doesn't work for you. I tried to reproduce your setup, including the dialog module parameters you are using. However, things keep workingfor
me the way they should. A few people have had issues when starting to track dialogs beforethe
INVITE was authenticated. In that case, the caller could receive a407
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 thecall
to dlg_manage() past the location where "route(AUTH)" is called andsee
if it helps? Cheers, --Timo