[cisco-voip] Dialplan Woes

[Pawlowski, Adam]

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