20 Mar
2019
20 Mar
'19
2:48 p.m.
Am Mi., 20. März 2019 um 19:28 Uhr schrieb Henning Westerholt <hw(a)kamailio.org>rg>:
Am Dienstag, 19. März 2019, 16:40:23 CET schrieb Kevin Olbrich:
Yes, I am confused :-)
I read the docs and I learned, that the PUA modules with
pua_dialoginfo + dialog (dlg_manage) allow me to track the call state
per endpoint.
This works perfectly (BLF works!) when I remove "WITH_AUTH" but it
does not when it is enabled.
I can see that Kamailio generates a PUBLISH message and sends it back
to itself. (Why? Shouldn't it be doing this inside the application?).
Without AUTH, Kamailio accepts the message and sends NOTIFY to the
endpoints. I do unterstand, that this makes perfect sense for cases
where I host another Kamailio just for the PUBLISH / SUBSCRIBE. (But I
am not...)
Why is it necessary to generate a message that is sent to the own
process? And how is this supposed to work with Kamailio that has AUTH
enabled?
Asterisk for example nerver generates PUBLISH, it just sends NOTIFY to
endpoints (the state is handled internal).
I am running the 5.2 Kamailio config with the additions from the HowTo
and it does not work for me - Kamailio is rejecting it's own message.
thank you! I will check that again.
Hi Kevin,
I don't understand your problem or question, sorry.
Is the Digest Authentication not working correctly? Or are you confused about
the SIP message flow for your wanted Presence application?
Best regards,
Henning
In the mean time, I tried to get this running:
http://kb.asipto.com/kamailio:presence:k43-blf
In my setup, the local node is also the presence server (... or should be).
BLF is working perfectly fine if I disable AUTH (PUBLISH to local ->
NOTIFY to phones).
If I enable AUTH, I can see "PUBLISH" sent to the node itself, getting
denied by a 407 "Proxy Authentication Required".
Do I realy need a SIP message flowing to myself to "PUBLISH" the
change detected by dlg_manage() + presence_dialoginfo +
pua_dialoginfo?
The behavior seems to be correct for external presence management
where I do IP based auth.
For my understanding, Kamailio could handle that internal without
building a SIP message(?).
This is what I set up as params (pbx.example.com -> DOMAIN,
123.123.123.123 Public IP of node):
=======================>%=======================
#!ifdef WITH_PRESENCE
# ----- presence params -----
modparam("presence", "db_url", DBURL)
modparam("presence",
"server_address","sip:123.123.123.123:5060")
modparam("presence", "send_fast_notify", 0)
modparam("presence", "db_update_period", 20)
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)
# ----- presence_dialoginfo params -----
modparam("presence_dialoginfo", "force_single_dialog", 0)
# -- dialog params --
modparam("dialog", "db_url", DBURL)
modparam("dialog", "db_mode", 1)
modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "enable_stats", 1)
modparam("dialog", "dlg_flag", FLT_DLG)
# -- pua parameters --
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)
# CUSTOM
modparam("pua_usrloc", "default_domain",
"pbx.example.com")
modparam("pua_reginfo", "server_address",
"sip:123.123.123.123:5060")
modparam("pua_reginfo", "default_domain",
"pbx.example.com")
#!endif
=======================>%=======================
Kind regards
Kevin
Am Mo., 18. März 2019 um 22:55 Uhr schrieb Henning Westerholt
<hw(a)kamailio.org>rg>:
> Am Montag, 18. März 2019, 19:42:30 CET
schrieb Kevin Olbrich:
> > I rolled back the change and Kamailio still sends the challenge. Seems
> > I took the wrong transaction during debug...
> >
> > Am Mo., 18. März 2019 um 19:16 Uhr schrieb Kevin Olbrich <ko(a)sv01.de>de>:
> > > Hi!
> > >
> > > I am implementing forwarding of SUBSCRIBE (BLF) to an Asterisk behind
> > > Kamailio. This works but Kamailio is not requesting for Auth.
> > >
> > > I then added SUBSCRIBE to:
> > > https://github.com/kamailio/kamailio/blob/master/etc/kamailio.cfg#L746
> > >
> > > And it now challenges the client correctly.
> > >
> > > Why does this line only show REGISTER?
> > > Shouldn't it request a challenge for all messages?
> > > And why does it work with INVITES ootb?
>
> Hi Kevin,
>
> have a look to e.g. this page:
>
> https://andrewjprokop.wordpress.com/2015/01/27/understanding-sip-authentic
> ation/
>
> "That means that messages like INVITE and BYE will receive 407 responses
> and REGISTER and SUBSCRIBE will receive 401 responses."
>
> For this reasons they are two *challenge functions in the auth module
> available.
>
> Cheers,
>
> Henning
>
>
> --
> Henning Westerholt - https://skalatan.de/blog/
> Kamailio services - https://skalatan.de/services
> Kamailio security assessment - https://skalatan.de/de/assessment
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services