[SR-Users] Strange PUA Behaviour
Daniel-Constantin Mierla
miconda at gmail.com
Tue Jan 26 23:41:18 CET 2016
No, I meant when it is taken from dialog max lifetime value (so when the
override_lifetime is not set).
Looks like I need to dig in the code anyhow, I am not the author of the
module to know by heart what is inside -- just need some spare time when
I get to the office, not easy to set a testbed while traveling...
Cheers,
Daniel
On 26/01/16 22:23, Phil Lavin wrote:
>
> It does it when the value is taken from override_lifetime, if that’s
> what you mean. The override_lifetime value has been set sufficiently
> high such that a refresh is not required because calls on our platform
> cannot last more than 4 hours.
>
>
>
>
>
> 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:*Daniel-Constantin Mierla [mailto:miconda at gmail.com]
> *Sent:* 26 January 2016 21:08
> *To:* Phil Lavin <phil.lavin at synety.com>; Kamailio (SER) - Users
> Mailing List <sr-users at lists.sip-router.org>
> *Cc:* Telco Team <telco-team at synety.com>
> *Subject:* Re: [SR-Users] Strange PUA Behaviour
>
>
>
>
>
> 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:* 'miconda at gmail.com <mailto:miconda at gmail.com>'
> <miconda at gmail.com> <mailto:miconda at gmail.com>; Kamailio (SER) -
> Users Mailing List <sr-users at lists.sip-router.org>
> <mailto:sr-users at lists.sip-router.org>
> *Cc:* Telco Team <telco-team at synety.com>
> <mailto:telco-team at 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:miconda at gmail.com]
> *Sent:* 26 January 2016 11:36
> *To:* Phil Lavin <phil.lavin at synety.com
> <mailto:phil.lavin at synety.com>>; Kamailio (SER) - Users Mailing
> List <sr-users at lists.sip-router.org
> <mailto:sr-users at lists.sip-router.org>>
> *Cc:* Telco Team <telco-team at synety.com
> <mailto:telco-team at 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:* miconda at gmail.com <mailto:miconda at gmail.com>; Kamailio
> (SER) - Users Mailing List <sr-users at lists.sip-router.org>
> <mailto:sr-users at lists.sip-router.org>
> *Cc:* Telco Team <telco-team at synety.com>
> <mailto:telco-team at 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:* miconda at gmail.com <mailto:miconda at gmail.com>; Kamailio
> (SER) - Users Mailing List <sr-users at lists.sip-router.org
> <mailto:sr-users at lists.sip-router.org>>
> *Cc:* Telco Team <telco-team at synety.com
> <mailto:telco-team at 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:miconda at gmail.com]
> *Sent:* 19 January 2016 23:26
> *To:* Phil Lavin <phil.lavin at synety.com
> <mailto:phil.lavin at synety.com>>; Kamailio (SER) - Users
> Mailing List <sr-users at lists.sip-router.org
> <mailto:sr-users at 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-bounces at lists.sip-router.org] *On Behalf
> Of *Phil Lavin
> *Sent:* 19 January 2016 18:11
> *To:* miconda at gmail.com <mailto:miconda at gmail.com>;
> Kamailio (SER) - Users Mailing List
> <sr-users at lists.sip-router.org>
> <mailto:sr-users at 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://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160126/38f526d3/attachment.html>
More information about the sr-users
mailing list