Hey Phillip,
On 20.09.2011 13:48, Phillman25 Kyriacou wrote:
Thanks for your email.
Yes dlg_manage(); has to now be called on INVITE and BYE/CANCEL messages. Where would i have to call loose_route()? Only on INVITE?
On *all* in-dialog requests, i.e., all requests which contain a To tag. This may include Re-INVITEs too (but not initial INVITEs).
My configuration did not change between 3.1.2 and 3.1.5.
Call flow example:
Cisco PGW ===> Kamailio 3.1.5 ===> VOIP PROVIDER or ASTERISK PABX
The below is my configuration.
Let's take a look at it:
#!KAMAILIO #
[...]
if(is_method("BYE|CANCEL")) { dlg_manage(); # per request initial checks route(REQINIT); # NAT detection route(NAT); # handle requests within SIP dialogs route(WITHINDLG);
[...]
# Handle requests within SIP dialogs route[WITHINDLG] { if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) {
[...]
So route[WITHINDLG] contains the logic to track in-dialog requests. However, you seem to call that route only from BYE and CANCEL requests, missing out ACKs, which is likely the reason why things go wrong. So make sure you run all in-dialog requests through that route, and you should be fine (hopefully).
Cheers,
--Timo
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();
}
# per request initial checks route(REQINIT);
# NAT detection route(NAT);
# handle requests within SIP dialogs route(WITHINDLG);
### only initial requests (no To tag)
# CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) t_relay(); exit; }
t_check_trans();
# authentication route(AUTH);
# record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) record_route();
Thanks again for your help.
Phillip
On Tue, Sep 20, 2011 at 3:06 PM, Timo Reimann timo.reimann@1und1.de wrote:
Hey Phillip,
On 20.09.2011 13:48, Phillman25 Kyriacou wrote:
Thanks for your email.
Yes dlg_manage(); has to now be called on INVITE and BYE/CANCEL messages. Where would i have to call loose_route()? Only on INVITE?
On *all* in-dialog requests, i.e., all requests which contain a To tag. This may include Re-INVITEs too (but not initial INVITEs).
My configuration did not change between 3.1.2 and 3.1.5.
Call flow example:
Cisco PGW ===> Kamailio 3.1.5 ===> VOIP PROVIDER or ASTERISK PABX
The below is my configuration.
Let's take a look at it:
#!KAMAILIO #
[...]
if(is_method("BYE|CANCEL")) { dlg_manage(); # per request initial checks route(REQINIT); # NAT detection route(NAT); # handle requests within SIP dialogs route(WITHINDLG);[...]
# Handle requests within SIP dialogs route[WITHINDLG] { if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) {
[...]
So route[WITHINDLG] contains the logic to track in-dialog requests. However, you seem to call that route only from BYE and CANCEL requests, missing out ACKs, which is likely the reason why things go wrong. So make sure you run all in-dialog requests through that route, and you should be fine (hopefully).
Cheers,
--Timo
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
Hi Timo
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?
Regards Phillip
On Tue, Sep 20, 2011 at 8:07 PM, Timo Reimann 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
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 } 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
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
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 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
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
Hey,
On 21.09.2011 14:58, Phillman25 Kyriacou wrote:
How can i increase log verbosity to "debug" level? Do i change the below debug values?
You just need to change the "debug" parameter. It's gotta be "3" in SIP Router to get DBG-level verbosity (the most noisy level).
You can also change the debug level on-the-fly using sercmd; this is quite useful as you do not need to restart the server. Please see the official documentation here:
http://sip-router.org/wiki/cookbooks/core-cookbook/devel?s%5B%5D=debug#debug
As the documentation says, a very verbose and busy Kamailio can easily flood your logs. If that's a potential issue to you, keep verbose times as short as possible, i.e., change the debug level [on-the-fly] only for the duration of trace generation and revert back to a safer setting right afterwards.
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" ?
ngrep would be perfect!
Thanks a lot and
cheers,
--Timo
On Wed, Sep 21, 2011 at 3:41 PM, Timo Reimann <timo.reimann@1und1.de mailto:timo.reimann@1und1.de> wrote:
Hey, On 21.09.2011 14 <tel:21.09.2011%2014>: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> > <mailto:timo.reimann@1und1.de <mailto:timo.reimann@1und1.de>>> wrote: > > Hey Phillip, > > > On 21.09.2011 13 <tel:21.09.2011%2013> <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>> > > <mailto: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
-
Phillman25 Kyriacou -
Timo Reimann