[SR-Users] Strange PUA Behaviour

Daniel-Constantin Mierla miconda at gmail.com
Tue Jan 26 12:33:19 CET 2016


Hi Phil,

sorry, couldn't get the time to analyze the pcap, but I still want to do
it and sort it out, being in my short list, just that some higher
priority events, not necessary related to work, squeezed my spare time a
lot.

Cheers,
Daniel

On 22/01/16 14:19, Phil Lavin wrote:
>
> 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; 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,
>
>  
>
> 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/911e93f0/attachment.html>


More information about the sr-users mailing list