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@sv01.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-authenticat...

"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

Hi again!

Any hints? Has someone tested these modules with Kamailio 5.2?

Thank you Kevin

Am Di., 19. März 2019 um 16:40 Uhr schrieb Kevin Olbrich ko@sv01.de:

Hi Henning,

thank you! I will check that again.

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@kamailio.org:

...

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@sv01.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-authenticat...

"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

Am Mi., 20. März 2019 um 19:28 Uhr schrieb Henning Westerholt hw@kamailio.org:

Am Dienstag, 19. März 2019, 16:40:23 CET schrieb Kevin Olbrich:

...

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?

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.

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@kamailio.org:

...

...

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@sv01.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

Am Mi., 20. März 2019 um 20:01 Uhr schrieb Henning Westerholt hw@kamailio.org:

Am Mittwoch, 20. März 2019, 19:48:00 CET schrieb Kevin Olbrich:

...

...

Am Dienstag, 19. März 2019, 16:40:23 CET schrieb Kevin Olbrich:

...

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?

Yes, I am confused :-)

Hi Kevin,

if the AUTH for the Kamailio is the problem, just add some logic to exclude this particular SIP message from Kamailio from the AUTH challenge. Not sure how the Publish looks like, if its targeted to itself maybe something like 'is_method("PUBLISH" && uri == "myself"' would do the trick. Maybe just output the message in the kamailio cfg or look to the SIP signalization.

Ok, I understand. Thought this might be just a wrong module setting. This is what I am using now:

if(is_method("PUBLISH") && from_uri==myself) { # source IP allowed return; }

Is this a safe setting? Looks like I allow forged messages if they set the servers domain in FROM. Do I need to implement $si check?

About the question why it was developed like this - I guess the modules were created independently from each others over several years.

Best regards,

Henning

...

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.

...

...

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@kamailio.org:

...

...

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@sv01.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-authe ntic 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.

-- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://skalatan.de/services

On 20.03.19 20:21, Kevin Olbrich wrote:

Am Mi., 20. März 2019 um 20:01 Uhr schrieb Henning Westerholt hw@kamailio.org:

...

Am Mittwoch, 20. März 2019, 19:48:00 CET schrieb Kevin Olbrich:

...

...

Am Dienstag, 19. März 2019, 16:40:23 CET schrieb Kevin Olbrich:

...

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?

Yes, I am confused :-)

Hi Kevin,

if the AUTH for the Kamailio is the problem, just add some logic to exclude this particular SIP message from Kamailio from the AUTH challenge. Not sure how the Publish looks like, if its targeted to itself maybe something like 'is_method("PUBLISH" && uri == "myself"' would do the trick. Maybe just output the message in the kamailio cfg or look to the SIP signalization.

Ok, I understand. Thought this might be just a wrong module setting. This is what I am using now:

if(is_method("PUBLISH") && from_uri==myself) { # source IP allowed return; }

Is this a safe setting? Looks like I allow forged messages if they set the servers domain in FROM.

This will not be a good condition for security in my opinion, as you mentioned, it allows traffic for PUBLISH with local domains in From, no matter who is sending them.

Probably you can reject PUBLISH requests that don't use local domain/ip in From header. No reason to have them routed by kamailio, because publish should be sent by local users.

if(is_method("PUBLISH") && from_uri!=myself) {

send_reply("403", " Not allowed");   exit;

}

Then do use authentication or conditions on source ip to ensure the traffic is sent by a local user or a trusted peer.

Cheers, Daniel

Do I need to implement $si check?

...

About the question why it was developed like this - I guess the modules were created independently from each others over several years.

Best regards,

Henning

...

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.

...

...

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@kamailio.org:

...

...

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@sv01.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-authe ntic 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.

-- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://skalatan.de/services

---

Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users