[SR-Users] Strange PUA Behaviour
Daniel-Constantin Mierla
miconda at gmail.com
Tue Jan 26 12:36:00 CET 2016
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; 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
>
>
>
> 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://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/e218101c/attachment.html>
More information about the sr-users
mailing list