[cisco-voip] Dialplan Woes

Norton, Mike mikenorton at pwsd76.ab.ca
Wed Sep 7 14:56:55 EDT 2011


A lot of folks seem to be into using 10-digit DNs because it makes certain things easier. Sounds like your situation would be one of those things. Follow the current "Easy Ways to Mass Modify Dial Plans" thread to figure out how to add the area code to the beginning of all your DNs. After that you could probably come up with some translation patterns so that people could still dial each other using 7 digits like they're used to.

Or, don't overthink it and just use the external number mask field, since that's what it's for.

-- 
Mike Norton
I.T. Support
Peace Wapiti School Division No. 76
Helpdesk: 780-831-3080
Direct: 780-831-3076


-----Original Message-----
From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Pawlowski, Adam
Sent: September-06-11 7:59 AM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] Dialplan Woes

Mornin' group! I've exhausted a number of possibilities here, but, I haven't lost hope that some fresh views may yield the solution to our troubles.

We've created and worked ourselves a dialplan using seven digit extensions, basically 1:1 extension - DID . This did, of course, make things so much simpler, initially, but, there seems to have been some folly in that this is inflexible to additions and changes, as pretty much all the call processing we would have done with traditional short extensions and routing, we didn't do.

Right now, we basically use a ubiquitous calling search space for a given call restriction level (say, long-distance calling), for both normal calling, masked calling, call forwarding, services (voicemail) etc. Where we've run into trouble is that our service provider is enforcing 10 digit calling party presentation, otherwise our CLID does not work outbound. I've looked at a number of possibilities, but, I'm worried it is going to cause us to have to get under the hood for a dialplan overhaul, which I can't see that being exactly painless. 

I looked at inserting the area code via prefix and mask with transformation patterns, at the route list, and gateway levels. This works except that it overrides external number masks, and re-writes forwarded numbers. 
I looked at transformation patterns, but, in this version (6.1.3) it doesn't seem to be functional, or, at least, I can't find the part where you set the "calling search space" for that, and it seems to have no effect.
I looked at a translation on the gateway, but, the documentation is telling me that it does not accept wildcards (6500 CMM with 6T1 on 12.4(23) ) , so that would have the same problems as above.

Viable options would include:

separate calling search spaces for each case, with appropriate transformations, so, "traditional" dialing and "masked" dialing, as well as services and forwarding. This would take some time, of course.
Upgrade to CUCM 8 where, theoretically, transformation patterns work, but, I bet this still breaks the external number mask.
Run a DB query to populate the external number mask field on all (not already masked) numbers to 123XXXXXXX , where 123 is the needed area code.

I think this last one would work to "buy us time" but would become obnoxious to deal with filling this in and maintaining it in the future. If there's no easy way around this, at least, could anyone recommend a "best practice" type document in regards to dialplan design? If it requires moving away from long extensions, I doubt there'd be much buy-in, but, it may allow us to at least think about what we're doing so that we don't make things worse.

Thanks much
        

Adam Pawlowski
Computing and Information Technology
Network and Classroom Services
716.645.8489  


_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip



More information about the cisco-voip mailing list