[SR-Users] Digest authentication w/ Kamailio & Freeswitch

Edward Romanenco edward at telemessage.com
Mon May 11 16:16:35 CEST 2020


In my topology, Kamailio is the one making contact with a remote VOIP company, meaning, as it comes for my scope – Kamailio acts as the gateway.

I also have the dialog module loaded.

[cid:image001.png at 01D627AB.1FEFD2F0]

Does it change your answer in any way?

Also, if I choose to authenticate with Freeswitch, do you have any idea how to choose the username/password by the realm? I'm using a singular 'gateway' settings that goes straight to Kamailio, but I may want to have multiple sets of username/password for different providers.

Edward

From: Daniel-Constantin Mierla<mailto:miconda at gmail.com>
Sent: Monday, 11 May 2020 14:33
To: Kamailio (SER) - Users Mailing List<mailto:sr-users at lists.kamailio.org>; Edward Romanenco<mailto:edward at telemessage.com>
Subject: Re: [SR-Users] Digest authentication w/ Kamailio & Freeswitch


Hello,





if you have this topology:



[freeswitch] ====> [kamailio] ====> [gateway]



and the gateway is sending back 407, the I would still use freeswitch to do the authentication, otherwise you need dialog module in kamailio to track cseq changes. FreeSwitch originates the call and then can increase the cseq as it needs. If the gateway is a proxy (e.g., another Kamailio), then cseq increase is not needed and you can just do it with uac module without dialog module.



Regarding your question of adding the Proxy-Authorization header in the first INVITE, that can work sometimes if you know the nonce the gateway is going to use, which can be the case of caching the nonce when receiving the 407 first time and reusing it later. However, the nonce typically is invalidated after a while (or even on first usage), so reusing it is not going to work always. Which is for good reasons, otherwise there can be reply-attacks.



Cheers,
Daniel


On 10.05.20 18:53, Edward Romanenco wrote:
Hi!

I've using a SIP setup that includes both Kamailio & Freeswitch, invites are passed from Freeswitch and relayed by Kamailio to various dispatchers, I would like to have Kamailio authenticating when Proxy Authentication is required.

As I understood, this can be achieved with the help of a failure route, problem is, when I'm utilizing this method - the 407 response gets reverted back to Freeswitch, which returns the revised invite filled with the default Freeswitch username/password, how can let Kamailio handle the authentication once receiving the 407? Can I work straight without relying on a failure route, but having the Proxy Authentication header on my original invite?

This is my relevant configuration -
route[RELAY] {
    if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) {
        if(!t_is_set("branch_route")) {
                        t_on_branch("MANAGE_BRANCH");
                 }
    }
    if (is_method("INVITE|SUBSCRIBE|UPDATE")) {
        if(!t_is_set("onreply_route")) {
                          t_on_reply("MANAGE_REPLY");
                }
    }
    if (is_method("INVITE")) {
        if(!t_is_set("failure_route")) {
                     t_on_failure("KAM_AUTH");
                }
    }

    if (!t_relay()) {
        sl_reply_error();
    }
    exit;
}

failure_route[KAM_AUTH] {
  if(t_check_status("401|407")) {
    $avp(auser) = "xxx";
    $avp(apass) = "yyy";
    t_on_failure("OUTGOING_FAILURE");
    uac_auth();
    t_relay();
    exit;
  }
}

Edward



_______________________________________________

Kamailio (SER) - Users Mailing List

sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>

https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

--

Daniel-Constantin Mierla -- www.asipto.com<http://www.asipto.com>

www.twitter.com/miconda<http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda>

Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200511/b502ae77/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8FB2C107DFC54619A157AA960D4BB7CD.png
Type: image/png
Size: 2600 bytes
Desc: 8FB2C107DFC54619A157AA960D4BB7CD.png
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200511/b502ae77/attachment.png>


More information about the sr-users mailing list