[SR-Users] Strange PUA Behaviour

Tue Jan 19 10:41:48 CET 2016

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 at 172.31.17.81~2o
        from_uri: sip:9989 at 91.228.242.23
        from_tag: bo2laqatpfnl7b3l.o
          to_uri: sip:441164969988 at 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 at 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 at 172.31.17.126
           xdata: NULL
*************************** 2. row ***************************
              id: 603
      hash_entry: 2101
         hash_id: 11063
          callid: 8f7b7053-2026fb79-350890bb at 172.31.17.81
        from_uri: sip:441164969989 at 185.28.212.118
        from_tag: 1B2E6CC3-5A94D549
          to_uri: sip:441164969988 at 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 at 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 at 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 at gmail.com]
Sent: 19 January 2016 07:27
To: Kamailio (SER) - Users Mailing List <sr-users at lists.sip-router.org>; Phil Lavin <phil.lavin at synety.com>
Subject: Re: [SR-Users] Strange PUA Behaviour

Hello,

when you get such situation, can you check the database and see if there are more records for the same presence dialog?

Also, can you send here the parameters for pua*/presence* modules? DB URL parameters are not relevant, you can skip/replace them as they contain password.

Cheers,
Daniel
On 18/01/16 19:15, Phil Lavin wrote:
Hi all,

We are investigating an issue with BLF whereby the BLF key on the subscribed phone does not always "turn off" after the call has ended. We have enabled force_single_dialog to keep things simple for debugging. The attached pcap is the result. The relevant stuff as I see it is:

*         Packet #60 - UA sends a BYE

*         Packet #62 - PUA sends a PUBLISH over loopback with a state of "terminated"

*         Packet #65 - The PUBLISH is sent out to the subscribed UA as a NOTIFY with a state of "early"

This causes the BLF light on the phone to continue flashing.

We are running a version of Kamailio compiled from the HEAD of the current 4.3 branch.

Any ideas?

Phil Lavin
Telecoms Systems Manager
CloudCall by SYNETY
www.cloudcall.com<http://www.cloudcall.com/>

T: +44 (0) 330 335 0000 / +1 617 982 1600
D: +44 (0) 116 424 4790 / +1 617 982 4790
SM: LinkedIn<https://uk.linkedin.com/pub/phil-lavin/25/422/750>
READ OUR BLOG FOR SMARTER COMMUNICATIONS<http://t.sidekickopen03.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XX43M2cMvVRrZGW2zq9tRVd0tpR56dKNHf2gJW-W02?t=http%3a%2f%2fwww.synety.com%2fblog&si=4668581662425088&pi=98b5dc7b-6a3f-4319-9221-c422f106ebf9>

Confidentiality: This e-mail transmission, including any attachments, is intended only for the named recipient(s) and may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you have received this transmission in error, or are not the named recipient(s), please notify the sender immediately by return e-mail and permanently delete this transmission, including any attachments.
Security: This e-mail and any attachments are believed to be free from any virus but it is the responsibility of the recipient to ensure this is so. E-mail is not a 100% secure communication.

_______________________________________________

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list

sr-users at lists.sip-router.org<mailto:sr-users at lists.sip-router.org>

http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

--

Daniel-Constantin Mierla

http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

Book: SIP Routing With Kamailio - http://www.asipto.com

http://miconda.eu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160119/29fc5157/attachment.html>