my question is about processing order between internel DN's and route pattern destination. I explain:
1. I must migrate from a traditional Nortel PBX to Cisco Call Manager
2. I have about 2000 phones to migrate
3. There will be a migration period during this i will have both Nortel and CUCM up interoperating and mixed traditional and ip phones.
4. Suppose i have a QSIG trunk between Nortel and CUCM and i have 100 IP phones migrated to Cisco and 1900 still on Nortel
5. I need a route pattern for numbers to PSTN (eg: 0.!)
6. I need a route pattern to reach the DN's on Nortel (maybe...)
My question is: in the route pattern at point 6 i must specify an expression that excludes the first 100 Cisco ip phones ? Or i can leave XXXX because of processing order of CUCM that recognizes that the 100 cisco phones are internal DN's ?
That`s correct, a simple route patttern of xxxx , digit length of the Nortel , will work fine though to remove any doubt it may be better to have the prefix, leading digit of the Nortel range so 2xxx, 3xxx, 45xx etc. The blanket xxxx will work as long as you do not have any other closer matches
so is correct that: if i have 100 dn's registered with CUCM and i have a route pattern that also matches this DN's (eg:XXXX or with prefix like you said), the CUCM first loook into internals DN's and processes them first ?
Sorry if i ask again but, like i said, i'm in this situation:
- i must progressively migrate DN's from Nortel to CUCM (suppose 100 dn's per day)
- i want to avoid to change every day the route pattern that permit the communication from Cisco IP phones to Notel phones
- so i want to be sure that i can use a pattern of XXXX and don't change it every time i migrate groups of DN's
Yes, you are correct.
CUCM will look at DNs configured locally, then look at route patterns on a digit-by-digit basis i.e. it will try to match after each digit is received.
I have the same configuration as you whereby I have a Qsig trunk to an PABX, I have DNs registered on CUCM with e.g. 7696 and a router pattern to the qsig trunk of 7XXX and it works without any issues.
To make yor life even easier. At the moment you delete a Nortel user and point their extension number to the CUCM using a CDP, to remove the need to do this for every user
Is your Nortel networked to any other PABX?
If not then ask your Nortel supper if Vacant number is used, set up
Look for VNR
Create a RLB, Route to point to your CUCM. Set VNR to yes
Now when you delete a DN in Nortel it and a user dials the DDI number, the Nortel will search for it and if the number is not configured in its Db ie you deleted it then it will send the call to the VNR which in turn sends it to the CUCM. Be aware of any other vacant numbering set up - ask the Nortel guys if they have vacant set up with the Nortel Switchboard as this VNR may override it
i have another question regarding CUCM processing order. I did the configuration that i was talking about in previous post. So:
- Created a route pattern of XXXX for the Dn's migrated to Nortel (this pattern points to QSIG interface)
- Added some DN's to CUCM
- i didn't need to upgrade " XXXX pattern" every time i migrate a DN to CUCM because the Call Manager first look at his internal DN's and then to patterns.
All is working well...
Now i decide to implement CoS. I try to avoid explaining all the configuration because is long but... in few words:
- i create 4 partitions for different types of calls (internal calls, local calls, long distance calls, international and mobile calls)
- i create 4 partitions for hosting DN's that are allowed to the prevoius 4 kind of calls
- i creata 4 CSS (every DN's is permitted to call each other)
My question is about calls between DN's registered in CUCM and not for PSTN.
The problem is that, as i implement such a configuration and move my DN's from the default partition, CUCM processing order changes: now CUCM looks directly to " XXXX pattern" and seems not seenig first to his internal's DN's.
The result is that:every time i do an internal call between 2 DN's registered in CUCM, the Call Manager looks first to route pattern.
Is this behaviour normal ?
So you have 5 parttitions
long distance calls
You have assigned 4 each of these to separate Route Patterns?
long distance calls
and Partition - "Internal calls" to internal DN`s
Each DN has a CSS containing
long distance calls
and each DN is assigned to internal calls partition?
It should look for the DN 3123 rather then xxxx pattern as this is closet match . How do you know if looks at the xxxx patern first is it via DNA?
Yes, i have :
- 2 route patterns ( 0.! and XXXX) not associated yet with partitions because my problem deals with internal calls.
- 4 partitions (and suppose i have 4 DN's to test purpose)
long distance calls
international + mobile calls
to assign to 4 different route patterns (not assigned yet).
- Then i have other 4 partitions to associate them to different DN's with different privileges:
internal calls DN's (eg: DN1 associated)
Local calls DN's (eg: DN2 associated)
long distance calls DN's (eg: DN3 associated)
international + mobile calls DN's (eg: DN4 associated)
- Then i create 1 CSS for each test DN: each CSS contains all 4 previous partitions to permit internal calls to every DN.(and contains 1 or more of the first 4 partitions to implement different PSTN privileges).
Yes, i do test via DNA and, for example, if i do a call from DN1 to DN2 my closest match is XXXX pattern.
Before implementing partitions and CSS, CUCM correctly recognized both DN's as internal registered and didn't need to match a route pattern.
the configuration was working...it's my fault because i didn't specify a CSS in DNA. It's strange that you can specify a CSS in your DNA test: the CSS is assigned to DN...so if i start a test call between DN1 and DN2 the software must see which CSS is assigned to DN1 and give the result to make me sure that the configuration is good.
The reason you have to provide the CSS of the calling DN is due to the potential of overlapping Numbers. You may have a DN of 1234 with Partition A and the same DN 1234 but with Partition B- both can exist on CUCM due to the different Partitions however DNA does not use, need Partitions so to make DNA work you have to assign the CSS - don`t forgot DNA is used to investigate dialed numbers and so does not care what Partition you dial from