[SR-Users] Kamailio dialog termination

Thu Apr 25 15:18:56 CEST 2013

Hello,

On 4/25/13 3:07 PM, Grant Bagdasarian wrote:
>
> Hello,
>
> I've set the default_timeout to 3600 seconds, which is 1 hour.
>
> In the database the dialog record shows:
>
> StartTime Timeout
>
> 1366886241 1366929441
>
> The difference is 12 hours. Shouldn't the timeout be StartTime + 
> default_timeout?
>
> Also the matching mode is set to 1, which is DID_FALLBACK.
>
> DID_FALLBACK: the match is first tried based on DID and if not 
> present, it will fall back to SIP matching. I'm assuming SIP matching 
> is done based on CallID and Tags?
>
> Why does the dialog module still reserve a 'port' even if the 
> profile_size is 0, but the dialog:active_dialogs is 1?
>
> Below a sample of my configuration script which handles the call limit.
>
> dlg_manage();
>
> record_route();
>
> $var(SIZE) = 0;
>
> sql_query("vf", "exec dbo.SelectCurrentTimeFrame '00$rU'", "ra");
>
> $avp(s:limit) = $dbr(ra=>[0,7]);
>
> xlog("L_INFO", "Maximum simultaneous calls is configured at 
> $avp(s:limit) ....");
>
> sql_result_free("ra");
>
> get_profile_size("limitedCallsProfile", "$rU", "$var(SIZE)");
>
> xlog("L_INFO", "There are currently $var(SIZE) calls for $rU, 
> excluding the current call");
>
> if($var(SIZE) >= $avp(s:limit)) {
>
> xlog("L_INFO", "Simultaneous calls limit of $avp(s:limit) reached for 
> $rU: $var(SIZE)\n");
>
> sl_send_reply("603", "Simultaneous calls limit reached");
>
> exit;
>
> }
>
> set_dlg_profile("limitedCallsProfile ", "$rU");
>
you should use dlg_mange() as last action before relaying the initial 
INVITE. Makes no sense to create a rather large structure in shared 
memory for a dialog that you may destroy immediately by sending 603. You 
can still do all the dialog profile related checks. In some cases it was 
reported that dialogs may not be destroyed when replying with stateless 
module. Not sure it is the case here.

There was no time to look deeper at the reported issue, in my 
deployments where I'm creating dialog before relay, I was not able to 
reproduce. However, the main reason is that dialog is planned to be 
refactored based on a past discussion, effort started by other 
developers with dialog_ng.

Also, be sure that you run the latest version in your deployed series, 
not to be the effect of an issue already fixed.

Cheers,
Daniel
>
> Thanks,
>
> Grant
>
> *From:*sr-users-bounces at lists.sip-router.org 
> [mailto:sr-users-bounces at lists.sip-router.org] *On Behalf Of *Carlos 
> Ruiz Díaz
> *Sent:* Thursday, April 25, 2013 2:30 PM
> *To:* Kamailio (SER) - Users Mailing List
> *Subject:* Re: [SR-Users] Kamailio dialog termination
>
> Hi,
>
> did you wait the default 12 hours (default_timeout) for the dialog to 
> be released? If after that time, the dialog is still there, it is 
> probably because of a bug.
>
> You should also take into account the matching mode currently 
> configured: 
> http://www.kamailio.org/docs/modules/3.3.x/modules_k/dialog.html#idp129680. 
> The default behavior is to add a dialog-id cookie in the route header 
> but if your user agent fails to add the parameter when it sends the 
> subsequent requests, the dialog will not be properly tracked and you 
> could end with a bunch of active "unfinished" dialogs in memory.
>
> Regards,
>
> On Thu, Apr 25, 2013 at 8:13 AM, Grant Bagdasarian <GB at cm.nl 
> <mailto:GB at cm.nl>> wrote:
>
> Hello,
>
> Another dialog got stuck in kamailio, so I checked a few kamctl 
> commands. This is what I found.
>
> When viewing the profile size the count is 0 (using kamctl fifo 
> profile_get_size [NAME])
>
> When using the kamctl fifo get_statistics all command, the 
> dialog:active_dialogs shows 1. There are no other calls active at this 
> point, so this must be the one that got stuck.
>
> The call is still in state 4. I don't know what this means, but I'm 
> guessing active.
>
> Why did the dialog module fail to release this dialog? The profile was 
> configured to allow 2 concurrent calls. We called the number using two 
> phones and only one made it through.
>
> Is this a bug?
>
> Regards,
>
> Grant
>
> *From:*sr-users-bounces at lists.sip-router.org 
> <mailto:sr-users-bounces at lists.sip-router.org> 
> [mailto:sr-users-bounces at lists.sip-router.org 
> <mailto:sr-users-bounces at lists.sip-router.org>] *On Behalf Of *Grant 
> Bagdasarian
> *Sent:* Monday, April 22, 2013 10:55 AM
> *To:* sr-users at lists.sip-router.org <mailto:sr-users at lists.sip-router.org>
> *Subject:* [SR-Users] Kamailio dialog termination
>
> Hello,
>
> Using the dialog module. According to the documentation a dialog is 
> automatically destroyed when a BYE is received. In case of no BYE, the 
> dialog lifetime is controlled via the default timeout.
>
> I'm assuming the dialog module only creates a dialog when a 200 OK is 
> received on the INVITE. So if a CANCEL request is sent for this INVITE 
> or the server answers with anything but a 200 OK, no dialog is created 
> and maintained by the dialog module?
>
> Also, when the dialog is terminated, is it guaranteed the dialog entry 
> is removed from memory at all times, but there might be a chance the 
> dialog remains stored in the database table because of some error? I'm 
> using the dialog module to control the number of calls allowed to a 
> certain destination, but it sometimes does occur that an entry in the 
> database is not removed, but I'm not sure if the dialog is also 
> removed from memory when this happens.
>
> I hope someone could clear this out for me.
>
> Thanks,
>
> Grant
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org <mailto:sr-users at lists.sip-router.org>
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> -- 
> Carlos
>
> http://caruizdiaz.com
>
> +595981146623
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130425/a8c1d6c5/attachment-0001.html>