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(a)1und1.de>wrote;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(a)1und1.de
<mailto:timo.reimann@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(a)1und1.de <mailto:timo.reimann@1und1.de>
> <mailto:timo.reimann@1und1.de <mailto:timo.reimann@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