Table of Contents
List of Examples
restore_mode parameter
restore_passwd parameterrr_from_store_param parameterrr_to_store_param parameterforce_dialog parameteruac_replace_from/uac_replace_to usageuac_replace_from/uac_replace_to usageuac_restore_from/uac_restore_to usageuac_auth usageUAC (User Agent Client) module provides some basic UAC functionalities like FROM / TO header manipulation (anonymization) or client authentication.
If the dialog module is loaded and a dialog can be created, then the auto mode can be done more efficiently.
Known limitations in this version:
authentication does not support qop auth-int, just qop auth;
CSeq not increased during authentication - the response may be rejected.
The following modules must be loaded before this module:
TM - Transaction Module.
RR - Record-Route Module, but only if restore mode for FROM URI is set to “auto”.
UAC_AUTH - UAC Authentication Module.
Dialog Module, if “force_dialog” module parameter is enabled, or a dialog is created from the configuration script.
There are 3 mode of restoring the original headers (FROM/TO) URI:
“none” - no information about original URI is stored; restoration is not possible.
“manual” - all following replies will be restored, except for the sequential requests - these must be manually updated based on original URI.
“auto” - all sequential requests and replies will be automatically updated based on stored original URI.
This parameter is optional, it's default value being “auto”.
String password to be used to encrypt the RR storing parameter (when replacing the TO/FROM headers). If empty, no encryption will be used.
Default value of this parameter is empty.
Example 1.2. Set restore_passwd parameter
...
modparam("uac","restore_passwd","my_secret_passwd")
...
Name of Record-Route header parameter that will be used to store (encoded) the original FROM URI.
This parameter is optional, it's default value being “vsf”.
Example 1.3. Set rr_from_store_param parameter
...
modparam("uac","rr_from_store_param","my_Fparam")
...
Replace in FROM/TO header the display name and the URI part.
display and URI parameters can include pseudo-variables.
IMPORTANT: calling the function more than once per branch will lead to inconsistent changes over the request.Be sure you do the change only ONCE per branch. Note that calling the function from REQUEST ROUTE affects all the branches!, so no other change will be possible in the future. For per branch changes use BRANCH and FAILURE route.
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE and FAILURE_ROUTE.
Example 1.6. uac_replace_from/uac_replace_to usage
...
# replace both display and uri
uac_replace_from("$avp(display)","$avp(uri)");
# replace only display and do not touch uri
uac_replace_from("batman","");
# remove display and replace uri
uac_replace_from("","sip:robin@gotham.org");
# remove display and do not touch uri
uac_replace_from("","");
...
Replace in FROM/TO header the URI part without altering the display name.
URI parameter can include pseudo-variables.
This function can be used from REQUEST_ROUTE.
Example 1.7. uac_replace_from/uac_replace_to usage
...
uac_replace_from("sip:batman@gotham.org");
...
This function will check if the FROM/TO URI was modified and will use the information stored in header parameter to restore the original FROM/TO URI value.
NOTE - this function should be used only if you configured MANUAL restoring of the headers (see restore_mode param). For AUTO and NONE, there is no need to use this function.
This function can be used from REQUEST_ROUTE.
This function can be called only from failure route and will build the authentication response header and insert it into the request without sending anything. Credentials for buiding the authentication response will be taken from the list of credentials provided by the uac_auth module (static or via AVPs).
This function can be used from FAILURE_ROUTE.
2.1. | What happened with auth_username_avp, auth_realm_avp and auth_password_avp parameters |
Due some restructuring of the UAC auth modules, these parameters were moved into the "uac_auth" module. This module is now responsible for handling all the credentials (static defined or dynamically defined via AVPs). The UAC module will still see the credentials defined via the AVPs. | |
2.2. | Where can I find more about OpenSIPS? |
Take a look at http://www.opensips.org/. | |
2.3. | Where can I post a question about this module? |
First at all check if your question was already answered on one of our mailing lists:
E-mails regarding any stable OpenSIPS release should be sent to
If you want to keep the mail private, send it to
| |
2.4. | How can I report a bug? |
Please follow the guidelines provided at: https://github.com/OpenSIPS/opensips/issues. |