In an IBM®
Sametime® deployment, configure routing rules that define
inbound routes (from a third-party SIP endpoint to IBM
Sametime) and outbound routes (from Sametime to the third-party SIP endpoint) for SIP
trunking.
About this task
The SIP Proxy/Registrar component uses inbound routes
to receive call requests from third-party audio/video devices and
then direct those calls to the Conference Manager component, which
in turn routes the calls to Sametime clients. Outbound
routes direct call requests from Sametime clients to third-party
SIP endpoints, which in turn route the calls to the callee's
audio/video devices.
The process for defining inbound and outbound
routes is the same. The route consists of a rule (one or more conditions
to be met) and a destination (inbound routes target the Sametime Conference Manager
while outbound routes target the third-party SIP endpoint).
Procedure
Use the routing rules table in the Proxy Administration
page to view, create, or edit rules.
- On the Sametime System
Console, log in to the Integrated Solutions Console as the IBM WebSphere® administrator.
- In the navigation tree, click .
- On the SIP page, look in the proxies
table and click the Deployment Identifier of
the SIP Proxy/Registrar.
- On the SIP Proxies and Registrars page,
click Proxy Administration.
- In the routing rules table, do one of the following:
- Click the name of a rule to edit it.
- Click New to create a new rule.
- Add or modify settings for the routing rule as follows:
- Type a name and description of the route in the Name and Description fields.
It is helpful to indicate the route's direction and
endpoint in the name so you can easily distinguish among routes in
the routing rules table later.
- Use the "Conditions" section to configure the routing
rule by defining at least one condition:
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 . is preceded with the escape character \ so it can be interpreted
as a period 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> |
- In the "Destination" section, select the method to use
for storing the address of the destination SIP endpoint:
Table 2. Destination addressing methods and descriptions
Field |
Description |
Push a Route header field |
Insert the destination address into a Route
header field of the outgoing SIP request. |
Replace a Request-URI |
Replace the original Request-URI with the destination
address when creating the outgoing request. |
- Construct the destination address using the method you
selected in substep c.
Push a Route header field
Supply
a value in one or more of the fields described in the table.
Table 3. SIP URI addressing fields and descriptions
Field |
Value |
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 trunking. For incoming calls, use the port that the Sametime Media Manager's Conference Manager component is
listening on (the port you looked up in Determining the ports
used by the Sametime Media Manager). This field is
optional; if you do not provide a value, the server uses the correct port. Note: Make sure you
specify the correct port for the transport protocol. For unsecured TCP communications, the
Conference Manager typically uses port 5063; for encrypted TLS communications, the Conference
Manager typically uses port 5062. |
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
Construct regular expressions
to define the original Request-URI pattern and
its replacement Output pattern, which are explained
in the table.
Table 4. 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. |
Remember: Regular expressions must follow a strict
notation, different from other notation forms you may use. For example,
the operating system shell notation for a wildcard (series of 0 or
more characters) is the asterisk character: *, The regular expression
equivalent for a wildcard is different: it is a combination of a dot
followed by an asterisk, as follows: .*
Before adding the
regular expression to the routing rule, you should test the expressions
using any of the testing engines available online. To learn more about
creating regular expressions, see the Java™ Regular
Expressions class on the Oracle web site.
- Click OK to save the rule.
- Repeat from step 5 until all your routing rules have
been defined.
You must create at least one inbound route
and one outbound route between Sametime and each third-party
SIP endpoint. You can create different versions of a route using different
sets of conditions (all of a route's conditions must be satisfied
for that route to be selected), and you can prioritize routing rules
as explained in the next step.
- Prioritize the routing rules by arranging them in the sequence
in which you want them processed:
It is acceptable to
have inbound routes mixed with outbound routes in the sequence because
if a message does not satisfy all of the routing conditions, the route
will be ignored.
- In the routing rules table, select a route and click
the Move Up button or the Move Down button
until the route is positioned in the correct sequence.
- Repeat as needed until the rules appear in priority
sequence.
- Save the set of routing rules and priorities by clicking Save link
in the "Messages" box at the beginning of the page.
- Restart the SIP Proxy/Registrar's server or cluster:
- For a stand-alone Media Manager or SIP Proxy/Registrar, restart
it now as follows:
- In the server's Integrated Solutions Console, click .
- In the list of servers, select your server and click the Restart button
at the beginning of the table.
- Click the Refresh button and verify that
all components are active.
- For a cluster of SIP Proxy/Registrars, synchronize the nodes
before restarting them:
- In the Deployment Manager's Integrated Solutions Console, click .
- Select all nodes in the cluster, and then click the Full
Resynchronize button at the beginning of the table.
- Back in the navigation tree, click .
- Select all nodes in the cluster, and then click the Restart button
at the beginning of the table.
Example
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 expression
in parentheses for Request-URI pattern captures the user name in a
variable and the output pattern refers to the variable as $1
.
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
What to do next
After you have added routing rules and then restarted
servers, proceed to Configuring
a third-party SIP endpoint for Sametime calls.