[SR-Users] Kamailio Presence help required.

Wed Mar 8 16:37:37 CET 2017

Hi Phil,
That did help improve the situation; but I've noticed that now when a phone
boots up and sends for SUBSCRIBE its gets a NOTIFY for the request with
state 'terminated' even if the other side is Online/Active.

Here is a sample of the Immediate NOTIFY:

To: <sip:135 at presence.voipguy.ca <sip%3A314 at presence.voipguy.ca>
>;tag=2731947019
From: <sip:201 at presence.voipguy.ca <sip%3A314 at presence.voipguy.ca>
>;tag=5d081ad8df67fd2b232f5240ec63c6ff-f422
CSeq: 2 NOTIFY
Call-ID: 0_1231439266 at 192.168.1.19
Content-Length: 267
User-Agent: kamailio (4.4.4 (x86_64/linux))
Max-Forwards: 70
Event: dialog
Contact: <sip:Server_IP:5060>
Subscription-State: active;expires=1800
Content-Type: application/dialog-info+xml

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1"
state="full" entity="sip:201 at presence.voipguy.ca
<sip%3A314 at presence.voipguy.ca>">
  <dialog id="615293b33c62dec073e05d9421e9f48b" direction="recipient">
    <state>terminated</state>
  </dialog>
</dialog-info>

In above case the 201 device was Registered but its state is set as
terminated. Same signal goes for offline users as well. Is this a standard
reply or something is missing ?

Thanks for your time Phil.

Regards,
Sammy

On Tue, Mar 7, 2017 at 1:54 PM, Phil Lavin <phil.lavin at cloudcall.com> wrote:

> Looks fairly sane. Try setting “pua” db_mode to 0. db_mode 2 takes a very
> different path through the code of the pua module and we have found it to
> be somewhat broken beyond repair. Our config is as follows. You may not
> have some of the stuff highlighted in yellow as I recently added those
> features to Kamailio. Depends which version you’re running. They’re not
> necessary for normal operation, however.
>
>
>
> 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)
>
>
>
> modparam("presence_xml", "db_url", DBURL)
>
> modparam("presence_xml", "force_active", 1)
>
>
>
> 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)
>
>
>
> modparam("pua_dialoginfo", "send_publish_flag", FLT_DLGINFO)
>
> modparam("pua_dialoginfo", "override_lifetime", 14420)
>
> modparam("pua_dialoginfo", "callee_trying", 1)
>
> modparam("pua_dialoginfo", "disable_caller_publish_flag",
> FLT_DISABLE_CALLER_PUBLISH)
>
> modparam("pua_dialoginfo", "disable_callee_publish_flag",
> FLT_DISABLE_CALLEE_PUBLISH)
>
>
>
>
>
> *From:* sr-users [mailto:sr-users-bounces at lists.sip-router.org] *On
> Behalf Of *SamyGo
> *Sent:* 06 March 2017 22:51
> *To:* Kamailio (SER) - Users Mailing List <sr-users at lists.sip-router.org>
>
> *Subject:* Re: [SR-Users] Kamailio Presence help required.
>
>
>
>
>
> Phil, here are all the Presence related modules and their params.
>
> Igor, I go clearly understand that difference and I accept it. However, Im
> finding it difficult to digest that FreeSWITCH sends back initial NOTIFY
> and phone light works while Kamailio is unable to do the same.
>
>
>
>
>
> #!ifdef WITH_PRESENCE
>
> loadmodule "presence.so"
>
> loadmodule "presence_xml.so"
>
> loadmodule "presence_dialoginfo.so"
>
> loadmodule "presence_reginfo.so"
>
> loadmodule "pua.so"
>
> loadmodule "pua_dialoginfo.so"
>
> loadmodule "pua_reginfo.so"
>
> loadmodule "pua_usrloc.so"
>
> #!endif
>
>
>
>
>
> #!ifdef WITH_PRESENCE
>
> # ----- presence params -----
>
> modparam("presence", "db_url", DBURL)
>
> modparam("presence", "server_address", "sip:ServerIP:5060" )
>
> modparam("presence", "send_fast_notify", 0)
>
> modparam("presence", "db_update_period", 20)
>
> modparam("presence", "clean_period", 40)
>
> modparam("presence", "subs_db_mode", 2)
>
> modparam("presence", "fetch_rows", 1000)
>
>
>
> # ----- presence_xml params -----
>
> modparam("presence_xml", "db_url", DBURL)
>
> modparam("presence_xml", "force_active", 1)
>
> modparam("presence_xml", "force_dummy_presence", 1)
>
>
>
>
>
> # ----- presence_dialoginfo params -----
>
> modparam("presence_dialoginfo", "force_single_dialog", 1)
>
> modparam("presence_dialoginfo", "force_dummy_dialog", 0)
>
>
>
> # ----- pua params -----
>
> modparam("pua", "db_url", DBURL)
>
> modparam("pua", "db_mode", 2)
>
> modparam("pua", "update_period", 60)
>
> modparam("pua", "dlginfo_increase_version", 0)
>
> modparam("pua", "reginfo_increase_version", 0)
>
> modparam("pua", "check_remote_contact", 1)
>
> modparam("pua", "fetch_rows", 1000)
>
>
>
> # ----- pua_dialoginfo params -----
>
> modparam("pua_dialoginfo", "include_callid", 1)
>
> modparam("pua_dialoginfo", "send_publish_flag", FLT_DLGINFO)
>
> modparam("pua_dialoginfo", "caller_confirmed", 0)
>
> modparam("pua_dialoginfo", "include_tags", 1)
>
> modparam("pua_dialoginfo", "override_lifetime", 124)
>
>
>
> modparam("pua_reginfo|pua_usrloc", "default_domain", "voipguy.ca")
>
> modparam("pua_reginfo", "server_address", "sip:REGINFO at ServerIP")
>
> modparam("pua_usrloc", "branch_flag", FLT_DLGINFO)
>
>
>
> #!endif
>
>
>
>
>
> Thanks for helping me out on this.
>
>
>
> Regards,
>
> Sammy
>
>
>
>
>
> On Mon, Mar 6, 2017 at 4:31 PM, Igor Olhovskiy <igorolhovskiy at gmail.com>
> wrote:
>
> Hi, Samy.
>
> Point, there is 2 modes of presence. Based on 'presence' and 'dialog'.
> Only 'presence' indicates states like online/offline, 'dialog' indicates
> only different call states, but also hold more info about a call. In
> 'dialog' case XML does not even has an option to indicate, that phone is
> online or offline.
>
> Refer to https://tools.ietf.org/html/rfc3856 and
> https://tools.ietf.org/html/rfc4235
> So, when phone subscribes to 'dialog', according to rfc, they just want to
> know active states and not care about online/offline.
>
>
> Regards, Igor
>
>
> 6 марта 2017 г., 18:00 +0200, Phil Lavin <phil.lavin at cloudcall.com>,
> писал:
>
>
>
> You should get an initial NOTIFY when you subscribe. Can you share the
> parts of your config that are relevant to presence/pua/etc.?
>
>
>
>
>
> *From:* sr-users [mailto:sr-users-bounces at lists.sip-router.org] *On
> Behalf Of* SamyGo
> *Sent:* 06 March 2017 15:50
> *To:* Daniel-Constantin Mierla <miconda at gmail.com>; Kamailio (SER) -
> Users Mailing List <sr-users at lists.sip-router.org>
> *Subject:* Re: [SR-Users] Kamailio Presence help required.
>
>
>
> Thanks Daniel for replying,
>
> Yes the BLF/Callstates are working fine. Problem arise when a phone
> reboots and initially has no Lights indication.
>
>
>
> These are the traces from a Working old-box(not-kamailio) - Kindly guide
> why my Kamailio is unable to send the "immediate NOTIFY" regarding the
> current state of the subscribed extension. If it can do that then I don't
> need to write anything.
>
>
>
>
>
>
>
> SUBSCRIBE sip:314 at presence.voipguy.ca SIP/2.0.
>
> Via: SIP/2.0/UDP 10.0.2.95:5060;branch=z9hG4bK-5ef31b0b.
>
> From: "299" <sip:299 at presence.voipguy.ca>;tag=40ab701f5717f5e9.
>
> To: <sip:314 at presence.voipguy.ca>.
>
> Call-ID: 7f166cd7-a89e6091 at 10.0.2.95.
>
> CSeq: 7888 SUBSCRIBE.
>
> Max-Forwards: 70.
>
> Contact: "299" <sip:299 at 10.0.2.95:5060>.
>
> Accept: application/dialog-info+xml.
>
> Accept: application/x-broadworks-hoteling+xml.
>
> Expires: 1800.
>
> Event: dialog.
>
> User-Agent: Cisco/SPA504G-7.5.6.
>
> Content-Length: 0.
>
> .
>
>
>
>
>
> Server_IP:5060 -> Client_IP:1042
>
>
>
> SIP/2.0 202 Accepted.
>
> v:SIP/2.0/UDP 10.0.2.95:5060;branch=z9hG4bK-5ef31b0b;received=Server_IP;
> rport=1042.
>
> f:"299"<sip:299 at presence.voipguy.ca>;tag=40ab701f5717f5e9.
>
> t:<sip:314 at presence.voipguy.ca>;tag=jYj0rSoBG7KA.
>
> i:7f166cd7-a89e6091 at 10.0.2.95.
>
> CSeq:7888 SUBSCRIBE.
>
> m:<sip:314 at Client_IP:5060>.
>
> Expires:1800.
>
> User-Agent:HV.
>
> Allow:INVITE,ACK,BYE,CANCEL,OPTIONS,MESSAGE,INFO,UPDATE,
> REGISTER,REFER,NOTIFY,PUBLISH,SUBSCRIBE.
>
> k:timer,path,replaces.
>
> u:talk,hold,conference,presence,as-feature-event,
> dialog,line-seize,call-info,sla,include-session-
> description,presence.winfo,message-summary,refer.
>
> Subscription-State:active;expires=1800.
>
> l:0.
>
> .
>
>
>
>
>
> Server_IP:5060 -> Client_IP:1042
>
>
>
> NOTIFY sip:299 at 10.0.2.95:5060 SIP/2.0.
>
> v:SIP/2.0/UDP Client_IP;rport;branch=z9hG4bKUQ5v41FcK0Bvm.
>
> Route:<sip:Server_IP:1042>;transport=udp.
>
> Max-Forwards:70.
>
> f:<sip:314 at presence.voipguy.ca>;tag=jYj0rSoBG7KA.
>
> t:"299"<sip:299 at presence.voipguy.ca>;tag=40ab701f5717f5e9.
>
> i:7f166cd7-a89e6091 at 10.0.2.95.
>
> CSeq:261575252 NOTIFY.
>
> m:sip:314 at Client_IP:5060.
>
> User-Agent:HV.
>
> Allow:INVITE,ACK,BYE,CANCEL,OPTIONS,MESSAGE,INFO,UPDATE,
> REGISTER,REFER,NOTIFY,PUBLISH,SUBSCRIBE.
>
> k:timer,path,replaces.
>
> o:dialog.
>
> u:talk,hold,conference,presence,as-feature-event,
> dialog,line-seize,call-info,sla,include-session-
> description,presence.winfo,message-summary,refer.
>
> Subscription-State:active;expires=1800.
>
> c:application/dialog-info+xml.
>
> l:166.
>
> .
>
> <?xml version="1.0"?>
>
> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0"
> state="full" entity="sip:314 at presence.voipguy.ca">
>
> </dialog-info>
>
>
>
>
>
> Client_IP:1042 -> Server_IP:5060
>
>
>
> SIP/2.0 200 OK.
>
> t:"299"<sip:299 at presence.voipguy.ca>;tag=40ab701f5717f5e9.
>
> f:<sip:314 at presence.voipguy.ca>;tag=jYj0rSoBG7KA.
>
> i:7f166cd7-a89e6091 at 10.0.2.95.
>
> CSeq:261575252 NOTIFY.
>
> v:SIP/2.0/UDP Client_IP;branch=z9hG4bKUQ5v41FcK0Bvm.
>
> Server: Cisco/SPA504G-7.5.6.
>
> Content-Length: 0.
>
> .
>
>
>
>
>
>
>
>
>
> Regards,
>
> Sammy
>
>
>
>
>
> On Mon, Mar 6, 2017 at 2:22 AM, Daniel-Constantin Mierla <
> miconda at gmail.com> wrote:
>
> Hello,
>
> from your description, I don't see a problem from the specs point of view,
> but more like something that you would like to have.
>
> If UA subscribers only for dialog event, then it gets NOTIFY requests only
> for dialog states (new call, ..., termintated call). When it subscribers
> for presence, then it gets UA availability states.
>
> And I think this is what you also get based on description. Am I wright?
>
> Mixing the states of presence for dialog notifications is not possible,
> not in the specs, but eventually you can write a module yourself and map as
> you want/need presence states over dialog states.
>
> Cheers,
> Daniel
>
> On 03/03/2017 19:13, SamyGo wrote:
>
> Hi,
> I'm in need of making/tweak an existing Kamailio Presence setup which is
> giving some tough time.
>
> *Whats already working:*
>
> BLF dialog states changes are already sent across the users. SCA is
> working as well.
>
>
>
> *What isn't working:*
>
> When a User comes online then it sends SUBSCRIBE with *Event: dialog* and
> don't get notified of its subscribers state right then unless the monitored
> extensions make a call (BLF works)
>
> *Why is it not working:*
>
> As evident from wireshark traces, the user IP phones (Test sets: Polycoms,
> Yealink, CISCO, Grandstream) don't send our *Event: presence* rather only
> *Event:dialog* and Kamailio do not send NOTIFY out to everyone. Though
> yes there is an internally generated PUBLISH seen and handled properly upon
> registration state changes.
>
> Jitsi has been tested and Kamailio send out these registration state
> change info to jitsi, somce jitsi sends *Event:presence* in SUBSCRIBE.
>
> I need dialog based NOTIFY to be sent out on registration state-change.
>
> Need pointers and help on the topic, looking forward to some feedback.
>
> Regards,
> Sammy
>
>
>
> _______________________________________________
>
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>
> sr-users at lists.sip-router.org
>
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> --
>
> Daniel-Constantin Mierla
>
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>
> Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com
>
> Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20170308/a3574880/attachment.html>