As soon as your endpoints – codecs and Cisco Jabber client – are registered to CUCM and ready to dial each other URIs it’s time to try dialling to an external URI,
that is outside our enterprise. External URIs could be one of the following types:
1) a normal SIP URI in a form of info@example.com where example.com domain has appropriate SRV records (_sip._udp SRV 0 5060 host.example.com. for example for SIP over UDP)
2) a SIP URI in a form of info@1.2.3.4 with an IP address in place of the domain
3) an IP address – usually guys with Polycom systems use it along with H323 protocol.
4) exotic URIs like 1.2.3.4##12345 used also by some Polycom systems – they usually can be accesses by a standard URI of 12345@1.2.3.4 or by IP 1.2.3.4
If you have only CUCM in your network you can dial only type 1 and 2. For that case you can create a SIP Route Pattern with domain routing for type1 and with IP routing with type2. I can’t definitely say why CUCM has there two flavours of SIP route patterns – my guess is that IP address notation of 192.168.0.1 can bee seen by CUCM as a domain with 4 levels and it tries an SRV lookup (for _sip._udp.192.168.0.1) instead just using this IP address for network layer.
In order to cover all possible destinations – all types of URIs and both signalling protocols – it’s better to have an Collaboration Edge servers installed. They come in two versions: VCS-E/C which supports registrations of endpoints and
Expressway-E/C which relays endpoint registrations to CUCM in case of MRA.
So, first you need a SIP route pattern *.* with domain routing in CUCM pointing to a SIP trunk (a Route list in my case as I have a clustered pair of Expressway and two SIP trunks).
According to this document http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X8-2/Mobile-Remote-Access-via-Expressway-Deployment-Guide-X8-2.pdf on page 30 you have to have a new SIP Trunk Security Profile with non-standard SIP listening port for Expressway-CUCM integration to work.
This route pattern easily covers type 1 URIs. In order to dial type 2 URIs you should add a separate SIP route pattern with IP routing and specify exact IP address (and I don’t know the way to make it more flexible now).
To cover type 3 URI we will convert IP addresses to URIs with some user training and special search rules on Collaboration Edge servers.
On Expressway-C I’ve created a separate from automatically created MRA zones neighbour zone toward CUCM.
And configured a search rule for URI dialing. When a requests is received from CUCM Expressway-C just sends it to Traversal zone (and my traversal zone is SIP only). That shoud cover type 1 URIs
For dialing by IP (type 3) IP I’ve found a post http://www.ucguerrilla.com/2014/02/cisco-telepresence-endpoints-and-ip.html which suggested a using special type of URI for that.
You should instruct your users to dial 192.168.0.100@ip.local to reach external endpoint 192.168.0.100 – this effectively converts pure IP dialling to standard URI dialling.
When the request with 192.168.0.100@ip.local reaches Expressway-C the transform would convert it to IP address
Then for type 2 and type 3 (converted to IP address by transform) URIs there is a separate Search rule:
Moreover under Configuration -> Dial plan -> Configuration Calls to unknown IP addresses should be set to Indirect on Expressway-C for it to work.
On Internet facing Expressway-E acting as traversal server I set up a DNS zone and a search rule with pretty standard configuration.
It will deal with type 1 URIs making DNS SRV and even DNS A/AAAA lookups for H323 and SIP.
But in order to support both SIP and H32 you should have H323-SIP Interworking Gateway option key installed, and SIP-H323 interworking turned on under Configuration -> Protocols -> interworking. And you don’t need a DNS zone for IP dialling (both type 2 and type 3) as it will be covered by option Configuration -> Dial plan -> Configuration Calls to unknown IP addresses set to direct.
smirnov-am's tech blog 