[SR-Users] UAC authentication challenge response using KEMI/app_ruby

[Daniel-Constantin Mierla]

Hello,

can you remove the KSR::COREX.append_branch()? The uac_auth() should
create a branch, should be no need to append a new one.

As for realm, you can leave it unset, to avoid an extra op of setting an
empty string.

Cheers,
Daniel

On 05.04.19 05:43, Andrew White wrote:
> Hi all,
>
> I’ve gotten a little closer.
>
> After setting my $avp(arealm) to an empty string, I’ve been able to
> get a Authorization response sent. It appears that my trunk in this
> case regularly responds from different realms, which is an issue I’ll
> have to deal with another time.
>
> Since then, I’m now sending a valid Authorization header back in a
> second invite, however I’m also sending an identical invite
> immediately after:
>
> https://i.imgur.com/lmuglwu.png
>
> The code block generating this is the same as below, but with the
> append_branch():
>
> if KSR::UAC.uac_auth() then
> KSR <http://KSR.info>.info <http://KSR.info>("UAC authed, relaying")
> KSR::COREX.append_branch()
> KSR::TM.t_relay()
> else
>
> Removing the t_relay() obviously stops any response at all, and
> removing the append_branch means only an ACK is sent.
>
> Can anyone point me the right way here?
>
> Thanks!
> ________________________________
>
> Andrew White - Director
> uConnected
> Email: andrew at uconnected.com.au <mailto:andrew at uconnected.com.au>
> Web: www.uConnected.com.au <http://www.uConnected.com.au>
>
>> On 5 Apr 2019, at 2:07 pm, Andrew White <andrew at uconnected.com.au
>> <mailto:andrew at uconnected.com.au>> wrote:
>>
>> Hi all,
>>
>> I’m continuing on my quest to use app_ruby for my logic - it’s
>> working very well so far!
>>
>> The last major hurdle I’ve come across is UAC response to WWW
>> challenge. On my outbound path, the correct URIs for From and To are
>> set based on provider requirements, and the INVITE is sent using
>> t_relay():
>>
>> def ksr_route_to_trunk()
>> KSR.info("Route to trunk")
>> if KSR::TM.t_is_set("failure_route") < 0 then
>> KSR::TM.t_on_failure("ksr_failure_manage_trunk")
>> end
>> # Relay
>> KSR::PV.sets("$fu",
>> "sip:#{$uacs[trunk]['r_username']}@#{$uacs[trunk]['r_domain']}")
>> KSR::PV.sets("$fn", '')
>> new_uri = "sip:61400123123@#{uacs[trunk]['r_domain']}"
>> KSR.info("New URI is #{new_uri}")
>> KSR.seturi(uri)
>> KSR::UAC.uac_replace_to('', uri)
>> KSR::TM.t_relay()
>> exit
>> end
>>
>> I’ve stripped it back, but this function is great and works
>> perfectly. An INVITE is sent to the correct place, and the trunk
>> receives the INVITE. It then responds with a 401/WWW-Authenticate.
>>
>> My failure route is called fine. Below is the stripped down code:
>>
>> def ksr_failure_manage_trunk()
>> exit if KSR::TM.t_is_canceled() > 0
>> KSR.info("Hit trunk failure manage route")
>> KSR::PV.sets("$avp(auser)", 'user')
>> KSR::PV.sets("$avp(apass)", 'pass')
>> KSR::PV.sets("$avp(arealm)", 'test.local')
>> KSR.info("AVPs:
>> #{KSR::PV.gete("$avp(auser)")}#{KSR::PV.gete("$avp(apass)")}#{KSR::PV.gete("$avp(arealm)")}")
>> if KSR::UAC.uac_auth() then
>> KSR.info("UAC authed, relaying")
>> KSR::TM.t_relay()
>> else
>> KSR.info("UAC NOT authed, no relay")
>> end
>> exit
>> end
>>
>> Also the AVP values are set (I believe) correctly:
>>
>> modparam("uac", "auth_username_avp", "$avp(auser)")
>> modparam("uac", "auth_password_avp", "$avp(apass)")
>> modparam("uac", "auth_realm_avp", "$avp(arealm)")
>>
>> This throws the following complaint, and doesn’t send a new response
>> back to the trunk:
>>
>> Apr  5 02:55:22 ip-10-0-0-2 /usr/local/sbin/kamailio[26870]: ERROR:
>> {1 102 INVITE 3a84da15272da66e527a79144c48516c at 10.0.0.20
>> <mailto:3a84da15272da66e527a79144c48516c at 10.0.0.20>:5060} tm
>> [t_fwd.c:1728]: t_forward_nonack(): no branches for forwarding
>> Apr  5 02:55:22 ip-10-0-0-2 /usr/local/sbin/kamailio[26870]: ERROR:
>> {1 102 INVITE 3a84da15272da66e527a79144c48516c at 10.0.0.20
>> <mailto:3a84da15272da66e527a79144c48516c at 10.0.0.20>:5060} tm
>> [tm.c:1619]: _w_t_relay_to(): t_forward_noack failed
>>
>> I don’t understand branches very well, however after some digging
>> around, I appended KSR::COREX.append_branch() in before the t_relay()
>> in the failure. This stops the error and now we send an ACK and a new
>> INVITE, but still without the expected authorisation header.
>>
>> I feel like my lack of understanding about branches is the issue here
>> - I seem to be sending an INVITE, but not adding the auth header that
>> I suspect is being generated somewhere!
>>
>> Thanks for your help.
>>
>> ________________________________
>>
>> Andrew White - Director
>> uConnected
>> Email: andrew at uconnected.com.au <mailto:andrew at uconnected.com.au>
>> Web: www.uConnected.com.au <http://www.uConnected.com.au>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190405/7d86d973/attachment.html>