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/f18dQhb0S7lC8dDMPbW2n…
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(a)gmail.com; Kamailio (SER) - Users Mailing List
<sr-users(a)lists.sip-router.org>
Cc: Telco Team <telco-team(a)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@gmail.com]
Sent: 19 January 2016 23:26
To: Phil Lavin <phil.lavin@synety.com<mailto:phil.lavin@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…
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@lists.sip-router.org] On Behalf Of Phil Lavin
Sent: 19 January 2016 18:11
To: miconda@gmail.com<mailto:miconda@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://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio -
http://www.asipto.com
http://miconda.eu