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@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@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@uconnected.com.au Web: www.uConnected.com.au
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 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@uconnected.com.au mailto:andrew@uconnected.com.au Web: www.uConnected.com.au http://www.uconnected.com.au/
On 5 Apr 2019, at 2:07 pm, Andrew White andrew@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@ 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@10.0.0.20 mailto:3a84da15272da66e527a79144c48516c@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@10.0.0.20 mailto:3a84da15272da66e527a79144c48516c@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@uconnected.com.au mailto:andrew@uconnected.com.au Web: www.uConnected.com.au
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@uconnected.com.au mailto:andrew@uconnected.com.au Web: www.uConnected.com.au http://www.uConnected.com.au
On 5 Apr 2019, at 2:07 pm, Andrew White <andrew@uconnected.com.au mailto:andrew@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@10.0.0.20 mailto:3a84da15272da66e527a79144c48516c@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@10.0.0.20 mailto:3a84da15272da66e527a79144c48516c@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@uconnected.com.au mailto:andrew@uconnected.com.au Web: www.uConnected.com.au http://www.uConnected.com.au
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-
Andrew White -
Daniel-Constantin Mierla