1.3.1. OpenSER Modules

The following modules must be loaded before this module:

• No dependencies on other OpenSER modules.

1.3.2. External Libraries or Applications

The following libraries or applications must be installed before running OpenSER with this module loaded:

• None.

1.4.1. enable_full_lr (integer)

If set to 1 then ";lr=on" instead of just ";lr" will be used. This is to overcome problems with broken UAs which strip ";lr" parameter when generating Route header fields from Record-Route (";lr=on" seems to help).

Default value is 0 (no).

...
modparam("rr", "enable_full_lr", 1)
...

1.4.2. append_fromtag (integer)

If turned on, request's from-tag is appended to record-route; that's useful for understanding whether subsequent requests (such as BYE) come from caller (route's from-tag==BYE's from-tag) or callee (route's from-tag==BYE's to-tag)

Default value is 1 (yes).

...
modparam("rr", "append_fromtag", 0)
...

1.4.3. enable_double_rr (integer)

There are some situations when the server needs to insert two Record-Route header fields instead of one. For example when using two disconnected networks or doing cross-protocol forwarding from UDP->TCP. This parameter enables inserting of 2 Record-Routes. The server will later remove both of them.

Default value is 1 (yes).

...
modparam("rr", "enable_double_rr", 0)
...

1.4.4. add_username (integer)

If set to a non 0 value (which means yes), the username part will be also added in the Record-Route URI.

Default value is 0 (no).

...
modparam("rr", "add_username", 1)
...

1.5.1. loose_route()

The function performs loose routing as defined in RFC3261. See the RFC3261 for more details.

This function can be used from REQUEST_ROUTE.

...
loose_route();
...

1.5.2. record_route() and record_route(string)

The function adds a new Record-Route header field. The header field will be inserted in the message before any other Record-Route header fields.

If any string is passed as parameter, it will be appended as URI parameter to the Record-Route header. The string must follow the ";name=value" scheme and it may contain pseudo-variables.

This function can be used from REQUEST_ROUTE, BRANCH_ROUTE and FAILURE_ROUTE.

...
record_route();
...

1.5.3. record_route_preset(string)

This function will put the string into Record-Route, don't use unless you know what you are doing.

Meaning of the parameters is as follows:

• string - String to be inserted into the header field; it may contain pseudo-variables.

This function can be used from REQUEST_ROUTE, BRANCH_ROUTE and FAILURE_ROUTE.

...
record_route_preset("1.2.3.4:5090");
...

1.5.4. add_rr_param(param)

Adds a parameter to the Record-Route URI (param must be in ";name=value" format. The function may be called also before or after the record_route() call (see Section 1.5.2).

Meaning of the parameters is as follows:

• param - String containing the URI parameter to be added. It must follow the ";name=value" scheme; it may contain pseudo-variables.

This function can be used from REQUEST_ROUTE, BRANCH_ROUTE and FAILURE_ROUTE.

...
add_rr_param(";nat=yes");
...

1.5.5. check_route_param(re)

The function checks if the URI parameters of the local Route header (corresponding to the local server) matches the given regular expression. It must be call after loose_route() (see Section 1.5.1).

Meaning of the parameters is as follows:

• re - regular expression to check against the Route URI parameters.

This function can be used from REQUEST_ROUTE.

...
if (check_route_param("nat=yes")) {
    setflag(6);
}
...

1.5.6. is_direction(dir)

The function checks the flow direction of the request. As for checking it's used the "ftag" Route header parameter, the append_fromtag (see Section 1.4.2 module parameter must be enables. Also this must be call only after loose_route() (see Section 1.5.1).

The function returns true if the "dir" is the same with the request's flow direction.

The "downstream" (UAC to UAS) direction is relative to the initial request that created the dialog.

Meaning of the parameters is as follows:

• dir - string containing the direction to be checked. It may be "upstream" (from UAS to UAC) or "downstream" (UAC to UAS).

This function can be used from REQUEST_ROUTE.

...
if (is_direction("upstream")) {
    xdbg("upstream request ($rm)\n");
}
...

2.1.1. add_rr_param( msg, param)

Adds a parameter to the requests's Record-Route URI (param must be in ";name=value" format).

The function returns 0 on success. Otherwise, -1 is returned.

Meaning of the parameters is as follows:

• struct sip_msg* msg - request that will has the parameter "param" added to its Record-Route header.

• str* param - parameter to be added to the Record-Route header - it must be in ";name=value" format.

2.1.2. check_route_param( msg, re)

The function checks for the request "msg" if the URI parameters of the local Route header (corresponding to the local server) matches the given regular expression "re". It must be call after the loose_route was done.

The function returns 0 on success. Otherwise, -1 is returned.

Meaning of the parameters is as follows:

• struct sip_msg* msg - request that will has the Route header parameters checked.

• regex_t* param - compiled regular expression to be checked against the Route header parameters.

2.1.3. is_direction( msg, dir)

The function checks the flow direction of the request "msg". As for checking it's used the "ftag" Route header parameter, the append_fromtag (see Section 1.4.2 module parameter must be enables. Also this must be call only after the loose_route is done.

The function returns 0 if the "dir" is the same with the request's flow direction. Otherwise, -1 is returned.

Meaning of the parameters is as follows:

• struct sip_msg* msg - request that will have the direction checked.

• int dir - direction to be checked against. It may be "RR_FLOW_UPSTREAM" or "RR_FLOW_DOWNSTREAM".

2.1.4. get_route_param( msg, name, val)

The function search in to the "msg"'s Route header parameters the parameter called "name" and returns its value into "val". It must be call only after the loose_route is done.

The function returns 0 if parameter was found (even if it has no value). Otherwise, -1 is returned.

Meaning of the parameters is as follows:

• struct sip_msg* msg - request that will have the Route header parameter searched.

• str *name - contains the Route header parameter to be serached.

• str *val - returns the value of the searched Route header parameter if found. It might be empty string if the parameter had no value.

2.1.5. register_rrcb( callback, param)

The function register a new callback (along with its parameter). The callback will be called when a loose route will be performed for the local address.

The function returns 0 on success. Otherwise, -1 is returned.

Meaning of the parameters is as follows:

• rr_cb_t callback - callback function to be registered.

• void *param - parameter to be passed to the callback function.

2.1.6. Examples

...
#include "../rr/api.h"
...
struct rr_binds my_rrb;
...
...
/* load the RR API */
if (load_rr_api( & my_rrb )!=0) {
    LOG(L_ERR, "ERROR: can't load RR API\n");
    goto error;
}
...
...
/* register a RR callback */
if (my_rrb.register_rrcb(my_callback,0))!=0) {
    LOG(L_ERR, "ERROR: can't register RR callback\n");
    goto error;
}
...