Hello,
We are using pua-dialoginfo and presence modules for BLF.
When the first call comes in or goes out, every thing works great; however, a second call to the same key/extension (e.g a call waiting which is not answered) would turn off the key even though the original call/dialog is still active.
Has anyone had experienced such problem? How can I fix this?
Any constructive suggestion would be appreciated.
Regards, Ali Pey
Hello,
I know that there are couple of options to tune the behaviour, like sending combined body with all active presence states or sending the most recent one.
Look at the SIP traffic with ngrep or other network capturing tool and see if you spot something wrong there -- eventuall send the text output here (or a pcap) if you are not sure what should be there.
Also, the modparams for all presence/pua modules might be useful for troubleshooting.
Providing the kamailio version as well as what phones are you using it is important as well.
Cheers, Daniel
On 19/05/16 22:24, Ali Pey wrote:
Hello,
We are using pua-dialoginfo and presence modules for BLF.
When the first call comes in or goes out, every thing works great; however, a second call to the same key/extension (e.g a call waiting which is not answered) would turn off the key even though the original call/dialog is still active.
Has anyone had experienced such problem? How can I fix this?
Any constructive suggestion would be appreciated.
Regards, Ali Pey
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
Which version of Kamailio?
We had a tonne of issues with this module – many of which I submitted fixes for.
There were 2 issues that could not be resolved after a fair bit of trying:
· The presentity table was not cleared of the old state when a new state occurred (e.g. both trying and completed would be in the table for a single dialog). The fix for this was to set pua db_mode to 0
· The presentity table was sometimes cleared up too quickly when the dialog was still ongoing. The fix for this was to set the expiry time to a big number. In our case, the billing system won’t let calls go on for more than 4 hours so that value was chosen.
Here’s all the relevant settings:
# ----- presence params ----- modparam("presence", "db_url", DBURL) modparam("presence", "db_update_period", 20) modparam("presence", "clean_period", 60) modparam("presence", "local_log_facility", "LOG_LOCAL3") modparam("presence", "max_expires", 14430) # Max call time (4 hours) plus a little
# ----- presence_xml params ----- modparam("presence_xml", "db_url", DBURL) modparam("presence_xml", "force_active", 1)
# ----- pua params ----- modparam("pua", "db_url", DBURL) modparam("pua", "db_mode", 0) # Memory only. Required due to the "multiple states for a single dialog" bug modparam("pua", "update_period", 20) modparam("pua", "outbound_proxy", MY_SIP_URL)
# ----- pua_dialoginfo params ----- modparam("pua_dialoginfo", "send_publish_flag", FLT_DLGINFO) modparam("pua_dialoginfo", "override_lifetime", 14420) # Max call time (4 hours) plus a little modparam("pua_dialoginfo", "callee_trying", 1)
Phil Lavin Telecoms Systems Manager CloudCall by SYNETY www.cloudcall.comhttp://www.cloudcall.com/
From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Ali Pey Sent: 19 May 2016 21:25 To: Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org Subject: [SR-Users] Sequential calls messes up presence with pua-dialog info
Hello,
We are using pua-dialoginfo and presence modules for BLF.
When the first call comes in or goes out, every thing works great; however, a second call to the same key/extension (e.g a call waiting which is not answered) would turn off the key even though the original call/dialog is still active.
Has anyone had experienced such problem? How can I fix this?
Any constructive suggestion would be appreciated.
Regards, Ali Pey
Thanks for your response phil Kamailio version 4.1.8 Sent from my iPhone
On May 20, 2016, at 3:17 AM, Phil Lavin phil.lavin@synety.com wrote:
Which version of Kamailio?
We had a tonne of issues with this module – many of which I submitted fixes for.
There were 2 issues that could not be resolved after a fair bit of trying:
· The presentity table was not cleared of the old state when a new state occurred (e.g. both trying and completed would be in the table for a single dialog). The fix for this was to set pua db_mode to 0 · The presentity table was sometimes cleared up too quickly when the dialog was still ongoing. The fix for this was to set the expiry time to a big number. In our case, the billing system won’t let calls go on for more than 4 hours so that value was chosen.
Here’s all the relevant settings:
# ----- presence params ----- modparam("presence", "db_url", DBURL) modparam("presence", "db_update_period", 20) modparam("presence", "clean_period", 60) modparam("presence", "local_log_facility", "LOG_LOCAL3") modparam("presence", "max_expires", 14430) # Max call time (4 hours) plus a little
# ----- presence_xml params ----- modparam("presence_xml", "db_url", DBURL) modparam("presence_xml", "force_active", 1)
# ----- pua params ----- modparam("pua", "db_url", DBURL) modparam("pua", "db_mode", 0) # Memory only. Required due to the "multiple states for a single dialog" bug modparam("pua", "update_period", 20) modparam("pua", "outbound_proxy", MY_SIP_URL)
# ----- pua_dialoginfo params ----- modparam("pua_dialoginfo", "send_publish_flag", FLT_DLGINFO) modparam("pua_dialoginfo", "override_lifetime", 14420) # Max call time (4 hours) plus a little modparam("pua_dialoginfo", "callee_trying", 1)
Phil Lavin Telecoms Systems Manager CloudCall by SYNETY www.cloudcall.com
From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Ali Pey Sent: 19 May 2016 21:25 To: Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org Subject: [SR-Users] Sequential calls messes up presence with pua-dialog info
Hello,
We are using pua-dialoginfo and presence modules for BLF.
When the first call comes in or goes out, every thing works great; however, a second call to the same key/extension (e.g a call waiting which is not answered) would turn off the key even though the original call/dialog is still active.
Has anyone had experienced such problem? How can I fix this?
Any constructive suggestion would be appreciated.
Regards, Ali Pey
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
You’re not going to have any of the patches I did – I believe they are all in 4.4. Though… now I look back at them, I’m not sure if any of them are relevant to your problem. The only one that might be relevant is https://github.com/kamailio/kamailio/pull/514 - specifically commit 1c0242f... Though I doubt it will help here.
Give the config I provided a try – that will probably solve your problems.
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 716 242 6604 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: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Pejman Rajabian Sent: 20 May 2016 13:07 To: Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org Subject: Re: [SR-Users] Sequential calls messes up presence with pua-dialog info
Thanks for your response phil Kamailio version 4.1.8 Sent from my iPhone
On May 20, 2016, at 3:17 AM, Phil Lavin <phil.lavin@synety.commailto:phil.lavin@synety.com> wrote: Which version of Kamailio?
We had a tonne of issues with this module – many of which I submitted fixes for.
There were 2 issues that could not be resolved after a fair bit of trying:
· The presentity table was not cleared of the old state when a new state occurred (e.g. both trying and completed would be in the table for a single dialog). The fix for this was to set pua db_mode to 0
· The presentity table was sometimes cleared up too quickly when the dialog was still ongoing. The fix for this was to set the expiry time to a big number. In our case, the billing system won’t let calls go on for more than 4 hours so that value was chosen.
Here’s all the relevant settings:
# ----- presence params ----- modparam("presence", "db_url", DBURL) modparam("presence", "db_update_period", 20) modparam("presence", "clean_period", 60) modparam("presence", "local_log_facility", "LOG_LOCAL3") modparam("presence", "max_expires", 14430) # Max call time (4 hours) plus a little
# ----- presence_xml params ----- modparam("presence_xml", "db_url", DBURL) modparam("presence_xml", "force_active", 1)
# ----- pua params ----- modparam("pua", "db_url", DBURL) modparam("pua", "db_mode", 0) # Memory only. Required due to the "multiple states for a single dialog" bug modparam("pua", "update_period", 20) modparam("pua", "outbound_proxy", MY_SIP_URL)
# ----- pua_dialoginfo params ----- modparam("pua_dialoginfo", "send_publish_flag", FLT_DLGINFO) modparam("pua_dialoginfo", "override_lifetime", 14420) # Max call time (4 hours) plus a little modparam("pua_dialoginfo", "callee_trying", 1)
Phil Lavin Telecoms Systems Manager CloudCall by SYNETY www.cloudcall.comhttp://www.cloudcall.com/
From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Ali Pey Sent: 19 May 2016 21:25 To: Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org> Subject: [SR-Users] Sequential calls messes up presence with pua-dialog info
Hello,
We are using pua-dialoginfo and presence modules for BLF.
When the first call comes in or goes out, every thing works great; however, a second call to the same key/extension (e.g a call waiting which is not answered) would turn off the key even though the original call/dialog is still active.
Has anyone had experienced such problem? How can I fix this?
Any constructive suggestion would be appreciated.
Regards, Ali Pey
_______________________________________________ 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
SOLVED
Hi Phil:
Your below suggestion fixed this problem for us:
modparam("pua_dialoginfo", "override_lifetime", 14420) # Max call time (4 hours) plus a little
Pejman Rajabian
Director of Product Development
iTalk IP Networks LLC Office: (703) 550-8888 x.107 Cell: (571) 723-2224 Fax: (703) 439-1350 mailto:pejman@italkip.com pejman@italkip.com
From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Phil Lavin Sent: Friday, May 20, 2016 10:09 AM To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] Sequential calls messes up presence with pua-dialog info
You’re not going to have any of the patches I did – I believe they are all in 4.4. Though… now I look back at them, I’m not sure if any of them are relevant to your problem. The only one that might be relevant is https://github.com/kamailio/kamailio/pull/514 - specifically commit 1c0242f... Though I doubt it will help here.
Give the config I provided a try – that will probably solve your problems.
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 716 242 6604
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: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Pejman Rajabian Sent: 20 May 2016 13:07 To: Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org Subject: Re: [SR-Users] Sequential calls messes up presence with pua-dialog info
Thanks for your response phil
Kamailio version 4.1.8 Sent from my iPhone
On May 20, 2016, at 3:17 AM, Phil Lavin phil.lavin@synety.com wrote:
Which version of Kamailio?
We had a tonne of issues with this module – many of which I submitted fixes for.
There were 2 issues that could not be resolved after a fair bit of trying:
· The presentity table was not cleared of the old state when a new state occurred (e.g. both trying and completed would be in the table for a single dialog). The fix for this was to set pua db_mode to 0
· The presentity table was sometimes cleared up too quickly when the dialog was still ongoing. The fix for this was to set the expiry time to a big number. In our case, the billing system won’t let calls go on for more than 4 hours so that value was chosen.
Here’s all the relevant settings:
# ----- presence params -----
modparam("presence", "db_url", DBURL)
modparam("presence", "db_update_period", 20)
modparam("presence", "clean_period", 60)
modparam("presence", "local_log_facility", "LOG_LOCAL3")
modparam("presence", "max_expires", 14430) # Max call time (4 hours) plus a little
# ----- presence_xml params -----
modparam("presence_xml", "db_url", DBURL)
modparam("presence_xml", "force_active", 1)
# ----- pua params -----
modparam("pua", "db_url", DBURL)
modparam("pua", "db_mode", 0) # Memory only. Required due to the "multiple states for a single dialog" bug
modparam("pua", "update_period", 20)
modparam("pua", "outbound_proxy", MY_SIP_URL)
# ----- pua_dialoginfo params -----
modparam("pua_dialoginfo", "send_publish_flag", FLT_DLGINFO)
modparam("pua_dialoginfo", "override_lifetime", 14420) # Max call time (4 hours) plus a little
modparam("pua_dialoginfo", "callee_trying", 1)
Phil Lavin
Telecoms Systems Manager
CloudCall by SYNETY http://www.cloudcall.com/ www.cloudcall.com
From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Ali Pey Sent: 19 May 2016 21:25 To: Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org Subject: [SR-Users] Sequential calls messes up presence with pua-dialog info
Hello,
We are using pua-dialoginfo and presence modules for BLF.
When the first call comes in or goes out, every thing works great; however, a second call to the same key/extension (e.g a call waiting which is not answered) would turn off the key even though the original call/dialog is still active.
Has anyone had experienced such problem? How can I fix this?
Any constructive suggestion would be appreciated.
Regards,
Ali Pey
Image removed by sender. https://contactmonkey.com/api/v1/tracker?cm_session=d374fc77-077d-434f-8967-... removed by sender. https://contactmonkey.com/api/v1/tracker?cm_session=d374fc77-077d-434f-8967-...
_______________________________________________ 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
-
Ali Pey -
Daniel-Constantin Mierla -
Pejman Rajabian -
Phil Lavin