Hi Daniel,
The multiple records are because we are routing calls between UAs which are
both registered against Kamailio via an external SIP server (our billing
engine). That is causing there to be 2 dialogs created.
We have put in a quick hack to not call dlg_manage() when the $fU is "9989".
This does not create 2 records in the dialogs table and the BLF functionality
works as expected.
What do you propose as the correct fix for this situation?
Thanks
Phil
From: Phil Lavin
Sent: 19 January 2016 09:42
To: 'mico...@gmail.com' <mico...@gmail.com>; Kamailio (SER) - Users Mailing
List <sr-users@lists.sip-router.org>
Subject: RE: [SR-Users] Strange PUA Behaviour
Hi Daniel,
Thanks for your response. There are 2 records in the database. They are below:
mysql> select * from dialog\G;
*************************** 1. row ***************************
id: 602
hash_entry: 3537
hash_id: 8368
callid:
8f7b7053-2026fb79-350890bb@172.31.17.81~2o<mailto:8f7b7053-2026fb79-350890bb@172.31.17.81~2o>
from_uri: sip:9989@91.228.242.23
from_tag: bo2laqatpfnl7b3l.o
to_uri: sip:441164969988@185.28.212.118
to_tag: BCC9B8F7-2852AE14
caller_cseq: 124
callee_cseq: 0
caller_route_set: NULL
callee_route_set: NULL
caller_contact: sip:91.228.242.23:5061
callee_contact: sip:441164969988@185.28.212.246:24468
caller_sock: udp:185.28.212.118:5060
callee_sock: udp:185.28.212.118:5060
state: 4
start_time: 1453196293
timeout: 1453239493
sflags: 0
iflags: 0
toroute_name: NULL
req_uri: sip:441164969988@172.31.17.126
xdata: NULL
*************************** 2. row ***************************
id: 603
hash_entry: 2101
hash_id: 11063
callid:
8f7b7053-2026fb79-350890bb@172.31.17.81<mailto:8f7b7053-2026fb79-350890bb@172.31.17.81>
from_uri: sip:441164969989@185.28.212.118
from_tag: 1B2E6CC3-5A94D549
to_uri: sip:441164969988@185.28.212.118;user=phone
to_tag: osmzuhhnrncelo22.i
caller_cseq: 2
callee_cseq: 0
caller_route_set: NULL
callee_route_set: <sip:91.228.242.23:5060;transport=udp;lr>
caller_contact: sip:441164969989@185.28.212.246:7816
callee_contact: sip:91.228.242.23:5061
caller_sock: udp:185.28.212.118:5060
callee_sock: udp:185.28.212.118:5060
state: 4
start_time: 1453196293
timeout: 1453239493
sflags: 0
iflags: 0
toroute_name: NULL
req_uri: sip:441164969...@sip.staging.cloudcall.com
xdata: NULL
2 rows in set (0.00 sec)
Config is as follows:
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("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)
Thanks
Phil
From: Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Sent: 19 January 2016 07:27
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>>; Phil
Lavin <phil.la...@synety.com<mailto:phil.la...@synety.com>>
Subject: Re: [SR-Users] Strange PUA Behaviour
Hello,
when you get such situation, can you check the database and see if there are
more records for the same presence dialog?
Also, can you send here the parameters for pua*/presence* modules? DB URL
parameters are not relevant, you can skip/replace them as they contain password.
Cheers,
Daniel
On 18/01/16 19:15, Phil Lavin wrote:
Hi all,
We are investigating an issue with BLF whereby the BLF key on the subscribed
phone does not always "turn off" after the call has ended. We have enabled
force_single_dialog to keep things simple for debugging. The attached pcap is
the result. The relevant stuff as I see it is:
* Packet #60 - UA sends a BYE
* Packet #62 - PUA sends a PUBLISH over loopback with a state of
"terminated"
* Packet #65 - The PUBLISH is sent out to the subscribed UA as a NOTIFY
with a state of "early"
This causes the BLF light on the phone to continue flashing.
We are running a version of Kamailio compiled from the HEAD of the current 4.3
branch.
Any ideas?
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.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
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
