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