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~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.com


T: +44 (0) 330 335 0000 / +1 617 982 1600

D: +44 (0) 116 424 4790 / +1 617 982 4790

SM: LinkedIn

READ OUR BLOG FOR SMARTER COMMUNICATIONS 


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

 

-- 
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