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: [email protected] <mailto:[email protected]> > Web: www.uConnected.com.au <http://www.uConnected.com.au> > >> On 5 Apr 2019, at 2:07 pm, Andrew White <[email protected] >> <mailto:[email protected]>> 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 [email protected] >> <mailto:[email protected]>: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 [email protected] >> <mailto:[email protected]>: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: [email protected] <mailto:[email protected]> >> Web: www.uConnected.com.au <http://www.uConnected.com.au> > > > _______________________________________________ > Kamailio (SER) - Users Mailing List > [email protected] > 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
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
