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:1...@presence.voipguy.ca <sip%3a...@presence.voipguy.ca> >;tag=2731947019 From: <sip:2...@presence.voipguy.ca <sip%3a...@presence.voipguy.ca> >;tag=5d081ad8df67fd2b232f5240ec63c6ff-f422 CSeq: 2 NOTIFY Call-ID: 0_1231439266@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:2...@presence.voipguy.ca <sip%3a...@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.la...@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-boun...@lists.sip-router.org] *On > Behalf Of *SamyGo > *Sent:* 06 March 2017 22:51 > *To:* Kamailio (SER) - Users Mailing List <sr-users@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@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 <igorolhovs...@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.la...@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-boun...@lists.sip-router.org] *On > Behalf Of* SamyGo > *Sent:* 06 March 2017 15:50 > *To:* Daniel-Constantin Mierla <mico...@gmail.com>; Kamailio (SER) - > Users Mailing List <sr-users@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:3...@presence.voipguy.ca SIP/2.0. > > Via: SIP/2.0/UDP 10.0.2.95:5060;branch=z9hG4bK-5ef31b0b. > > From: "299" <sip:2...@presence.voipguy.ca>;tag=40ab701f5717f5e9. > > To: <sip:3...@presence.voipguy.ca>. > > Call-ID: 7f166cd7-a89e6091@10.0.2.95. > > CSeq: 7888 SUBSCRIBE. > > Max-Forwards: 70. > > Contact: "299" <sip:299@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:2...@presence.voipguy.ca>;tag=40ab701f5717f5e9. > > t:<sip:3...@presence.voipguy.ca>;tag=jYj0rSoBG7KA. > > i:7f166cd7-a89e6091@10.0.2.95. > > CSeq:7888 SUBSCRIBE. > > m:<sip:314@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@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:3...@presence.voipguy.ca>;tag=jYj0rSoBG7KA. > > t:"299"<sip:2...@presence.voipguy.ca>;tag=40ab701f5717f5e9. > > i:7f166cd7-a89e6091@10.0.2.95. > > CSeq:261575252 NOTIFY. > > m:sip:314@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:3...@presence.voipguy.ca"> > > </dialog-info> > > > > > > Client_IP:1042 -> Server_IP:5060 > > > > SIP/2.0 200 OK. > > t:"299"<sip:2...@presence.voipguy.ca>;tag=40ab701f5717f5e9. > > f:<sip:3...@presence.voipguy.ca>;tag=jYj0rSoBG7KA. > > i:7f166cd7-a89e6091@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 < > mico...@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@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@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@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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users