I've been trying to understand how to enable URI dialing to external destinations from endpoints (SX10 and SX20), registered on CUCM 10.5 through VCS-C/E pair. So here is a couple of cases
1) I want to dial a URI of firstname.lastname@example.org from a registered SX10.
I have a SIP route pattern of * (with routing of domains) pointing to a SIP trunk, which points to VCS-C (using TCP, and 5560 port for incoming connections)
On VCS-C I have a neighbor zone named CUCM-manual to CUCM and a traversal zone to VCS-E (SIP only!)
Also I've created a search rule like that one
On VCS-E I have a DNS zone
And a Search rule
Under Configuration -> Interworking I have H323-SIP mode set to ON
So when I dial email@example.com I get through.
The question is:
How does VCS-E decide what protocol to use, provided both SIP and H323 DNS SRV records are there? How to influence this decision?
2) I want to dial a URI of firstname.lastname@example.org (188.8.131.52 is an external IP adress). All configuration stays the same and I get announcement "Call cannot be completed as dialed".
The questions are:
1) why this call is not covered by the * SIP route pattern (domain routing) ?
2) Why I have to add IP SIP route pattern of 184.108.40.206? Can I make this pattern more flexible provided a cannot summarize all destinations into Subnet/mask quatation as I don't know them in advance?
3) why are there 2 types of SIP route patterns (domain and IP routing)?
4) With IP SIP route pattern of 220.127.116.11 the call reaches VCS-E, but it doesn't fall under DNS search rule and in Search history I see
Yes, "Call cannot be completed as dialed" is a standart announcement by Media Streaming App, when, for example, your CSS lacks a partition with the destination. The problem is that I have a SIP route pattern with domain routing in my only partition.
That announcement goes away when I add SIP route pattern with IP dialing with the exact IP.
I just don't understand why there is a need for these 2 types of SIP route patterns
I have configured this in the past and the workaround I came up with was a SIP route pattern that was prefixed by IP: (you can make it whatever you want).
This route points to the SIP Trunk to VCS, there is a transform on the VCS that strips the IP: and routes the call. This is for IP:x.x.x.x only however and may not match your specific pattern. Give it a shot and see if the call at least gets to the VCS.
But I'm not trying to call by IP only (for that case I've implemented a solution described here http://www.ucguerrilla.com/2014/02/cisco-telepresence-endpoints-and-ip.html).
I'n thr ing to figure out why URI with alfanumerical domain and URI with IP address as a domain are routed differently?
Add New SIP Route Pattern
Pattern Usage=Domain Routing
Set route partition according to your dial plan
Set route list to the B2B SIP Trunk Configured for Expressway (or route list if you are using that)
Create new transform
Regex Alias Pattern Match
Try to dial 18.104.22.168@IP from an endpoint/client (or a known good IP address)
Check Search history on Expressway C. If you see the call arriving at the expressway, then the CUCM SIP Route Pattern is configured correctly.
If it does not show up in expressway C, then the CUCM SIP Route Pattern or SIP trunk is not configured correctly. In this case, try using Dialed Number Analyzer to determine why the pattern is or is not being matched.
Please post results from expressway search history and CUCM DNA.
Sorry I just reread this and forgot you were referring to IP dialing only, not SIP URI Dialing including the IP address.
In this case you could create a SIP Route Pattern for info@!*!*!*! and pass that to the VCS-C or Expresway-C B2B SIP Trunk.
At this point the VCS should route the call accordingly.
In order to force H.323 over SIP protocol:
Create a search rule that matches that matches the pattern email@example.com and make the target zone a new/secondary DNS Zone that has SIP disabled. (Make sure this rule has a higher priority than the DNS Serach rule)
Alternatively, you could make a search rule and zone on the VCS-C that matches the pattern firstname.lastname@example.org and targets a zone to the VCS-E but that has SIP disabled. (Make sure this rule has a higher priority than the DNS Serach rule)
Either way this is going to invoke interworking as all calls from CUCM to VCS are using the SIP protocol.
I have a similar challenge:
I would like to route all external domains through to my Exp-C and exclude the two internal domains i have (vc.domain.org & domain.org)
Like the Exp-C & E supports comprehensive expression usage, can CUCM allow for anything not vc.domain.org or domain.org to be routed to Exp-C ?
If your SIP domains are configured on your Expressway, you can configure your Traversal Zone search rule or DNS search rule to not allow those domains, for example:
%localdomains% will match any domain configured on the Expressway. However, if you don't have your local SIP domains configured on your Expressway, you can specify the domain in the pattern string instead of using a variable:
The protocol that gets determined and used for a call depends on calling and called endpoint. All calls from CUCM will be SIP, if the called endpoint is SIP the protocol will be SIP, however of its H323, then the call will be interworked between SIP-H323.
CUCM doesn't support IP address dialing, even with an alias prefix, however you can implement a workaround using your VCS, see the below tech note on how to do this.
To get an understanding of how external IP address routing is handled, take a look at the VCS Configuration Deployment Guide on of 30. Only URI addresses would do an SRV lookup.
Thank you, Patrick.
I've got your point. I'm using a nonroutable domain of @ip.local. for route calls to IP only.
But what is the difference between URI of email@example.com and firstname.lastname@example.org? Why are they routed differently by CUCM and VCS-E?
As for VCS-E with direct calls to unknown IP adresses why URI of email@example.com doesn't to a DNS zone and firstname.lastname@example.org does? DNS zone can be configures to make A records lookups as well...
Did you resolve your issue?
We have same problem. We have active SIP trunk between CUCM and Expressway Core but outgoing call from endpoint registered on CUCM cannot route to the SIP trunk and not hitting the Expressway Core. Inbound B2B call from external is working fine but outgoing is not working. When we dial a SIP URI - email@example.com it fails and no search history on the Expressway Core.
We have configured SIP route pattern as Domain Routing with pattern * pointing to the SIP trunk for Expressway Core.
What things need to be checked?