Trying to figure out a way to have a scalable global dial plan while forcing calls to DN's on-net. To do that "automatically" without having to constantly train users about who's on-net vs. off makes this harder than it sounds.
Since I can't do centralized trunking yet (politics), I'm trying to figure out a way to define all DID's (globally) in one, or few, servers/gatekeepers instead of on every cluster.
Trying to figure out if Gatekeeper technology prefixes will help do this.
Call Manager will do the class-of-service admission, and translate every number into an int'l dial string (such as 1-651-777-5xxx for US or 49-211-333-xxxx for Dusseldorf).
From there, all calls would be sent to a local IOS gateway. A high preference dial peer would send every call to a gatekeeper with a tech prefix that is unique to that gateway.
Here's where I don't know of tech prefixes will make this work. If there is a zone prefix match (meaning an internal DN defined that goes to CCM) then it would hopefully go to that CCM's ICT and be an internal call.
If no zone prefix match, then would the call get sent back to the gateway designated as that tech prefix? With the tech prefix still in front of the original number?
If so, then I'd have a dial peer with that tech prefix configured to go out the PSTN.
The way I read the docs is that tech prefix will override a zone prefix match. But that would make them useless for anything but a default gateway type of thing so I wanted to ask.
Re: Global Dial Plan - Gatekeeper Technology Prefixes
Zone prefix is not the same as a registered e.164 number. if a device registers to a gatekeeper using e164, the gatekeeper can easily route the call based on that number. Zone prefixes are used in combination with techprefixes to route calls in cases where you dont have an option to register extensions as e164 numbers. For example, callmanager cannot register to a gatekeeper with e164 numbers. (while CME can).
Here is a diagram that indicates how gatekeeper routes a call. Look at the first picture in this link.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...