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.reim...@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.reim...@1und1.de > > <mailto:timo.reim...@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.reim...@1und1.de <mailto:timo.reim...@1und1.de> > > > <mailto:timo.reim...@1und1.de <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