[SR-Users] Dialog module showing calls that have already been terminated
Phillman25 Kyriacou
phillman25 at gmail.com
Tue Sep 20 13:57:07 CEST 2011
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 <timo.reimann at 1und1.de>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 <timo.reimann at 1und1.de
> > <mailto:timo.reimann at 1und1.de>> 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
> > <timo.reimann at 1und1.de <mailto:timo.reimann at 1und1.de>
> > > <mailto:timo.reimann at 1und1.de <mailto:timo.reimann at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20110920/e838031e/attachment.htm>
More information about the sr-users
mailing list