Defining routing rules

Define the conditions under which a SIP trunking telephone call is routed to a particular SIP endpoint in the IBM® Sametime® deployment.

About this task

Routing rules tell IBM Sametime where to direct calls under certain conditions. The rule consists of one or more conditions, and a destination (SIP endpoint) where call requests that meet the conditions will be routed.

Note: Some of the fields used to define routing rules must be formatted as regular expressions.
Defining routing conditions

A routing rule must include at least one condition; if it includes multiple conditions, the SIP call request must satisfy all of them to be matched to the associated route. As soon as a match is found, Sametime stops checking other conditions and routes the call; however, you can configure multiple routes with a different condition for each and then prioritize them. The routing rule can include conditions in any or all of the SIP request fields described in the table:

Table 1. Conditions fields and descriptions
Field Description
Method A predefined value indicating the type of request: INVITE, INFO, MESSAGE, or ANY. Select the appropriate value from the field's list; if you do not select a method, then all methods are accepted by this condition.
Source Address The originating caller's IP address, which must match the pattern specified in the regular expression that you provide. You could specify a single IP address:9\.3\.186\.215 or use an expression to specify a range of IP addresses: 9\.3\.186\.215|9\.3\.186\.216 (Notice that the . (dot) is preceded with the escape character \ (backslash) so it can be interpreted as a period (dot) and not the "any character" symbol.)
Request URI The resource, usually the origin server, on which to apply the request. The URI must match the pattern specified in the regular expression that you provide. For example: .*example\.com.* matches both of these incoming initial requests : sip:example.com:5060;transport=tcp SIP/2.0 and sips:subdomain.example.com:5061 SIP/2.0
Contact Header The SIP URI of the originating caller. The URI must match the pattern specified in the regular expression that you provide. For example, .*20100@192\.192\.0\.2\.12:506<01>.* matches incoming initial requests with either of these contact header values: <sip:20110@192.0.2.12:5060;transport=tcp> or <sips:user9920100@192.0.2.12:5061;transport=tcp>

Defining routing destinations

The routing destination is the SIP endpoint where the call will be directed. For incoming calls, the destination is the Sametime Media Manager's SIP Proxy/Registrar component. For outgoing calls, the destination is the third-party SIP endpoint. Specify a call's destination by constructing its address. There are two ways to construct the destination address: by pushing address information into one of the route's header fields, or by replacing the original request URI with the destination address.

Push a Route header field

Pushing a Route header field lets you define the destination address using fields in the outgoing call request's Route header as described in the table:

Table 2. SIP URI addressing fields and descriptions
Field Description
Scheme The scheme can be either SIP or SIPS (the secure version of SIP); the default is SIP. This field is required.
IP/FQDN The IP address or fully qualified host name of the destination server (the SIP endpoint). For incoming calls, use the fully qualified domain name of the Sametime Media Manager's Conference Manager component. This field is required.
Port The port that the destination server (the SIP endpoint) is listening on for SIP-based communications. For incoming calls, use the port that the Sametime Media Manager's Conference Manager component is listening for SIP communications (typically port 5063 for unsecured communications and port 5062 for secure communications). This field is optional; if you do not provide a value, the server uses the correct port.
Transport The network transport protocol to use for sending SIP messages: TCP or TLS over TCP (UDP is not supported). Use the same transport protocol throughout the entire route (from the Sametime client to the SIP Proxy/Registrar to the third-party SIP endpoint). For example, if the Media Manager is configured to use TLS for SIP communications, you must use TLS for all routes. This field is optional. If you do not provide a value, the server supplies a transport protocol.

Replace a Request-URI

Replacing the Request URI lets you substitute the destination address for the original Request URI in the outgoing call request. Supply values for the Request-URI pattern and Output pattern to create a destination address formed by a regular expression.

Table 3. URI pattern fields and descriptions
Field Description
Request-URI pattern A regular expression defining the pattern of the original Request URI. Use this field to extract fields or parameters from a Request-URI of a SIP request. A variable stores the part of the Request-URI matched by the part of the regular expression inside the parentheses, indicated by a number. The variables are recalled with the dollar-sign, for example, $1, $2, and so on. These fields or parameters can be used to build the Output pattern. This field is optional.
Output pattern A regular expression defining the pattern of the destination's URI (address). This field can contain either a SIP URI or a replacement expression with variables for example, $1, $2, and so on. Variables store the portion of a parenthesized pattern captured from the Request-URI pattern field. After processing any captured variables, the resulting field value must be a valid SIP or SIPS URI.
Note: If you do not provide a value in the Request-URI pattern field , this field must contain a valid SIP or SIPS URI.

The following examples show different combinations of values for Request-URI pattern and Output pattern that produce specific destination addresses.

  • Route all incoming SIP requests to this destination: sip:example.com;transport=tcp

    Request-URI pattern: empty

    Output pattern: sip:example.com;transport=tcp

    Because the Request-URI pattern field is empty, the destination is modified on all incoming requests.

  • Route incoming SIP requests to a new host, keeping the original user name

    Request-URI pattern: sip:(.+)@.*

    Output pattern: sip:$1@example.com

    The variable $1 in the Output pattern refers to the first submatch in the Request-URI pattern, which is the first match enclosed in parentheses (in this example, the user name). In this example, the $1 will match the .+ portion of the Request-URI pattern.

    For example, assume an incoming initial SIP request with a Request-URI of sip:12345@company.com. The Request-URI pattern runs, resulting in the variable $1=12345. The SIP URI for the destination address maintains the same user name, but adds a new host name: sip:12345@example.com.

  • Route incoming SIP requests to "host," keeping the original user name if the user-name prefix in the Request-URI is "45"

    Request-URI pattern: sip:(45.+)@.*

    Output pattern: sip:$1@host

  • Route incoming SIP requests to "host," omitting the prefix if the user name prefix in the Request-URI is "45"

    Request-URI pattern: sip:45(.+)@.*

    Output pattern: sip:$1@host