I have recently come across scenarios which involve the registration of video endpoints (C Series) to CUCM for call control, and use Expressway-Core/Expressway-Edge for MRA and off-net URI dialing using the Rich Media Session Licenses.
Every instance in my case have all had the requirement to dial an IP address from the endpoint, this could be an internal endpoint that can't register to CUCM or a gatekeeper, or to dial a public IP address on the internet.
After doing some research on why this was not working, it appears that IP address dialing from CUCM isn't supported and therefore there are a number of unofficial workarounds to get this working using VCS to digit manipulate the dialed alias.
For the requirement of dialing internal endpoints via IP address, i wanted to create a SIP Route Pattern in CUCM to match IP@<X.X.X.X> "X.X.X.X" being the internal video endpoints IP address.
I switched over to the Expressway-Core to finish the config as i thought i could use a translation pattern to remove the IP@ and resolve the call against an anyIP to LocalZone search-rule, only to find that i can't actually create a search rule that matches against a LocalZone because the LocalZone isn't available to use.
I presume this is because it's not what the Expressway-Core is designed for, does anyone have any other ideas? Or is this method of dialing for customers that have made the decision to register endpoints to CUCM and have Expressway-Core/Edge (not VCS) not going to be possible?
You are correct in regards to not being able to Register Endpoints to the Expressway Series therefore you cannot search LocalZone. With the VCS series you would have this ability as it is a SIP/H.323 Gateway & Registrar and could setup Zones for certain subnets and have it search said zones.
You could install VCS Control in a VM, the base install allows you to register 3 devices along with 1 Traversal Call. You would setup another SIP trunk to this VCSC to communicate between those Internal IP Endpoints and CUCM.
As for External IP Dialing - I deployed this recently. You are on the right track with ip@%ipaddress% as a SIP Route Pattern on CUCM. Cisco's suggested workaround for it would be using a XXX*XXX*XXX*XXX SIP Route Pattern but no End User is going to understand this dialing string and setting up Favorites would be time consuming. a few things here to make it work properly from CUCM:
- you need to create a new SIP Trunk to the Expressway Core with new SIP Profile (with sip early offer enabled) and a new SIP Trunk Sec Profile with a different incoming SIP port.
- Point the IP SIP Route to the new SIP Trunk
- create a transform on the Exp Core to strip the IP@ off the dial string (this should then match an IP Dialing search rule - create one if you don't already have one that points to Exp Edge)
the big issue is Sip Early Offer, if you don't have that configured CUCM doesn't send the SIP Call Capabilities therefore the Expressway leaves them blank. This causes a call to setup and Media to go outbound but then the remote endpoint doesn't know where to send the Media back to.
Hope this helps,
Were you able to get IP dialing from C series registered to CUCM via Expressway?
I am trying this with a customer of ours with a recommended SIP route pattern from Cisco (X.X.X.X@vcs.domain). I then have a transform setup on the EXPc to remove the @vcs.domain which then sends it across the traversal zone to EXPe. I see the search history trying sip:X.X.X.X but it can never locate the far end.
If I use the locate tool on the EXPe with H323 it can locate the far end IP, but this never completes with SIP.
Testing on our own VCS, if I try the locate tool with SIP it will fail over to H323. Is there any reason this should not work on the customer EXPe?
Also, with the SIP route pattern you are using, is it acutally "IP@X.X.X.X"?
Any help appreciated.
I managed to get IP address dialing working by configuring two SIP route patterns as IP address patterns, not domain patterns:
Pattern 1: 22.214.171.124/1
Pattern 2: 126.96.36.199/1
These patterns basically catch anything @ any IP address, i tend to encourage the end user to use a dialed alias as IP@1.X.X.X for example and then strip the IP@ from the alias on the VCS-Control.
It looks like the domain routing you have configured should be find but you need to look at the general functionality of your firewall traversal setup. Couple of things i would check for:
The previous support guys had these IP addresses configured, but I could nit see these working. I get calls going out now, but only one way. THe far end receives audio and video, but no return. I have tried setting early offer on the SIP trunk profile but still no joy.
I am waiting to test on a new trunk and profile.
When using the IP patterns mentioned, does the call just need to enter the IP address? If the need to dial 188.8.131.52 is that all they need? What transforms do I need on the EXPc if this is used?
Thanks for your help
So the fault description you are giving here points to the Expressway-Edge, i wouldn't focus so much on the CUCM side because you have managed to get the call working.
You need to check all inbound SIP ports to expressway-edge are open as per the latest Cisco documentation/deployment guide (if you can i would trace the outside firewall to see if anything is being blocked).
You also need to look at how you have set up your expressway-edge, if its not ports being blocked causing the one-way traffic it could potentially be NAT, there are a number of expressway-edge deployment scenarios:
http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/admin_guide/Cisco-Expressway-Administrator-Guide-X8-5-1.pdf (Page 23)
I've come in quite late on this one so don't know the history of it.
They are only using 1 LAN interface on the EXPe with the NAT feature enabled to the outside address.
The oubound IP call uses H323, so could this be H323 related ports and not SIP that being denied?
The NATing outbound is seamingly working as the SIP calls are ok.
You need to reference the Expressway-E deployment guide, the method you have mentioned (using a single interface using static NAT) would mean that you would have to peer your Expressway-Core with the public IP address of your Expressway-Edge - So your traffic would actually route outside of the network to come back in.
The reason why you have these NAT issues with video is because video traffic embeds the destination address within the data payload of a packet, which is why the advanced networking is required to change this to present as the Expressway-E's public IP.
Hope that makes sense.
The EXPc uses the DNS name of the EXPe in its traversal zone. This resolves to the External IP (public IP) of the EXPe. The traversal zone is up. SIP calls work fine, 2 way audio and video. Its just when we try Calls to unknown IP address from the EXPe that it then uses H323 (as expected). The call then has one way media.
This makes me think that the NATing is correct and that its something specific to H323? Or do you think that I need to activate the Advanced Networking (Dual NIC)?
Can you solve the issue? I have the same issue on my system...exactly same, only fails when dial to public ip address:
Nevertheless, when call come from internet to internal codec, works well.