Re: [SR-Users] Dialog module showing calls that have already been terminated

2011-09-21 Thread Timo Reimann
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[]=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  > 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
> mailto:timo.reim...@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
> > mailto:timo.reim...@1und1.de>
> >
> > > 
>  > >
> > > 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
> >

Re: [SR-Users] Dialog module showing calls that have already been terminated

2011-09-21 Thread Phillman25 Kyriacou
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  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  > > 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
> > mailto:timo.reim...@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
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.

Re: [SR-Users] Dialog module showing calls that have already been terminated

2011-09-21 Thread Timo Reimann
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  > 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
> mailto:timo.reim...@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

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Dialog module showing calls that have already been terminated

2011-09-21 Thread Phillman25 Kyriacou
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  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  > > 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
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Dialog module showing calls that have already been terminated

2011-09-21 Thread Timo Reimann
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  > 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

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Dialog module showing calls that have already been terminated

2011-09-21 Thread Phillman25 Kyriacou
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  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
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Dialog module showing calls that have already been terminated

2011-09-20 Thread Timo Reimann
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

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Dialog module showing calls that have already been terminated

2011-09-20 Thread Phillman25 Kyriacou
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  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
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Dialog module showing calls that have already been terminated

2011-09-20 Thread Timo Reimann
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

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Dialog module showing calls that have already been terminated

2011-09-20 Thread Phillman25 Kyriacou
Hey Timo

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?
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.



   # 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();




Please let me know if you need anything else.

Thanks
Phillip


On Mon, Sep 19, 2011 at 11:47 AM, Timo Reimann wrote:

> Hey Phillip,
>
> you probably forgot to keep the mailing list in CC, I'll do that for you.
>
>
> On 19.09.2011 08:43, Phillman25 Kyriacou wrote:
> > You are right.
> >
> > I added the function dlg_manage(); when there is a BYE or CANCEL and now
> > its working perfectly. Before i had this function defined only on
> > INVITES. The strange thing is that it was working normally before when
> > dlg_manage(); was defined only for INVITE messages in the route block.
>
> So you are saying that before, you called dlg_manage() on INVITEs only
> but now, you need that function on both INVITE and BYE/CANCEL messages?
>
> That'd still qualify as a bug as the trigger to tracking the dialog
> (i.e., dlg_manage()) is required only once. After that, the dialog
> module makes sure that all dialog-related messages are properly
> processed. The only thing that's necessary for sequential requests to be
> tracked correctly is a call to loose_route() on such messages.
>
> If you are sure that your Kamailio configuration didn't change between
> 3.1.2 and 3.1.5 w.r.t. dialog tracking or anything that could affect it,
> I'd be willing to take a closer look at this issue (giving you can
> provide me with more information on your scenario, like call flow
> examples or similar).
>
>
> Cheers,
>
> --Timo
>
>
>
> > The calls that were suppose to be terminated before where in state 3 to
> > answer your question. However, i still see calls in state 3 now but they
> > are valid.
> >
> > Regards
> > Phillip
> >
> > On Fri, Sep 16, 2011 at 8:01 PM, Timo Reimann  > > wrote:
> >
> > Hey Phillip,
> >
> > after looking closer at what has been reported to me initially, your
> > case may be different after all.
> >
> > Could you possibly use "kamctl fifo dlg_list" to check what state the
> > majority of dialogs that should be terminated in your opinion are in?
> > Being given the reference counter should be useful in debugging this
> as
> > well.
> >
> >
> > Thanks,
> >
> > --Timo
> >
> >
> >
> > On 16.09.2011 14:22, Phillman25 Kyriacou wrote:
> > > On Fri, Sep 16, 2011 at 3:09 PM, Timo Reimann
> > mailto:timo.reim...@1und1.de>
> > > >>
> wrote:
> > >
> > > Hey Phillip,
> > >
> > >
> > > On 16.09.2011 13:35, Phillman25 Kyriacou wrote:
> > > > Hello
> > > >
> > > > I have been facing an issue where the dialog module is
> showing
> > > calls as
> > > > being active when in fact the call has already been
> > completed long ago
> > > > and this is giving wrong number of concurrent calls on our
> > SNMP work
> > > > station (CACTI) when polling the data from Kamailio. I
> > realized this
> > > > only started occurring after i upgraded from 3.1.2 to 3.1.5,
> has
> > > anyone
> > > > experienced the same issue?
> > >
> > > I was *just* being notified of issues concerning dialogs not
> being
> > > deleted. Working on this right now to report back soon.
> > >
> > > Thanks for the note!
> > >
> > >
> > > Cheers,
> > >
> > > --Timo
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Dialog module showing calls that have already been terminated

2011-09-19 Thread Timo Reimann
Hey Phillip,

you probably forgot to keep the mailing list in CC, I'll do that for you.


On 19.09.2011 08:43, Phillman25 Kyriacou wrote:
> You are right.
> 
> I added the function dlg_manage(); when there is a BYE or CANCEL and now
> its working perfectly. Before i had this function defined only on
> INVITES. The strange thing is that it was working normally before when
> dlg_manage(); was defined only for INVITE messages in the route block.

So you are saying that before, you called dlg_manage() on INVITEs only
but now, you need that function on both INVITE and BYE/CANCEL messages?

That'd still qualify as a bug as the trigger to tracking the dialog
(i.e., dlg_manage()) is required only once. After that, the dialog
module makes sure that all dialog-related messages are properly
processed. The only thing that's necessary for sequential requests to be
tracked correctly is a call to loose_route() on such messages.

If you are sure that your Kamailio configuration didn't change between
3.1.2 and 3.1.5 w.r.t. dialog tracking or anything that could affect it,
I'd be willing to take a closer look at this issue (giving you can
provide me with more information on your scenario, like call flow
examples or similar).


Cheers,

--Timo



> The calls that were suppose to be terminated before where in state 3 to
> answer your question. However, i still see calls in state 3 now but they
> are valid.
> 
> Regards
> Phillip
> 
> On Fri, Sep 16, 2011 at 8:01 PM, Timo Reimann  > wrote:
> 
> Hey Phillip,
> 
> after looking closer at what has been reported to me initially, your
> case may be different after all.
> 
> Could you possibly use "kamctl fifo dlg_list" to check what state the
> majority of dialogs that should be terminated in your opinion are in?
> Being given the reference counter should be useful in debugging this as
> well.
> 
> 
> Thanks,
> 
> --Timo
> 
> 
> 
> On 16.09.2011 14:22, Phillman25 Kyriacou wrote:
> > On Fri, Sep 16, 2011 at 3:09 PM, Timo Reimann
> mailto:timo.reim...@1und1.de>
> > >> wrote:
> >
> > Hey Phillip,
> >
> >
> > On 16.09.2011 13:35, Phillman25 Kyriacou wrote:
> > > Hello
> > >
> > > I have been facing an issue where the dialog module is showing
> > calls as
> > > being active when in fact the call has already been
> completed long ago
> > > and this is giving wrong number of concurrent calls on our
> SNMP work
> > > station (CACTI) when polling the data from Kamailio. I
> realized this
> > > only started occurring after i upgraded from 3.1.2 to 3.1.5, has
> > anyone
> > > experienced the same issue?
> >
> > I was *just* being notified of issues concerning dialogs not being
> > deleted. Working on this right now to report back soon.
> >
> > Thanks for the note!
> >
> >
> > Cheers,
> >
> > --Timo

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Dialog module showing calls that have already been terminated

2011-09-16 Thread Timo Reimann
Hey Phillip,

after looking closer at what has been reported to me initially, your
case may be different after all.

Could you possibly use "kamctl fifo dlg_list" to check what state the
majority of dialogs that should be terminated in your opinion are in?
Being given the reference counter should be useful in debugging this as
well.


Thanks,

--Timo



On 16.09.2011 14:22, Phillman25 Kyriacou wrote:
> On Fri, Sep 16, 2011 at 3:09 PM, Timo Reimann  > wrote:
> 
> Hey Phillip,
> 
> 
> On 16.09.2011 13:35, Phillman25 Kyriacou wrote:
> > Hello
> >
> > I have been facing an issue where the dialog module is showing
> calls as
> > being active when in fact the call has already been completed long ago
> > and this is giving wrong number of concurrent calls on our SNMP work
> > station (CACTI) when polling the data from Kamailio. I realized this
> > only started occurring after i upgraded from 3.1.2 to 3.1.5, has
> anyone
> > experienced the same issue?
> 
> I was *just* being notified of issues concerning dialogs not being
> deleted. Working on this right now to report back soon.
> 
> Thanks for the note!
> 
> 
> Cheers,
> 
> --Timo

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Dialog module showing calls that have already been terminated

2011-09-16 Thread Phillman25 Kyriacou
Hi Timo

Thanks for the update!

Regards
Phillip

On Fri, Sep 16, 2011 at 3:09 PM, Timo Reimann  wrote:

> Hey Phillip,
>
>
> On 16.09.2011 13:35, Phillman25 Kyriacou wrote:
> > Hello
> >
> > I have been facing an issue where the dialog module is showing calls as
> > being active when in fact the call has already been completed long ago
> > and this is giving wrong number of concurrent calls on our SNMP work
> > station (CACTI) when polling the data from Kamailio. I realized this
> > only started occurring after i upgraded from 3.1.2 to 3.1.5, has anyone
> > experienced the same issue?
>
> I was *just* being notified of issues concerning dialogs not being
> deleted. Working on this right now to report back soon.
>
> Thanks for the note!
>
>
> Cheers,
>
> --Timo
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Dialog module showing calls that have already been terminated

2011-09-16 Thread Timo Reimann
Hey Phillip,


On 16.09.2011 13:35, Phillman25 Kyriacou wrote:
> Hello
> 
> I have been facing an issue where the dialog module is showing calls as
> being active when in fact the call has already been completed long ago
> and this is giving wrong number of concurrent calls on our SNMP work
> station (CACTI) when polling the data from Kamailio. I realized this
> only started occurring after i upgraded from 3.1.2 to 3.1.5, has anyone
> experienced the same issue?

I was *just* being notified of issues concerning dialogs not being
deleted. Working on this right now to report back soon.

Thanks for the note!


Cheers,

--Timo

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


[SR-Users] Dialog module showing calls that have already been terminated

2011-09-16 Thread Phillman25 Kyriacou
Hello

I have been facing an issue where the dialog module is showing calls as
being active when in fact the call has already been completed long ago and
this is giving wrong number of concurrent calls on our SNMP work station
(CACTI) when polling the data from Kamailio. I realized this only started
occurring after i upgraded from 3.1.2 to 3.1.5, has anyone experienced the
same issue?

my config:



loadmodule "dialog.so"
.
.
.
.
# - DIALOG MODULE
PARAMETERS--#
modparam("dialog", "enable_stats", 1)
modparam("dialog", "hash_size", 4096)
modparam("dialog", "rr_param", "did")
modparam("dialog", "dlg_flag", 4)
modparam("dialog", "timeout_avp", "$avp(i:10)")
modparam("dialog", "dlg_extra_hdrs", "NULL")
modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "detect_spirals", 1)
modparam("dialog", "db_url", "mysql://openser:openserrw@localhost/openser")
modparam("dialog", "db_mode", 1)
modparam("dialog", "db_update_period", 60)
modparam("dialog", "db_fetch_rows", 500)
modparam("dialog", "table_name", "dialog")
modparam("dialog", "from_uri_column", "from_uri")
modparam("dialog", "from_tag_column", "from_tag")
modparam("dialog", "to_uri_column", "to_uri")
modparam("dialog", "to_tag_column", "to_tag")
modparam("dialog", "h_id_column", "hash_id")
modparam("dialog", "h_entry_column", "hash_entry")
modparam("dialog", "state_column", "state")
modparam("dialog", "start_time_column", "start_time")
modparam("dialog", "timeout_column", "timeout")
modparam("dialog", "sflags_column", "sflags")
modparam("dialog", "bridge_controller", "sip:control...@kamailio.org")
modparam("dialog", "default_timeout", 7200)

.
.
.
.

route {

   # 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();

}



Thanks
Phillip
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users