1.5.1. loose_route()
The function performs routing of SIP requests which contain a route set. The name is a little bit confusing, as this function also routes requests which are in the “strict router” format.
This function is usually used to route in-dialog requests (like ACK, BYE, reINVITE). Nevertheless also out-of-dialog requests can have a “pre-loaded route set” and my be routed with loose_route. It also takes care of translating between strict-routers and loose-router.
The loose_route function analyzes the Route: headers in the requests. If there is no Route: header, the function returns FALSE and routing should be done with normal lookup functions. If a Route: header is found, the function returns 1 and behaves as described in section 16.12 of RFC 3261. There is only one exception: If the request is out-of-dialog (no to-tag) and there is only one Route: header indicating the local proxy, then the Route: header is removed and the function returns FALSE.
Make sure your loose_routing function can't be used by attackers to bypass proxy authorization.
The loose_routing topic is very complex. See the RFC3261 for more details (grep for “route set” is a good starting point in this comprehensive RFC).
This function can be used from REQUEST_ROUTE. Example 1.6. loose_route usage
...
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. Example 1.7. record_route usage ...
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.
Example 1.8. record_route_preset usage ...
record_route_preset(\...
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, “ record_route() and record_route(string) ”).
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.
Example 1.9. add_rr_param usage ...
add_rr_param(\...
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, “ loose_route() ”). 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. Example 1.10. check_route_param usage ...
if (check_route_param(\ 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, “append_fromtag (integer)” module parameter must be enabled. Also this must be called only after loose_route() (see Section 1.5.1, “ loose_route() ”).
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. Example 1.11. is_direction usage ...
if (is_direction(\ xdbg(\} ...