[SR-Users] Kamailio Presence help required.

Mon Mar 6 23:50:45 CET 2017

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*
> <https://tools.ietf.org/html/rfc3856> and
> *https://tools.ietf.org/html/rfc4235*
> <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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20170306/b730fc65/attachment.html>