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(a)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(a)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