2 Jul
2010
2 Jul
'10
10:36 a.m.
On 07/02/2010 03:22 AM, "Ján ONDREJ (SAL)" wrote:
I use defaults, so looks like I use automatic restore.
I don't know, how to
send it manually, so auto looks to be a good choice. uac_restore_from can't
be used from reply route.
If you are using the "auto" restore mode, it is not necessary to call
uac_restore_from().
Looks like uac_auth() does not send another request.
Can somebody give me a
more complete example, how to use uac_auth()? Do I need to use uac_req_send
or call some route to do it? May be it is my problem, because second INVITE
is not sent.
The uac_auth() function is intended to be called from a failure route
when catching a 407 Proxy Authorization Required challenge.
You will need to use serial forking ("branching") to re-send the
request with the appropriate digest authentication headers:
I would use it like this:
route {
...
t_on_failure("MAYBE_AUTH_CHALLENGE");
if(!t_relay())
sl_reply_error();
}
...
failure_route[MAYBE_AUTH_CHALLENGE] {
if(t_is_canceled())
exit;
if(t_check_status("407")) {
append_branch();
if(!uac_auth()) {
xlog("L_ERR", "Something went wrong with
uac_auth()!\n");
t_reply("500", "Internal Server Error");
return;
}
if(!t_relay()) {
t_reply("500", "Internal Server Error");
return;
}
}
Keep in mind that uac_auth() will silently fail to add the right
headers, without explanation, if the realm you provide it (whether by
AVP or via the "credential" modparam to 'uac') does not match the
realm requested in the challenge from the provider, but you won't know
that unless you turn up debug verbosity.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/