cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6305
Views
10
Helpful
16
Replies

URI dialing with CUCM+VCS-C/E to external destinations

Alexey Smirnov
Level 4
Level 4

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 info@example.com 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 info@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 info@1.2.3.4 (1.2.3.4 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 1.2.3.4? 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 1.2.3.4 the call reaches VCS-E, but it doesn't fall under DNS search rule and in Search history I see

  • CallsToUnknownIPAddresses (1)
    • Mode: Direct
    • Zone (1)
16 Replies 16

Hi, Alexey

"Call cannot be completed as dialed" - this says CUCM.
You have correct the route pattern .

br Oleksandr

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.

 

Thank you!

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?

I would genarly say because CUCM cannot distinguish the "." character properly.

Try this.

On CUCM

Add New SIP Route Pattern

Pattern Usage=Domain Routing

IPv4Pattern=ip

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)

On Expressway

Create new transform

Regex Alias Pattern Match

(.*)@ip

Strip

Try to dial 1.2.3.4@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 info@1.2.3.4 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 info@1.2.3.4 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.

Hi Shawn,

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 ?

Thanks.

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:

  • Mode: Alias pattern match
  • Pattern type: Regex
  • Pattern string:  (?!.*%localdomains%$).*
  • Pattern behavior: Leave

%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:

  • Pattern string: (?!.*@vc.domain.org.*$).*

Thanks Patrick !

Patrick Sparkman
VIP Alumni
VIP Alumni

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.

Dial IP Addresses from Endpoints Registered to CUCM with VCS / Expressway Configuration Example

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 1234@10.10.10.10 and 1234@example.com? Why are they routed differently by CUCM and VCS-E?

As for VCS-E with direct calls to unknown IP adresses why URI of 1234@10.10.10.10 doesn't to a DNS zone and 1234@example.com does? DNS zone can be configures to make A records lookups as well...

Alexey,

Did you ever figure this out?

Thanks
Justin

Thank you,
Justin Ferello
Technical Support Specialist, ScanSource KBZ

VCsupport17
Level 3
Level 3

Hi Alexey,

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 - loopback@rtp.ciscotac.net 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?

Thank you.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: