Hints on Kamailio BLF settings

[Daniel-Constantin Mierla]

Hello,

some people reported here issues with NOTIFY requests generated by Kamailio that include a large amount of dialog-info documents. Coming from couple of sources, I got some sample config files that I could test and see what happens.

Not sure it applies to Kazoo - afaik, the publishing of the dialog info data is done from kazoo module - but in any case, the details might be useful overall.

The cause for this situation seems to be a very long expires value used in PUBLISH requests. Look to database in presentity table and check the expires column value, if the value is too far in the future, then dialog-info documents are accumulated. The value ind database is unix timestamp -- the current one for your server can be seen with 'date +%s'.

With the standard modules presence_dialoginfo() + pua_dialoginfo() + dialog the issue is triggered by some default values for several parameters. The module presence_dialoginfo sets the Expires in PUBLISH using the lifetime value of dialog module. That is by default 12 hours. Practically that results in all dialog-info documents being stored for 12 hours in presentity table. The pua_dialoginfo module has the parameter force_single_dialog set to 0 by default, which means all the documents that are not expired are going to be added in the NOTIFY requests. Within 12 hours there can be a lot of calls, specially in enterprise environment.

This can be solved by setting the override_lifetime parameter for presence_dialoginfo to a low value, like 120 (this is seconds). See:

  - http://kamailio.org/docs/modules/4.2.x/modules/pua_dialoginfo.html#idp2576952

Also, you could consider setting the parameter:

  - http://kamailio.org/docs/modules/4.2.x/modules/presence_dialoginfo.html#idp2550936

I didn't have time to analyze properly the kazoo module, so far I could see that it writes directly to presentity table, it is not generating a PUBLISH request. Not sure how the NOTIFY is triggered out of it, perhaps via config/other function.

Hope these details are useful for some people here.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com

[Darren Schreiber]

Thanks a lot, Daniel! We’ll look into tweaking this so that it doesn’t happen. I assume that can be done in the script as you describe.

--
You received this message because you are subscribed to the Google Groups "2600hz-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 2600hz-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel-Constantin Mierla]

Hi Darren,

again, I am not sure it applies to Kazoo, but I wanted to point in this direction. Whenever someone reports such issue, she/he should first check the expires value from presentity table and tune that via module parameters if possible. The presence module appears to delete expired records just fine.

Cheers,
Daniel

[Darren Schreiber]

Yup, we have a script that grabs the dump info as well to analyze, so now we know what to look for. :-) Thanks for that.

[Luis Azedo]

Hi Daniel,

thank for your post.

we are not having blf issues anymore with the addition of 

3.2. force_dummy_dialog (int)

we are using the presentity_table directly because the updates are issued from kazoo thru amq without the knowledge of previous results but with a common key, which allow kazoo to set the proper expires by dialog-id.

to update a dialog (ringing -> answered -> hangup) with pua modules we would need the key returned in the first pua publish and we don't want to maintain state of these keys.

we had problems with kamailio not respecting send_fast_notify on resubscribes and we are taking back the notify for re-subscribe.

also, with addition on the above parameter, kazoo will stop send notify on first subscribe since we have done this to make bria, astra and others work.

Best