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.