7 Mar
2017
7 Mar
'17
1:54 p.m.
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@lists.sip-router.org] On Behalf Of SamyGo
Sent: 06 March 2017 22:51
To: Kamailio (SER) - Users Mailing List <sr-users(a)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<http://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
<igorolhovskiy@gmail.com<mailto:igorolhovskiy@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@cloudcall.com<mailto:phil.lavin@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@lists.sip-router.org<mailto:sr-users-bounces@lists.sip-router.org>]
On Behalf Of SamyGo
Sent: 06 March 2017 15:50
To: Daniel-Constantin Mierla <miconda@gmail.com<mailto:miconda@gmail.com>>;
Kamailio (SER) - Users Mailing List
<sr-users@lists.sip-router.org<mailto: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:314@presence.voipguy.ca<mailto:sip%3A314@presence.voipguy.ca>
SIP/2.0.
Via: SIP/2.0/UDP 10.0.2.95:5060;branch=z9hG4bK-5ef31b0b.
From: "299"
<sip:299@presence.voipguy.ca<mailto:sip%3A299@presence.voipguy.ca>>;tag=40ab701f5717f5e9.
To: <sip:314@presence.voipguy.ca<mailto:sip%3A314@presence.voipguy.ca>>.
Call-ID: 7f166cd7-a89e6091@10.0.2.95<mailto:7f166cd7-a89e6091@10.0.2.95>.
CSeq: 7888 SUBSCRIBE.
Max-Forwards: 70.
Contact: "299"
<sip:299@10.0.2.95:5060<http://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:299@presence.voipguy.ca<mailto:sip%3A299@presence.voipguy.ca>>;tag=40ab701f5717f5e9.
t:<sip:314@presence.voipguy.ca<mailto:sip%3A314@presence.voipguy.ca>>;tag=jYj0rSoBG7KA.
i:7f166cd7-a89e6091@10.0.2.95<mailto:i%3A7f166cd7-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<http://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:314@presence.voipguy.ca<mailto:sip%3A314@presence.voipguy.ca>>;tag=jYj0rSoBG7KA.
t:"299"<sip:299@presence.voipguy.ca<mailto:sip%3A299@presence.voipguy.ca>>;tag=40ab701f5717f5e9.
i:7f166cd7-a89e6091@10.0.2.95<mailto:i%3A7f166cd7-a89e6091@10.0.2.95>.
CSeq:261575252<tel: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:314@presence.voipguy.ca<mailto:sip%3A314@presence.voipguy.ca>">
</dialog-info>
Client_IP:1042 -> Server_IP:5060
SIP/2.0 200 OK.
t:"299"<sip:299@presence.voipguy.ca<mailto:sip%3A299@presence.voipguy.ca>>;tag=40ab701f5717f5e9.
f:<sip:314@presence.voipguy.ca<mailto:sip%3A314@presence.voipguy.ca>>;tag=jYj0rSoBG7KA.
i:7f166cd7-a89e6091@10.0.2.95<mailto:i%3A7f166cd7-a89e6091@10.0.2.95>.
CSeq:261575252<tel: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@gmail.com<mailto:miconda@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<mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
www.twitter.com/miconda<http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda>
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) -
www.asipto.com<http://www.asipto.com>
Kamailio World Conference - May 8-10, 2017 -
www.kamailioworld.com<http://www.kamailioworld.com>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org<mailto: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<mailto: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<mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users