I have a client that handles all there outbound call routing with Route patterns in the CUCM. They have a DID group of (339) XXX-2100-2199. They also have a Route Pattern that handles all calls when a caller picks up and dials 21XX and another pattern that handles all calls 8.1(339) XXX-21XX. ( They need to dial 8 to get an outside line ) So no matter how the caller tries to dial the telephone number it stays internal and never goes out to the provider. This way they keep costs down and don't send calls out only for then to come back in again.
The question that I have is this. One of the DID's has been ported to another carrier for testing. If you call it from a cell phone or any other outside line it works well and has no issues but when you try to dial that "one" phone number from inside the CUCM the call fails because it never leaves to go to the provider to be routed to the new carrier.
Is there any way that I can change the route pattern or write a new route pattern so that this single number will route out to the carrier?
The short answer is, as Jamie said, configure an exact match route pattern.
But let me add a few more details.
First of all, I think 21XX and even 8.1(339) XXX-21XX are translation patterns in your scenario. For example, whether you dial 2199 or 8.1(339) XXX-2199, they both translate to the same internal destination as per your explanations. On other hand, route patterns are only used when you want the calls to leave your phone system.
Now, let me ask you this. Does the new carrier deliver the single DID to a different phone system?
If yes, in order to get outbound calls to that number work from your exiting CUCM cluster (where the number used to belong), you
need to create an exact match route pattern.
Let's assume the DID in question is 3393332199.
In your CUCM, go to Call Routing > Route/Hunt > Route Pattern
Find the route pattern that routes outbound calls to your carrier (i.e. 8.1[2-9]XX[2-9]XXXXXX) and click on it.
Once the page loads, click Copy, then replace 8.1[2-9]XX[2-9]XXXXXX with 8.13393332199 in our example, and hit save.
Now, in this example, when you dial 8.13393332199 it matches the newly created Route Pattern instead of the translation pattern 8.1(339) XXX-21XX because the former is an exact match. This way the call routes to the carrier.
However, if the new carrier delivers the single DID to the same CUCM cluster where the DID has always belonged, why do you need internal calls to this number to go out to the carrier?
Thanks for the help. To answer your last questions first. The new carrier has taken the number to send it through a cloud based PBX that they want to migrate to. Im just having an issue with allowing the people that are still on the CUCM access to dialing that DID because the CUCM appears to be designed to keep all DID's dialed from leaving the CUCM.
But I will try as you suggest and see if that works for me.
To send calls outside to PSTN you need to have a route pattern. Depending on the gateway type you might also need dial-peer on your gateways matching this Route pattern.
When you said porting to another carrier, i assume you have a new line from the new ISP where they provide the same range of extensions. For testing they did the porting for just one number on these new lines . Am i correct ?
How do you achieve this " hey also have a Route Pattern that handles all calls when a caller picks up and dials 21XX and another pattern that handles all calls 8.1(339) XXX-21XX "is it by RP or translations ?
As others has said a Route Pattern will send calls outside of the CM. What you’re referring to with this “So they have a route pattern with just the last four 21XX and they also have a route pattern with the entire string 8.1(339) XXX-21XX.” are Translation Patterns, not Route Patterns. A translation pattern is designed to translate the called number and calling number as well if configured that way. This is what keeps calls to DID numbers inside of CM.
For us to help you you’ll need to share a little more detailed information on your specific setup so that we can understand your system.
I never seen router patter for an extensions unless they are on a different cluster connected by a trunk. If they are on the same CUCM server, you don't need a Router pattern to call 21XX. This concept exist for some vendor where they also need a route for internal extensions ..
It would be great if you provide us more information as @Roger Kallberg mentioned.
Just to give a little more information. It looks like they only have a PUB and a SUB with may sites connected by routers to the CUCM. I've looked at a few of the routers and none of them have any dial peers in the config. Ive copied and pasted all of what I believe to be the pertinent information below with regards to the routes and translations. Please tell me what you think and if there is anything else I can offer up for help. I really do appreciate the assistance.
Translation Pattern Partition Description
339xxx.21XX Extensions 10 Digit to 4 Digit
8339xxx.2XXX Extensions 10 Digit to 4 Digit
81339xxx.2XXX Extensions 10 Digit to 4 Digit
Pattern Description Partition Associated Device
21XX Extensions Extensions Lynn-Core
8.1XXXXXXXXXX Long Distance Boston Boston-PRI
8.XXXXXXXXXX Long Distance Boston Boston-PRI
This is consistent with my speculations in my previous post. Your DIDs match translation patterns to be translated to internal destinations which is most likely the last four of the DID.
Now, 8.1XXXXXXXXXX and 8.XXXXXXXXXX are your route patterns that route calls to the gateway/carrier.
Go head and copy 8.1XXXXXXXXXX and replace the Xs with your single DID that has been ported to the new carrier.
Also, copy 8.XXXXXXXXXX and replace the Xs with your single DID that has been ported to the new carrier.
When you copy a pattern, the pattern is not deleted or overwritten; it helps you create a new pattern with the same parameters.
After the above changes are applied in CUCM, you can start testing outbound calls to the DID in question by dialing 81+Single DID or 8+Single DID.
Edit: Disregard notes below. Just read your response again, and you mentioned there are no dial peers on the gateways, so you must be using MGCP to control your gateways. The above changes should still work.
If for some reason, the call still fails, it is possible that the gateway sends the call back to CUCM (instead of sending it to the carrier) due to a closer dial peer match on the CUCM facing side. In that case, please share your gateway config so we can suggest a solution.