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.comhttp://www.cloudcall.com/
T: +44 (0) 330 335 0000 / +1 617 982 1600 D: +44 (0) 116 424 4790 / +1 617 982 4790 SM: LinkedInhttps://uk.linkedin.com/pub/phil-lavin/25/422/750 READ OUR BLOG FOR SMARTER COMMUNICATIONShttp://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.
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 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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 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 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:441164969988@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:miconda@gmail.com] Sent: 19 January 2016 07:27 To: Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org; Phil Lavin phil.lavin@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.comhttp://www.cloudcall.com/
T: +44 (0) 330 335 0000 / +1 617 982 1600 D: +44 (0) 116 424 4790 / +1 617 982 4790 SM: LinkedInhttps://uk.linkedin.com/pub/phil-lavin/25/422/750 READ OUR BLOG FOR SMARTER COMMUNICATIONShttp://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.orgmailto: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
Hello,
and in the presence/pua related tables, do you have records related to the this calls?
Those from dialog table are only for dialog module internal needs.
Cheers, Daniel
On 19/01/16 10:41, Phil Lavin wrote:
Hi Daniel,
Thanks for your response. There are 2 records in the database. They are below:
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: 'miconda@gmail.com' miconda@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~2omailto: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.81mailto: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:441164969988@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:miconda@gmail.com] Sent: 19 January 2016 07:27 To: Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org>; Phil Lavin <phil.lavin@synety.commailto:phil.lavin@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.comhttp://www.cloudcall.com/
T: +44 (0) 330 335 0000 / +1 617 982 1600 D: +44 (0) 116 424 4790 / +1 617 982 4790 SM: LinkedInhttps://uk.linkedin.com/pub/phil-lavin/25/422/750 READ OUR BLOG FOR SMARTER COMMUNICATIONShttp://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.orgmailto: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
Hello,
is any of these two dialogs staying not terminated when the call is ended?
I would only advertise the dialog info states for the call leg going to callee, because it is the one for call pickup.
On the other hand for shared line appearance, the caller is watched as well. Is the caller id changed in the middle?
Cheers, Daniel
On 19/01/16 11:25, Phil Lavin wrote:
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:* 'miconda@gmail.com' miconda@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:
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.
mysql> SELECT * FROM presentity\G *************************** 1. row *************************** id: 1 username: 441164969989 domain: 185.28.212.118 event: dialog etag: a.1453224139.18802.144.0 expires: 1453226868 received_time: 1453226743 body: <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:441164969989@185.28.212.118"> <dialog id="b2d95153-ea311679-84b889bb@172.31.17.81" call-id="b2d95153-ea311679-84b889bb@172.31.17.81" direction="initiator"> <state>Trying</state> <remote> <identity>sip:9988@185.28.212.118;user=phone</identity> <target uri="sip:9988@185.28.212.118;user=phone"/> </remote> <local> <identity>sip:441164969989@185.28.212.118</identity> <target uri="sip:441164969989@185.28.212.118"/> </local> </dialog> </dialog-info>
sender: priority: 0 *************************** 2. row *************************** id: 2 username: 441164969988 domain: 185.28.212.118 event: dialog etag: a.1453224139.18803.173.0 expires: 1453226869 received_time: 1453226744 body: <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:441164969988@185.28.212.118"> <dialog id="b2d95153-ea311679-84b889bb@172.31.17.81~2o" call-id="b2d95153-ea311679-84b889bb@172.31.17.81~2o" local-tag="8D404FC4-3EB13CE3" remote-tag="sl4pzhsqvrpk4wqa.o" direction="recipient"> <state>early</state> <remote> <identity>sip:9989@91.228.242.21</identity> <target uri="sip:91.228.242.21:5061"/> </remote> <local> <identity>sip:441164969988@185.28.212.118</identity> <target uri="sip:441164969988@185.28.212.246:51415"/> </local> </dialog> </dialog-info>
sender: priority: 0 *************************** 3. row *************************** id: 3 username: 441164969989 domain: 185.28.212.118 event: dialog etag: a.1453224139.18816.93.0 expires: 1453226869 received_time: 1453226744 body: <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:441164969989@185.28.212.118"> <dialog id="b2d95153-ea311679-84b889bb@172.31.17.81" call-id="b2d95153-ea311679-84b889bb@172.31.17.81" local-tag="72DEDDC3-BABA2049" remote-tag="hu7u5gyrvjx5ebvc.i" direction="initiator"> <state>early</state> <remote> <identity>sip:9988@185.28.212.118;user=phone</identity> <target uri="sip:91.228.242.21:5061"/> </remote> <local> <identity>sip:441164969989@185.28.212.118</identity> <target uri="sip:441164969989@185.28.212.246:7816"/> </local> </dialog> </dialog-info>
sender: priority: 0 *************************** 4. row *************************** id: 4 username: 9988 domain: 185.28.212.118 event: dialog etag: a.1453224139.18804.132.0 expires: 1453226869 received_time: 1453226744 body: <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:9988@185.28.212.118;user=phone"> <dialog id="b2d95153-ea311679-84b889bb@172.31.17.81" call-id="b2d95153-ea311679-84b889bb@172.31.17.81" local-tag="hu7u5gyrvjx5ebvc.i" remote-tag="72DEDDC3-BABA2049" direction="recipient"> <state>early</state> <remote> <identity>sip:441164969989@185.28.212.118</identity> <target uri="sip:441164969989@185.28.212.246:7816"/> </remote> <local> <identity>sip:9988@185.28.212.118;user=phone</identity> <target uri="sip:91.228.242.21:5061"/> </local> </dialog> </dialog-info>
sender: priority: 0 *************************** 5. row *************************** id: 5 username: 441164969988 domain: 185.28.212.118 event: dialog etag: a.1453224139.18802.145.0 expires: 1453226881 received_time: 1453226756 body: <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:441164969988@185.28.212.118"> <dialog id="b2d95153-ea311679-84b889bb@172.31.17.81~2o" call-id="b2d95153-ea311679-84b889bb@172.31.17.81~2o" direction="recipient"> <state>confirmed</state> <remote> <identity>sip:9989@91.228.242.21</identity> <target uri="sip:91.228.242.21:5061"/> </remote> <local> <identity>sip:441164969988@185.28.212.118</identity> <target uri="sip:441164969988@185.28.212.118"/> </local> </dialog> </dialog-info>
sender: priority: 0 *************************** 6. row *************************** id: 6 username: 441164969989 domain: 185.28.212.118 event: dialog etag: a.1453224139.18803.174.0 expires: 1453226881 received_time: 1453226756 body: <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:441164969989@185.28.212.118"> <dialog id="b2d95153-ea311679-84b889bb@172.31.17.81" call-id="b2d95153-ea311679-84b889bb@172.31.17.81" direction="initiator"> <state>confirmed</state> <remote> <identity>sip:9988@185.28.212.118;user=phone</identity> <target uri="sip:9988@185.28.212.118;user=phone"/> </remote> <local> <identity>sip:441164969989@185.28.212.118</identity> <target uri="sip:441164969989@185.28.212.246:7816"/> </local> </dialog> </dialog-info>
sender: priority: 0 *************************** 7. row *************************** id: 7 username: 9988 domain: 185.28.212.118 event: dialog etag: a.1453224139.18800.126.0 expires: 1453226881 received_time: 1453226756 body: <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:9988@185.28.212.118;user=phone"> <dialog id="b2d95153-ea311679-84b889bb@172.31.17.81" call-id="b2d95153-ea311679-84b889bb@172.31.17.81" direction="recipient"> <state>confirmed</state> <remote> <identity>sip:441164969989@185.28.212.118</identity> <target uri="sip:441164969989@185.28.212.246:7816"/> </remote> <local> <identity>sip:9988@185.28.212.118;user=phone</identity> <target uri="sip:9988@185.28.212.118;user=phone"/> </local> </dialog> </dialog-info>
sender: priority: 0 7 rows in set (0.00 sec)
mysql> SELECT * FROM pua\G *************************** 1. row *************************** id: 1 pres_uri: sip:441164969989@185.28.212.118 pres_id: DIALOG_PUBLISH.b2d95153-ea311679-84b889bb@172.31.17.81 event: 32 expires: 1453226868 desired_expires: 1453226867 flag: 1024 etag: a.1453224139.18802.144.0 tuple_id: watcher_uri: call_id: to_tag: from_tag: cseq: 0 record_route: contact: remote_contact: version: 0 extra_headers: *************************** 2. row *************************** id: 3 pres_uri: sip:441164969989@185.28.212.118 pres_id: DIALOG_PUBLISH.b2d95153-ea311679-84b889bb@172.31.17.81 event: 32 expires: 1453226869 desired_expires: 1453226868 flag: 1024 etag: a.1453224139.18816.93.0 tuple_id: watcher_uri: call_id: to_tag: from_tag: cseq: 0 record_route: contact: remote_contact: version: 0 extra_headers: *************************** 3. row *************************** id: 4 pres_uri: sip:9988@185.28.212.118;user=phone pres_id: DIALOG_PUBLISH.b2d95153-ea311679-84b889bb@172.31.17.81 event: 32 expires: 1453226869 desired_expires: 1453226868 flag: 1024 etag: a.1453224139.18804.132.0 tuple_id: watcher_uri: call_id: to_tag: from_tag: cseq: 0 record_route: contact: remote_contact: version: 0 extra_headers: *************************** 4. row *************************** id: 6 pres_uri: sip:441164969989@185.28.212.118 pres_id: DIALOG_PUBLISH.b2d95153-ea311679-84b889bb@172.31.17.81 event: 32 expires: 1453226881 desired_expires: 1453226880 flag: 1024 etag: a.1453224139.18803.174.0 tuple_id: watcher_uri: call_id: to_tag: from_tag: cseq: 0 record_route: contact: remote_contact: version: 0 extra_headers: *************************** 5. row *************************** id: 7 pres_uri: sip:9988@185.28.212.118;user=phone pres_id: DIALOG_PUBLISH.b2d95153-ea311679-84b889bb@172.31.17.81 event: 32 expires: 1453226881 desired_expires: 1453226880 flag: 1024 etag: a.1453224139.18800.126.0 tuple_id: watcher_uri: call_id: to_tag: from_tag: cseq: 0 record_route: contact: remote_contact: version: 0 extra_headers: 5 rows in set (0.00 sec)
Phil Lavin Telecoms Systems Manager CloudCall by SYNETY www.cloudcall.comhttp://www.cloudcall.com/
T: +44 (0) 330 335 0000 / +1 617 982 1600 D: +44 (0) 116 424 4790 / +1 617 982 4790 SM: LinkedInhttps://uk.linkedin.com/pub/phil-lavin/25/422/750 READ OUR BLOG FOR SMARTER COMMUNICATIONShttp://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@gmail.com] Sent: 19 January 2016 17:49 To: Phil Lavin phil.lavin@synety.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org Subject: Re: [SR-Users] Strange PUA Behaviour
Hello,
is any of these two dialogs staying not terminated when the call is ended?
I would only advertise the dialog info states for the call leg going to callee, because it is the one for call pickup.
On the other hand for shared line appearance, the caller is watched as well. Is the caller id changed in the middle?
Cheers, Daniel On 19/01/16 11:25, Phil Lavin wrote: 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: 'miconda@gmail.commailto:miconda@gmail.com' miconda@gmail.commailto:miconda@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.orgmailto: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:
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
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; Kamailio (SER) - Users Mailing List 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.
mysql> SELECT * FROM presentity\G *************************** 1. row *************************** id: 1 username: 441164969989 domain: 185.28.212.118 event: dialog etag: a.1453224139.18802.144.0 expires: 1453226868 received_time: 1453226743 body: <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:441164969989@185.28.212.118"> <dialog id="b2d95153-ea311679-84b889bb@172.31.17.81<mailto:b2d95153-ea311679-84b889bb@172.31.17.81>" call-id="b2d95153-ea311679-84b889bb@172.31.17.81<mailto:b2d95153-ea311679-84b889bb@172.31.17.81>" direction="initiator"> <state>Trying</state> <remote> <identity>sip:9988@185.28.212.118;user=phone</identitysip:9988@185.28.212.118;user=phone%3c/identity> <target uri="sip:9988@185.28.212.118;user=phone"/> </remote> <local> <identity>sip:441164969989@185.28.212.118</identitysip:441164969989@185.28.212.118%3c/identity> <target uri="sip:441164969989@185.28.212.118"/> </local> </dialog> </dialog-info>
sender: priority: 0 *************************** 2. row *************************** id: 2 username: 441164969988 domain: 185.28.212.118 event: dialog etag: a.1453224139.18803.173.0 expires: 1453226869 received_time: 1453226744 body: <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:441164969988@185.28.212.118"> <dialog id="b2d95153-ea311679-84b889bb@172.31.17.81~2o<mailto:b2d95153-ea311679-84b889bb@172.31.17.81~2o>" call-id="b2d95153-ea311679-84b889bb@172.31.17.81~2o<mailto:b2d95153-ea311679-84b889bb@172.31.17.81~2o>" local-tag="8D404FC4-3EB13CE3" remote-tag="sl4pzhsqvrpk4wqa.o" direction="recipient"> <state>early</state> <remote> <identity>sip:9989@91.228.242.21</identitysip:9989@91.228.242.21%3c/identity> <target uri="sip:91.228.242.21:5061"/> </remote> <local> <identity>sip:441164969988@185.28.212.118</identitysip:441164969988@185.28.212.118%3c/identity> <target uri="sip:441164969988@185.28.212.246:51415"/> </local> </dialog> </dialog-info>
sender: priority: 0 *************************** 3. row *************************** id: 3 username: 441164969989 domain: 185.28.212.118 event: dialog etag: a.1453224139.18816.93.0 expires: 1453226869 received_time: 1453226744 body: <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:441164969989@185.28.212.118"> <dialog id="b2d95153-ea311679-84b889bb@172.31.17.81<mailto:b2d95153-ea311679-84b889bb@172.31.17.81>" call-id="b2d95153-ea311679-84b889bb@172.31.17.81<mailto:b2d95153-ea311679-84b889bb@172.31.17.81>" local-tag="72DEDDC3-BABA2049" remote-tag="hu7u5gyrvjx5ebvc.i" direction="initiator"> <state>early</state> <remote> <identity>sip:9988@185.28.212.118;user=phone</identitysip:9988@185.28.212.118;user=phone%3c/identity> <target uri="sip:91.228.242.21:5061"/> </remote> <local> <identity>sip:441164969989@185.28.212.118</identitysip:441164969989@185.28.212.118%3c/identity> <target uri="sip:441164969989@185.28.212.246:7816"/> </local> </dialog> </dialog-info>
sender: priority: 0 *************************** 4. row *************************** id: 4 username: 9988 domain: 185.28.212.118 event: dialog etag: a.1453224139.18804.132.0 expires: 1453226869 received_time: 1453226744 body: <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:9988@185.28.212.118;user=phone"> <dialog id="b2d95153-ea311679-84b889bb@172.31.17.81<mailto:b2d95153-ea311679-84b889bb@172.31.17.81>" call-id="b2d95153-ea311679-84b889bb@172.31.17.81<mailto:b2d95153-ea311679-84b889bb@172.31.17.81>" local-tag="hu7u5gyrvjx5ebvc.i" remote-tag="72DEDDC3-BABA2049" direction="recipient"> <state>early</state> <remote> <identity>sip:441164969989@185.28.212.118</identitysip:441164969989@185.28.212.118%3c/identity> <target uri="sip:441164969989@185.28.212.246:7816"/> </remote> <local> <identity>sip:9988@185.28.212.118;user=phone</identitysip:9988@185.28.212.118;user=phone%3c/identity> <target uri="sip:91.228.242.21:5061"/> </local> </dialog> </dialog-info>
sender: priority: 0 *************************** 5. row *************************** id: 5 username: 441164969988 domain: 185.28.212.118 event: dialog etag: a.1453224139.18802.145.0 expires: 1453226881 received_time: 1453226756 body: <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:441164969988@185.28.212.118"> <dialog id="b2d95153-ea311679-84b889bb@172.31.17.81~2o<mailto:b2d95153-ea311679-84b889bb@172.31.17.81~2o>" call-id="b2d95153-ea311679-84b889bb@172.31.17.81~2o<mailto:b2d95153-ea311679-84b889bb@172.31.17.81~2o>" direction="recipient"> <state>confirmed</state> <remote> <identity>sip:9989@91.228.242.21</identitysip:9989@91.228.242.21%3c/identity> <target uri="sip:91.228.242.21:5061"/> </remote> <local> <identity>sip:441164969988@185.28.212.118</identitysip:441164969988@185.28.212.118%3c/identity> <target uri="sip:441164969988@185.28.212.118"/> </local> </dialog> </dialog-info>
sender: priority: 0 *************************** 6. row *************************** id: 6 username: 441164969989 domain: 185.28.212.118 event: dialog etag: a.1453224139.18803.174.0 expires: 1453226881 received_time: 1453226756 body: <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:441164969989@185.28.212.118"> <dialog id="b2d95153-ea311679-84b889bb@172.31.17.81<mailto:b2d95153-ea311679-84b889bb@172.31.17.81>" call-id="b2d95153-ea311679-84b889bb@172.31.17.81<mailto:b2d95153-ea311679-84b889bb@172.31.17.81>" direction="initiator"> <state>confirmed</state> <remote> <identity>sip:9988@185.28.212.118;user=phone</identitysip:9988@185.28.212.118;user=phone%3c/identity> <target uri="sip:9988@185.28.212.118;user=phone"/> </remote> <local> <identity>sip:441164969989@185.28.212.118</identitysip:441164969989@185.28.212.118%3c/identity> <target uri="sip:441164969989@185.28.212.246:7816"/> </local> </dialog> </dialog-info>
sender: priority: 0 *************************** 7. row *************************** id: 7 username: 9988 domain: 185.28.212.118 event: dialog etag: a.1453224139.18800.126.0 expires: 1453226881 received_time: 1453226756 body: <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:9988@185.28.212.118;user=phone"> <dialog id="b2d95153-ea311679-84b889bb@172.31.17.81<mailto:b2d95153-ea311679-84b889bb@172.31.17.81>" call-id="b2d95153-ea311679-84b889bb@172.31.17.81<mailto:b2d95153-ea311679-84b889bb@172.31.17.81>" direction="recipient"> <state>confirmed</state> <remote> <identity>sip:441164969989@185.28.212.118</identitysip:441164969989@185.28.212.118%3c/identity> <target uri="sip:441164969989@185.28.212.246:7816"/> </remote> <local> <identity>sip:9988@185.28.212.118;user=phone</identitysip:9988@185.28.212.118;user=phone%3c/identity> <target uri="sip:9988@185.28.212.118;user=phone"/> </local> </dialog> </dialog-info>
sender: priority: 0 7 rows in set (0.00 sec)
mysql> SELECT * FROM pua\G *************************** 1. row *************************** id: 1 pres_uri: sip:441164969989@185.28.212.118 pres_id: DIALOG_PUBLISH.b2d95153-ea311679-84b889bb@172.31.17.81mailto:DIALOG_PUBLISH.b2d95153-ea311679-84b889bb@172.31.17.81 event: 32 expires: 1453226868 desired_expires: 1453226867 flag: 1024 etag: a.1453224139.18802.144.0 tuple_id: watcher_uri: call_id: to_tag: from_tag: cseq: 0 record_route: contact: remote_contact: version: 0 extra_headers: *************************** 2. row *************************** id: 3 pres_uri: sip:441164969989@185.28.212.118 pres_id: DIALOG_PUBLISH.b2d95153-ea311679-84b889bb@172.31.17.81mailto:DIALOG_PUBLISH.b2d95153-ea311679-84b889bb@172.31.17.81 event: 32 expires: 1453226869 desired_expires: 1453226868 flag: 1024 etag: a.1453224139.18816.93.0 tuple_id: watcher_uri: call_id: to_tag: from_tag: cseq: 0 record_route: contact: remote_contact: version: 0 extra_headers: *************************** 3. row *************************** id: 4 pres_uri: sip:9988@185.28.212.118;user=phone pres_id: DIALOG_PUBLISH.b2d95153-ea311679-84b889bb@172.31.17.81mailto:DIALOG_PUBLISH.b2d95153-ea311679-84b889bb@172.31.17.81 event: 32 expires: 1453226869 desired_expires: 1453226868 flag: 1024 etag: a.1453224139.18804.132.0 tuple_id: watcher_uri: call_id: to_tag: from_tag: cseq: 0 record_route: contact: remote_contact: version: 0 extra_headers: *************************** 4. row *************************** id: 6 pres_uri: sip:441164969989@185.28.212.118 pres_id: DIALOG_PUBLISH.b2d95153-ea311679-84b889bb@172.31.17.81mailto:DIALOG_PUBLISH.b2d95153-ea311679-84b889bb@172.31.17.81 event: 32 expires: 1453226881 desired_expires: 1453226880 flag: 1024 etag: a.1453224139.18803.174.0 tuple_id: watcher_uri: call_id: to_tag: from_tag: cseq: 0 record_route: contact: remote_contact: version: 0 extra_headers: *************************** 5. row *************************** id: 7 pres_uri: sip:9988@185.28.212.118;user=phone pres_id: DIALOG_PUBLISH.b2d95153-ea311679-84b889bb@172.31.17.81mailto:DIALOG_PUBLISH.b2d95153-ea311679-84b889bb@172.31.17.81 event: 32 expires: 1453226881 desired_expires: 1453226880 flag: 1024 etag: a.1453224139.18800.126.0 tuple_id: watcher_uri: call_id: to_tag: from_tag: cseq: 0 record_route: contact: remote_contact: version: 0 extra_headers: 5 rows in set (0.00 sec)
Phil Lavin Telecoms Systems Manager CloudCall by SYNETY www.cloudcall.comhttp://www.cloudcall.com/
T: +44 (0) 330 335 0000 / +1 617 982 1600 D: +44 (0) 116 424 4790 / +1 617 982 4790 SM: LinkedInhttps://uk.linkedin.com/pub/phil-lavin/25/422/750 READ OUR BLOG FOR SMARTER COMMUNICATIONShttp://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@gmail.com] Sent: 19 January 2016 17:49 To: Phil Lavin <phil.lavin@synety.commailto:phil.lavin@synety.com>; Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org> Subject: Re: [SR-Users] Strange PUA Behaviour
Hello,
is any of these two dialogs staying not terminated when the call is ended?
I would only advertise the dialog info states for the call leg going to callee, because it is the one for call pickup.
On the other hand for shared line appearance, the caller is watched as well. Is the caller id changed in the middle?
Cheers, Daniel On 19/01/16 11:25, Phil Lavin wrote: 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: 'miconda@gmail.commailto:miconda@gmail.com' miconda@gmail.commailto:miconda@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.orgmailto: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:
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
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; Kamailio (SER) - Users Mailing List 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.
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; Kamailio (SER) - Users Mailing List 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.commailto:miconda@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.orgmailto: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
Hi Daniel,
Any thoughts on this?
Thanks
Phil Lavin Telecoms Systems Manager CloudCall by SYNETY www.cloudcall.comhttp://www.cloudcall.com/
T: +44 (0) 330 335 0000 / +1 617 982 1600 D: +44 (0) 116 424 4790 / +1 617 982 4790 SM: LinkedInhttps://uk.linkedin.com/pub/phil-lavin/25/422/750 READ OUR BLOG FOR SMARTER COMMUNICATIONShttp://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@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org Cc: Telco Team telco-team@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.commailto:phil.lavin@synety.com>; Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.orgmailto: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.commailto:miconda@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.orgmailto: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
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@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org *Cc:* Telco Team telco-team@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://twitter.com/#%21/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu
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?
* 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?
# ----- 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@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org Cc: Telco Team telco-team@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.comhttp://www.cloudcall.com/
T: +44 (0) 330 335 0000 / +1 617 982 1600 D: +44 (0) 116 424 4790 / +1 617 982 4790 SM: LinkedInhttps://uk.linkedin.com/pub/phil-lavin/25/422/750 READ OUR BLOG FOR SMARTER COMMUNICATIONShttp://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@gmail.commailto:miconda@gmail.com; Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org> Cc: Telco Team <telco-team@synety.commailto:telco-team@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.commailto:phil.lavin@synety.com>; Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.orgmailto: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.commailto:miconda@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.orgmailto: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
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@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org *Cc:* Telco Team telco-team@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@gmail.com mailto:miconda@gmail.com; Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.org mailto:sr-users@lists.sip-router.org> *Cc:* Telco Team <telco-team@synety.com mailto:telco-team@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://twitter.com/#%21/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu
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@gmail.com] Sent: 26 January 2016 11:36 To: Phil Lavin phil.lavin@synety.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org Cc: Telco Team telco-team@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@gmail.commailto:miconda@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org Cc: Telco Team telco-team@synety.commailto:telco-team@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.comhttp://www.cloudcall.com/
T: +44 (0) 330 335 0000 / +1 617 982 1600 D: +44 (0) 116 424 4790 / +1 617 982 4790 SM: LinkedInhttps://uk.linkedin.com/pub/phil-lavin/25/422/750 READ OUR BLOG FOR SMARTER COMMUNICATIONShttp://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@gmail.commailto:miconda@gmail.com; Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org> Cc: Telco Team <telco-team@synety.commailto:telco-team@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.commailto:phil.lavin@synety.com>; Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.orgmailto: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.commailto:miconda@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.orgmailto: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/#!/micondahttp://twitter.com/#%21/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
Sorry, correction - desired expires is always 1 second LESS than expires.
Phil
From: Phil Lavin Sent: 26 January 2016 11:54 To: 'miconda@gmail.com' miconda@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org Cc: Telco Team telco-team@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@gmail.com] Sent: 26 January 2016 11:36 To: Phil Lavin <phil.lavin@synety.commailto:phil.lavin@synety.com>; Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org> Cc: Telco Team <telco-team@synety.commailto:telco-team@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@gmail.commailto:miconda@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org Cc: Telco Team telco-team@synety.commailto:telco-team@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.comhttp://www.cloudcall.com/
T: +44 (0) 330 335 0000 / +1 617 982 1600 D: +44 (0) 116 424 4790 / +1 617 982 4790 SM: LinkedInhttps://uk.linkedin.com/pub/phil-lavin/25/422/750 READ OUR BLOG FOR SMARTER COMMUNICATIONShttp://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@gmail.commailto:miconda@gmail.com; Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org> Cc: Telco Team <telco-team@synety.commailto:telco-team@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.commailto:phil.lavin@synety.com>; Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.orgmailto: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.commailto:miconda@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.orgmailto: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/#!/micondahttp://twitter.com/#%21/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
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@gmail.com' miconda@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org *Cc:* Telco Team telco-team@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@gmail.com] *Sent:* 26 January 2016 11:36 *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> *Cc:* Telco Team <telco-team@synety.com mailto:telco-team@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@gmail.com <mailto:miconda@gmail.com>; Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.org> <mailto:sr-users@lists.sip-router.org> *Cc:* Telco Team <telco-team@synety.com> <mailto:telco-team@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@gmail.com <mailto:miconda@gmail.com>; Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org>> *Cc:* Telco Team <telco-team@synety.com <mailto:telco-team@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.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@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://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
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.comhttp://www.cloudcall.com/
T: +44 (0) 330 335 0000 / +1 617 982 1600 D: +44 (0) 116 424 4790 / +1 617 982 4790 SM: LinkedInhttps://uk.linkedin.com/pub/phil-lavin/25/422/750 READ OUR BLOG FOR SMARTER COMMUNICATIONShttp://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@gmail.com] Sent: 26 January 2016 21:08 To: Phil Lavin phil.lavin@synety.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org Cc: Telco Team telco-team@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@gmail.commailto:miconda@gmail.com' miconda@gmail.commailto:miconda@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org Cc: Telco Team telco-team@synety.commailto:telco-team@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@gmail.com] Sent: 26 January 2016 11:36 To: Phil Lavin <phil.lavin@synety.commailto:phil.lavin@synety.com>; Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org> Cc: Telco Team <telco-team@synety.commailto:telco-team@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@gmail.commailto:miconda@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org Cc: Telco Team telco-team@synety.commailto:telco-team@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.comhttp://www.cloudcall.com/
T: +44 (0) 330 335 0000 / +1 617 982 1600 D: +44 (0) 116 424 4790 / +1 617 982 4790 SM: LinkedInhttps://uk.linkedin.com/pub/phil-lavin/25/422/750 READ OUR BLOG FOR SMARTER COMMUNICATIONShttp://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@gmail.commailto:miconda@gmail.com; Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org> Cc: Telco Team <telco-team@synety.commailto:telco-team@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.commailto:phil.lavin@synety.com>; Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.orgmailto: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.commailto:miconda@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.orgmailto: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/#!/micondahttp://twitter.com/#%21/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
--
Daniel-Constantin Mierla
http://twitter.com/#!/micondahttp://twitter.com/#%21/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
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@gmail.com] *Sent:* 26 January 2016 21:08 *To:* Phil Lavin phil.lavin@synety.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org *Cc:* Telco Team telco-team@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@gmail.com <mailto:miconda@gmail.com>' <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> *Cc:* Telco Team <telco-team@synety.com> <mailto:telco-team@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@gmail.com] *Sent:* 26 January 2016 11:36 *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>> *Cc:* Telco Team <telco-team@synety.com <mailto:telco-team@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@gmail.com <mailto:miconda@gmail.com>; Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.org> <mailto:sr-users@lists.sip-router.org> *Cc:* Telco Team <telco-team@synety.com> <mailto:telco-team@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@gmail.com <mailto:miconda@gmail.com>; Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org>> *Cc:* Telco Team <telco-team@synety.com <mailto:telco-team@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.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@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://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
I see the records in presentity table are expiring rather in short interval. Is the lamp still on after that?
Cheers, Daniel
On 19/01/16 19:10, Phil Lavin wrote:
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.
mysql> SELECT * FROM presentity\G
*************************** 1. row ***************************
id: 1 username: 441164969989 domain: 185.28.212.118 event: dialog etag: a.1453224139.18802.144.0 expires: 1453226868received_time: 1453226743
body: <?xml version="1.0"?><dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:441164969989@185.28.212.118">
<dialog id="b2d95153-ea311679-84b889bb@172.31.17.81" call-id="b2d95153-ea311679-84b889bb@172.31.17.81" direction="initiator">
<state>Trying</state> <remote> <identity>sip:9988@185.28.212.118;user=phone</identity> <target uri="sip:9988@185.28.212.118;user=phone"/> </remote> <local> <identity>sip:441164969989@185.28.212.118</identity> <target uri="sip:441164969989@185.28.212.118"/> </local></dialog>
</dialog-info>
sender: priority: 0*************************** 2. row ***************************
id: 2 username: 441164969988 domain: 185.28.212.118 event: dialog etag: a.1453224139.18803.173.0 expires: 1453226869received_time: 1453226744
body: <?xml version="1.0"?><dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:441164969988@185.28.212.118">
<dialog id="b2d95153-ea311679-84b889bb@172.31.17.81~2o" call-id="b2d95153-ea311679-84b889bb@172.31.17.81~2o" local-tag="8D404FC4-3EB13CE3" remote-tag="sl4pzhsqvrpk4wqa.o" direction="recipient">
<state>early</state> <remote> <identity>sip:9989@91.228.242.21</identity> <target uri="sip:91.228.242.21:5061"/> </remote> <local> <identity>sip:441164969988@185.28.212.118</identity> <target uri="sip:441164969988@185.28.212.246:51415"/> </local></dialog>
</dialog-info>
sender: priority: 0*************************** 3. row ***************************
id: 3 username: 441164969989 domain: 185.28.212.118 event: dialog etag: a.1453224139.18816.93.0 expires: 1453226869received_time: 1453226744
body: <?xml version="1.0"?><dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:441164969989@185.28.212.118">
<dialog id="b2d95153-ea311679-84b889bb@172.31.17.81" call-id="b2d95153-ea311679-84b889bb@172.31.17.81" local-tag="72DEDDC3-BABA2049" remote-tag="hu7u5gyrvjx5ebvc.i" direction="initiator">
<state>early</state> <remote> <identity>sip:9988@185.28.212.118;user=phone</identity> <target uri="sip:91.228.242.21:5061"/> </remote> <local> <identity>sip:441164969989@185.28.212.118</identity> <target uri="sip:441164969989@185.28.212.246:7816"/> </local></dialog>
</dialog-info>
sender: priority: 0*************************** 4. row ***************************
id: 4 username: 9988 domain: 185.28.212.118 event: dialog etag: a.1453224139.18804.132.0 expires: 1453226869received_time: 1453226744
body: <?xml version="1.0"?><dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:9988@185.28.212.118;user=phone">
<dialog id="b2d95153-ea311679-84b889bb@172.31.17.81" call-id="b2d95153-ea311679-84b889bb@172.31.17.81" local-tag="hu7u5gyrvjx5ebvc.i" remote-tag="72DEDDC3-BABA2049" direction="recipient">
<state>early</state> <remote> <identity>sip:441164969989@185.28.212.118</identity> <target uri="sip:441164969989@185.28.212.246:7816"/> </remote><local>
<identity>sip:9988@185.28.212.118;user=phone</identity> <target uri="sip:91.228.242.21:5061"/> </local></dialog>
</dialog-info>
sender: priority: 0*************************** 5. row ***************************
id: 5 username: 441164969988 domain: 185.28.212.118 event: dialog etag: a.1453224139.18802.145.0 expires: 1453226881received_time: 1453226756
body: <?xml version="1.0"?><dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:441164969988@185.28.212.118">
<dialog id="b2d95153-ea311679-84b889bb@172.31.17.81~2o" call-id="b2d95153-ea311679-84b889bb@172.31.17.81~2o" direction="recipient">
<state>confirmed</state> <remote> <identity>sip:9989@91.228.242.21</identity> <target uri="sip:91.228.242.21:5061"/> </remote> <local> <identity>sip:441164969988@185.28.212.118</identity> <target uri="sip:441164969988@185.28.212.118"/> </local></dialog>
</dialog-info>
sender: priority: 0*************************** 6. row ***************************
id: 6 username: 441164969989 domain: 185.28.212.118 event: dialog etag: a.1453224139.18803.174.0 expires: 1453226881received_time: 1453226756
body: <?xml version="1.0"?><dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:441164969989@185.28.212.118">
<dialog id="b2d95153-ea311679-84b889bb@172.31.17.81" call-id="b2d95153-ea311679-84b889bb@172.31.17.81" direction="initiator">
<state>confirmed</state> <remote> <identity>sip:9988@185.28.212.118;user=phone</identity> <target uri="sip:9988@185.28.212.118;user=phone"/> </remote> <local> <identity>sip:441164969989@185.28.212.118</identity> <target uri="sip:441164969989@185.28.212.246:7816"/> </local></dialog>
</dialog-info>
sender: priority: 0*************************** 7. row ***************************
id: 7 username: 9988 domain: 185.28.212.118 event: dialog etag: a.1453224139.18800.126.0 expires: 1453226881received_time: 1453226756
body: <?xml version="1.0"?><dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:9988@185.28.212.118;user=phone">
<dialog id="b2d95153-ea311679-84b889bb@172.31.17.81" call-id="b2d95153-ea311679-84b889bb@172.31.17.81" direction="recipient">
<state>confirmed</state> <remote> <identity>sip:441164969989@185.28.212.118</identity> <target uri="sip:441164969989@185.28.212.246:7816"/> </remote> <local> <identity>sip:9988@185.28.212.118;user=phone</identity> <target uri="sip:9988@185.28.212.118;user=phone"/> </local></dialog>
</dialog-info>
sender: priority: 07 rows in set (0.00 sec)
mysql> SELECT * FROM pua\G
*************************** 1. row ***************************
id: 1 pres_uri: sip:441164969989@185.28.212.118 pres_id: DIALOG_PUBLISH.b2d95153-ea311679-84b889bb@172.31.17.81 event: 32 expires: 1453226868desired_expires: 1453226867
flag: 1024 etag: a.1453224139.18802.144.0 tuple_id: watcher_uri: call_id: to_tag: from_tag: cseq: 0record_route:
contact:remote_contact:
version: 0extra_headers:
*************************** 2. row ***************************
id: 3 pres_uri: sip:441164969989@185.28.212.118 pres_id: DIALOG_PUBLISH.b2d95153-ea311679-84b889bb@172.31.17.81 event: 32 expires: 1453226869desired_expires: 1453226868
flag: 1024 etag: a.1453224139.18816.93.0 tuple_id: watcher_uri: call_id: to_tag: from_tag: cseq: 0record_route:
contact:remote_contact:
version: 0extra_headers:
*************************** 3. row ***************************
id: 4 pres_uri: sip:9988@185.28.212.118;user=phone pres_id: DIALOG_PUBLISH.b2d95153-ea311679-84b889bb@172.31.17.81 event: 32 expires: 1453226869desired_expires: 1453226868
flag: 1024 etag: a.1453224139.18804.132.0 tuple_id: watcher_uri: call_id: to_tag: from_tag: cseq: 0record_route:
contact:remote_contact:
version: 0extra_headers:
*************************** 4. row ***************************
id: 6 pres_uri: sip:441164969989@185.28.212.118 pres_id: DIALOG_PUBLISH.b2d95153-ea311679-84b889bb@172.31.17.81 event: 32 expires: 1453226881desired_expires: 1453226880
flag: 1024 etag: a.1453224139.18803.174.0 tuple_id: watcher_uri: call_id: to_tag: from_tag: cseq: 0record_route:
contact:remote_contact:
version: 0extra_headers:
*************************** 5. row ***************************
id: 7 pres_uri: sip:9988@185.28.212.118;user=phone pres_id: DIALOG_PUBLISH.b2d95153-ea311679-84b889bb@172.31.17.81 event: 32 expires: 1453226881desired_expires: 1453226880
flag: 1024 etag: a.1453224139.18800.126.0 tuple_id: watcher_uri: call_id: to_tag: from_tag: cseq: 0record_route:
contact:remote_contact:
version: 0extra_headers:
5 rows in set (0.00 sec)
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@gmail.com] *Sent:* 19 January 2016 17:49 *To:* Phil Lavin phil.lavin@synety.com; Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org *Subject:* Re: [SR-Users] Strange PUA Behaviour
Hello,
is any of these two dialogs staying not terminated when the call is ended?
I would only advertise the dialog info states for the call leg going to callee, because it is the one for call pickup.
On the other hand for shared line appearance, the caller is watched as well. Is the caller id changed in the middle?
Cheers, Daniel
On 19/01/16 11:25, Phil Lavin wrote:
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:* 'miconda@gmail.com <mailto:miconda@gmail.com>' <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 Hi Daniel, Thanks for your response. There are 2 records in the database. They are below:-- 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 -
Phil Lavin