HowTo: Support dialing IP addresses from Cisco TelePresence endpoints registered to CUCM to reach external H.323 video endpoints
Information here is a
compilation of that found in”Cisco
Unified Communications Manager with Cisco VCS (SIP Trunk)Deployment Guide”,
various http://supportforums.cisco.com discussions and a most excellent http://www.ucguerrilla.com post. Note William Bell is the brain behind the ip@ prefix and what follows is my personal interpretation and experience in the wild.Screen shots are actual client configurations in production as of
4/2/2015.
Call flow was tested
via a Cisco MX200 TelePresence endpoint registered to CUCM 9.1.2. Calls to
external H.323 video endpoints dialed via IP address were sent from CUCM to
Expressway 8.5.1 C and E, already providing B2B video calling via SIP URIs.
External auto-answering H.323 and SIP video endpoints were called for testing
purposes without permission and those IP addresses are not included here.
Background:
Video calling between endpoints registered to CUCM
internally and B2B via Expressway was already in production. Users were accustomed to dialing via SIP URI,
like joe.smith@mycompany.net or john.smith@anothercompany.com.
Previously, B2B H.323 video calls were made from Polycom
endpoints by dialing public IP addresses. As these older existing Polycom video
endpoints were retired and replaced by Cisco video endpoints registered to
CUCM, the ability to continue to dial external H.323 devices by IP address was required.
Issues:
Although the process of physically dialing IP addresses from
Cisco TelePresence Touch (or other) interfaces is no more difficult than
dialing SIP URIs, at this time CUCM does not support simply dialing IP
addresses.
Cisco’s VCS deployment guide suggests the solution is to
define a dialing access code specific to video calls, for example the digit 8.
Then you are to instruct the users to dial 8 plus a string of twelve digits to
represent the IP address they want to call, where leading zeros are to be added
to each octet where necessary and the dots ignored. For example, users accustomed to dialing
10.100.1.10 on a Polycom would now be required to convert the IP address and
dial 8010100001010 from the new Cisco video endpoints. This is not an acceptable solution.
Solution:
Configure CUCM and Expressway C and E to support dialing IP
addresses using the format ip@. For clarity, where a user would previously
dial 10.100.1.10 from a Polycom device, they would now dial ip@10.100.1.10 from
the Cisco device. The ip@ are literal
characters to be dialed prefacing the IP address, but otherwise the IP address
portion itself continues to look like and be dialed like an IP address.
Simply:
- CUCM will accept a call dialed with a SIP URI format like ip@10.100.1.10 and route it to Expressway C.
- Expressway C will accept the call in the ip@10.100.1.10:5060 format (or ip@10.100.1.10:5061), strip the ip@ and :5060 portions of the number and pass the remaining portion of the address, now looking like an IP address, to Expressway E.
- Expressway E will not attempt a DNS lookup on the address and will support SIP to H.323 conversions.
Configuration steps:
CUCM:
Navigate to Call
Routing | SIP Route Pattern and add a route pattern that matches your
destination video device IP address.
Verify the pattern is for IPAddress
Routing and note the address can either be an exact match, or reflect a
network address in the X.X.X.X/Y format.
The Sip Trunk / Route List
should reflect a SIP trunk between CUCM and Expressway C.
This is how calls placed from a CUCM registered endpoint to
a SIP URI with an IP address rather than domain name (i.e. ip@10.100.1.10) are
routed to Expressway C.
An example of a specific IP address being routed to a SIP
trunk called ExpresswayCore-SIP-Trunk
is below. This was used for initial
testing purposes. Do NOT use this IP address for your own tests.
Again, rather than creating a SIP Route Pattern for every public endpoint you need to contact,
you can add addresses in the X.X.X.X/Y IP address and subnet mask format. Unfortunately CUCM does not accept 0.0.0.0 as
an IP address. This means a single entry
similar to an IP default route found in other Cisco IOS based devices doesn’t
seem possible. One work around is
dividing the entire IPv4 space into two subnets, 1.0.0.0/1 and
128.0.0.1/1. It is working successfully
at this time.
Expressway C:
Navigate to Configuration
| Dial Plan | Transforms and add a new transformation. The type needs to be RegEx, the pattern string ip@(.*)(:506[01]) and the replace
string \1.
Via the RegEx replacement, this transform is responsible for
replacing the SIP URI presented by CUCM (i.e. ip@10.100.1.10:5060) with a
string resembling simply an IP address (i.e. 10.100.1.10).
Below is the actual configured transform. It is important to set the priority number so
that it does not break any other calling.
Here the transform worked safely with the highest priority value (last
to be matched).
Navigate to Configuration|
Dial Plan | Search Rule, and add a rule with a Mode that matches Any IP
Address. The target should be a
Traversal Zone that passes the call to Expressway E. This how the string that now looks like an IP
address (i.e. 10.100.1.10) gets routed to Expressway E.
Below is the actual search rule added, targeting a Traversal
Zone called Traversal B2B that was
already supporting B2B video calling vial SIP URIs.
Navigate to Configuration
| Dial Plan | Configuration and verify Calls
to unknown IP addresses are set to Indirect. I don’t have a picture here, but it is the
only option on the page and will likely not need to be changed.
Expressway E:
Navigate to Configuration
| Dial Plan | Configuration and verify Calls
to unknown IP addresses are set to Direct.
This routes calls to IP addresses directly to the
destination on the Internet without attempting DNS lookups.
Navigate to Configuration
| Protocols and verify both SIP and H.323 protocols are enabled. These are two basic settings required to
support SIP calls from CUCM / Expressway C and H.323 calls to external
endpoints.
Navigate to Configuration
| Protocols | Interworking and enable SIP to H.323 internetworking. I don’t
have a picture here but it is again the only option on the page and is likely
default. This provides support for your
call being generated by a Cisco SIP based TelePresence endpoint to communicate
with the target H.323 endpoint.
Notes
- On Cisco Telepresence endpoints, users will need to be instructed to dial ip@ in front of the IP address the intend to call.
- The event logs in Expressway C and E are relatively easy to use and decipher. If B2B video calling is in production, once you add your CUCM SIP Route Pattern, look to the Expressway C and then E for troubleshooting.
Log Example 1: Here is Expressway C rejecting a call from a device at 7902@mycompany.net, my test MX200 registered to the CUCM at 10.181.1.8. The destination IP address is 76.74.100.40. The 404 response code was a result of the Expressway C missing the search rule designed to route IP addresses to Expressway E via the Traversal Zone.
Log Example 2: Here is Expressway C reporting a 480 response
to an attempt to reach 66.135.98.168. The lesson here is when making test calls to
endpoints by IP address, first verify the IP address in question actually
points to a working video endpoint. This one didn’t.
Log
Example 3: Here is Expressway E reporting the destination 76.74.100.40 can’t be
found. This indicates the call has made
it all the way from the CUCM endpoint, to CUCM, to Expressway C and to
Expressway E and looks like an IP address.
We know this is a working endpoint though. The issue was the Calls to unknown IP addresses value was not set to Direct.
