On 26/01/16 12:54, Phil Lavin wrote: > > Sorry, correction – desired expires is always 1 second LESS than expires. >
Is this above happening when taking it from the dialog module value? Cheers, Daniel > > > > > > Phil > > > > *From:*Phil Lavin > *Sent:* 26 January 2016 11:54 > *To:* 'mico...@gmail.com' <mico...@gmail.com>; Kamailio (SER) - Users > Mailing List <sr-users@lists.sip-router.org> > *Cc:* Telco Team <telco-t...@synety.com> > *Subject:* RE: [SR-Users] Strange PUA Behaviour > > > > Hi Daniel, > > > > Not setting the lifetime does indeed take the expiry from the dialog > but the mechanism that refreshes the expiry when the call is ongoing > does not run unless max_expires time is less than the lifetime. This > seems to be because of the below code in pua.c: > > > > if((p->desired_expires> p->expires + min_expires) || > > (p->desired_expires== 0 )) > > > > The desired_expires value is always 1 second greater than the expires > value unless you set max_expires to pull it down. This has the side > effect that the presentity entries are cleaned up prematurely, however. > > > > Setting lifetime to a high value negates the need for the refreshes to > happen. > > > > > > Cheers > > > > Phil > > > > *From:*Daniel-Constantin Mierla [mailto:mico...@gmail.com] > *Sent:* 26 January 2016 11:36 > *To:* Phil Lavin <phil.la...@synety.com > <mailto:phil.la...@synety.com>>; Kamailio (SER) - Users Mailing List > <sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org>> > *Cc:* Telco Team <telco-t...@synety.com <mailto:telco-t...@synety.com>> > *Subject:* Re: [SR-Users] Strange PUA Behaviour > > > > Hello, > > thanks to tackling this further ... see my comments inline... > > On 26/01/16 11:46, Phil Lavin wrote: > > We now have something of a resolution to this. Config is below. > The key differences are: > > > > · pua – db_mode set to 0. This stops multiple states for a > single dialog (early, trying, confirmed and terminated) from > showing in the presentity table. I suspect this is a bug? > > > OK -- still in my todo to pursue this case. > > · pua_dialoginfo – override_lifetime set to a value > 4 > hours. 4 hours chosen because our platform terminates calls after > 4 hours to stop incomplete calls from continuing forever. There > does seem to be a mechanism to refresh the expiry time of > presentity records but it is only called when the max_expires time > is less than the override_lifetime. Doing that causes records to > be prematurely cleaned up. I suspect a few different bugs here? > > > IIRC, if you don't set: > > modparam("pua_dialoginfo", "override_lifetime", 14420) > > The value is taken from max dialog duration. Can you try without this > parameter? The parameter should be used only if you want to overwrite > the dialog module value. > > Cheers, > Daniel > > > > # ----- presence params ----- > > modparam("presence", "db_url", DBURL) > > modparam("presence", "send_fast_notify", 0) > > modparam("presence", "db_update_period", 20) > > modparam("presence", "clean_period", 60) > > modparam("presence", "max_expires", 14430) > > # ----- presence_xml params ----- > > modparam("presence_xml", "db_url", DBURL) > > modparam("presence_xml", "force_active", 1) > > # ----- presence_dialoginfo ----- > > modparam("presence_dialoginfo", "force_single_dialog", 0) > > modparam("presence_dialoginfo", "force_dummy_dialog", 1) > > # ----- pua params ----- > > modparam("pua", "db_url", DBURL) > > modparam("pua", "db_mode", 0) > > modparam("pua", "update_period", 20) > > modparam("pua", "dlginfo_increase_version", 0) > > modparam("pua", "reginfo_increase_version", 0) > > # ----- pua_dialoginfo params ----- > > modparam("pua_dialoginfo", "send_publish_flag", FLT_DLGINFO) > > modparam("pua_dialoginfo", "override_lifetime", 14420) > > modparam("pua_dialoginfo", "include_callid", 1) > > modparam("pua_dialoginfo", "caller_confirmed", 0) > > modparam("pua_dialoginfo", "include_tags", 1) > > > > > > Phil > > > > *From:*Phil Lavin > *Sent:* 22 January 2016 13:19 > *To:* mico...@gmail.com <mailto:mico...@gmail.com>; Kamailio (SER) > - Users Mailing List <sr-users@lists.sip-router.org> > <mailto:sr-users@lists.sip-router.org> > *Cc:* Telco Team <telco-t...@synety.com> > <mailto:telco-t...@synety.com> > *Subject:* RE: [SR-Users] Strange PUA Behaviour > > > > Hi Daniel, > > > > Any thoughts on this? > > > > > > Thanks > > > > Phil Lavin > > Telecoms Systems Manager > > *CloudCall by SYNETY* > www.cloudcall.com <http://www.cloudcall.com/> > > * > *T: +44 (0) 330 335 0000 / +1 617 982 1600 > > D: +44 (0) 116 424 4790 / +1 617 982 4790 > > SM: LinkedIn <https://uk.linkedin.com/pub/phil-lavin/25/422/750> > > *READ OUR BLOG FOR SMARTER COMMUNICATIONS* > > <http://t.sidekickopen03.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XX43M2cMvVRrZGW2zq9tRVd0tpR56dKNHf2gJW-W02?t=http%3a%2f%2fwww.synety.com%2fblog&si=4668581662425088&pi=98b5dc7b-6a3f-4319-9221-c422f106ebf9> > > > > *Confidentiality: This e-mail transmission, including any > attachments, is intended only for the named recipient(s) and may > contain information that is privileged, confidential and/or exempt > from disclosure under applicable law. If you have received this > transmission in error, or are not the named recipient(s), please > notify the sender immediately by return e-mail and permanently > delete this transmission, including any attachments. > Security: This e-mail and any attachments are believed to be free > from any virus but it is the responsibility of the recipient to > ensure this is so. E-mail is not a 100% secure communication*. > > > > *From:*Phil Lavin > *Sent:* 20 January 2016 19:52 > *To:* mico...@gmail.com <mailto:mico...@gmail.com>; Kamailio (SER) > - Users Mailing List <sr-users@lists.sip-router.org > <mailto:sr-users@lists.sip-router.org>> > *Cc:* Telco Team <telco-t...@synety.com > <mailto:telco-t...@synety.com>> > *Subject:* RE: [SR-Users] Strange PUA Behaviour > > > > Hi Daniel, > > > > Sorry for the delay in replying. I’ve attached blf.cap which shows > the “light stays on” scenario. You’ll see that the final NOTIFY > (packet 43) is a “confirmed” rather than a “terminated” as per the > PUBLISH (packet 41) that triggered it. > > > > I’ve also attached presentity.txt which is the contents of the DB > before the pcap was taken. > > > > With regards to your question about the light going out after the > entries in the table have expired, this does happen automatically. > As soon as the table drops down to being empty (it takes a couple > of minutes to fully clear), the light goes off. Subsequent calls > will work correctly with BLF until it eventually stops working and > the whole cycle repeats. > > > > I have repeated the test with subs_db_mode 0 and the same results > occur. This is, in fact, the state it was in when the attached > pcap was taken. > > > > Do you think the problem is in the cleanup of the data or in the > way the active dialog is matched against the set of data in the > table? Happy to prod through the code with gdb if you can point me > in the direction of where to start looking. > > > > > > Cheers > > > > Phil > > > > *From:*Daniel-Constantin Mierla [mailto:mico...@gmail.com] > *Sent:* 19 January 2016 23:26 > *To:* Phil Lavin <phil.la...@synety.com > <mailto:phil.la...@synety.com>>; Kamailio (SER) - Users Mailing > List <sr-users@lists.sip-router.org > <mailto:sr-users@lists.sip-router.org>> > *Subject:* Re: [SR-Users] Strange PUA Behaviour > > > > Can you get a pcap for a case with the new config? Being > traveling, but maybe I get a chance to look at it soon. > > Reading quickly on some docs, I noticed that subs_db_mode=3 and > notifier_proceses=0 rise a conflict: > > > http://www.kamailio.org/docs/modules/devel/modules/presence.html#presence.p.notifier_processes > > Can you try with subs_db_mode=0 and see if works different? > > Cheers, > Daniel > > On 19/01/16 20:35, Phil Lavin wrote: > > Just to follow this up with more recent results. I’ve > simplified things and have been testing calling from a > Kamailio registered UA to a phone on the PSTN. There’s only 1 > dialog in Kamailio for this and the results are just as > strange. BLF works for a while and then breaks. In this > particular case, the light does not go off after the call. > > > > I have set subs_db_mode to 3 (new config below) and I can > consistently reproduce the BLF light not turning off after the > call has ended (the phone does not get sent a terminate). As > soon as I truncate pua and presentity tables in the DB, the > next call works fine. > > > > modparam("presence", "subs_db_mode", 3) > > modparam("presence", "notifier_processes", 0) > > modparam("presence", "db_url", DBURL) > > modparam("presence", "send_fast_notify", 0) > > modparam("presence", "db_update_period", 20) > > modparam("presence_xml", "db_url", DBURL) > > modparam("presence_xml", "force_active", 1) > > modparam("presence_dialoginfo", "force_single_dialog", 1) > > modparam("presence_dialoginfo", "force_dummy_dialog", 1) > > modparam("pua", "db_url", DBURL) > > modparam("pua", "db_mode", 2) > > modparam("pua", "update_period", 20) > > modparam("pua_dialoginfo", "send_publish_flag", FLT_DLGINFO) > > modparam("pua_dialoginfo", "override_lifetime", 124) > > > > Before I truncate, the tables both a good number of rows in > each (70ish). > > > > Is it that they’re not being correctly cleaned up here? > > > > > > Thanks > > > > Phil > > > > *From:*sr-users [mailto:sr-users-boun...@lists.sip-router.org] > *On Behalf Of *Phil Lavin > *Sent:* 19 January 2016 18:11 > *To:* mico...@gmail.com <mailto:mico...@gmail.com>; Kamailio > (SER) - Users Mailing List <sr-users@lists.sip-router.org> > <mailto:sr-users@lists.sip-router.org> > *Subject:* Re: [SR-Users] Strange PUA Behaviour > > > > Below is the relevant presence/pua stuff. Let me know if I > should be examining other tables. > > > > When the call ends, there are no dialogs remaining in the > dialog table. A few things do hang around in the presentity > and pua tables for a short period of time. > > > > Regarding CLI changing, it does seem to do so. When the call > is routed onto the billing platform, the CLI is changed to the > local “extension” (e.g. 9989) on the leg that comes back to > Kamailio, destined for the callee. > > > > Regarding only advertising the leg going to the callee, not > all calls will terminate on a UA registered against Kamailio > (e.g. calls from a Kamailio registered UA to the PSTN). The > more I think about it, determining the correct leg in all > scenarios will be difficult. > > > > -- > > Daniel-Constantin Mierla > > http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> - > http://www.linkedin.com/in/miconda > > Book: SIP Routing With Kamailio - http://www.asipto.com > > http://miconda.eu > > > > -- > Daniel-Constantin Mierla > http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> - > http://www.linkedin.com/in/miconda > Book: SIP Routing With Kamailio - http://www.asipto.com > http://miconda.eu -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu
_______________________________________________ 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
