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@1und1.dewrote:

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@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@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