Cisco Cisco TelePresence Video Communication Server Expressway
Routing configuration
Cisco VCS Deployment Guide: Basic configuration – VCS Control with VCS Expressway
Page 18 of 69
Routing configuration
Pre-search transforms
Pre-search transform configuration allows the destination alias (called address) in an incoming search
request to be modified. The transformation is applied by the VCS before any searches take place, either
locally or to external zones.
request to be modified. The transformation is applied by the VCS before any searches take place, either
locally or to external zones.
The pre-search transform configuration described in this document is used to standardize destination aliases
originating from both H.323 and SIP devices.
originating from both H.323 and SIP devices.
For example, if the called address is an H.323 E164 alias “01234” the VCS will automatically append the
configured domain name (in this case example.com) to the called address (that is, 01234@example.com
making it into a URI), before attempting to set up the call.
configured domain name (in this case example.com) to the called address (that is, 01234@example.com
making it into a URI), before attempting to set up the call.
This is carried out to make the call searches the same for calls from H.323 endpoints and SIP endpoints.
n
Pre-search transforms should be used with care because they apply to all signaling messages – if they
match, they will affect the routing of provisioning and presence requests as well as call requests.
match, they will affect the routing of provisioning and presence requests as well as call requests.
n
Transformations can also be carried out in search rules – consider whether it is best to use a pre-search
transform or a search rule to modify the called address to be looked up.
transform or a search rule to modify the called address to be looked up.
Search rules
The search rules configuration defines how the VCS routes calls (to destination zones) in specific call
scenarios. When a search rule is matched, the destination alias can be modified according to the conditions
defined in the search rule.
scenarios. When a search rule is matched, the destination alias can be modified according to the conditions
defined in the search rule.
The search rules configuration described in this document is used to ensure SIP (and H.323) endpoints can
dial H.323 devices that have registered e164 numbers or H.323 IDs without a domain portion. The search
rules first search for received destination aliases without the domain portion of the URI, and then searching
with the full URI.
dial H.323 devices that have registered e164 numbers or H.323 IDs without a domain portion. The search
rules first search for received destination aliases without the domain portion of the URI, and then searching
with the full URI.
The search rules described here are used to enable the following routing combinations:
Calling party
Called party
Registered devices (VCS Control or Expressway)
Registered devices (VCS Control or Expressway)
Registered devices (VCS Control or Expressway)
External domains and un-registered devices (via VCS
Expressway using DNS zone)
Expressway using DNS zone)
Registered devices (VCS Control or Expressway)
Public external IP addresses (via VCS Expressway)
External domains and un-registered devices
Registered devices (VCS Control or Expressway)
The routing configuration in this document searches for destination aliases that have valid SIP URIs (that is,
using a valid SIP domain, such as id@domain).
using a valid SIP domain, such as id@domain).
It is possible to configure routing which enables calls to unregistered devices on an internal network (routing
to the addresses of IP of the devices) by configuring a search rule with mode of Any IP address with target
Local Zone. However this is not recommended (and not described in this document). The best practice is to
register all devices and route using destination aliases.
to the addresses of IP of the devices) by configuring a search rule with mode of Any IP address with target
Local Zone. However this is not recommended (and not described in this document). The best practice is to
register all devices and route using destination aliases.