[cisco-voip] Dialplan Woes

[Ryan Schwab]

+1 for using the EPNM for ANI display to the PSTN like Mike said...

If you're looking for 'best practice' IMO that is it. Just make sure the "
Use Calling Party's External Phone Number Mask " is selected throughout the
flow (typically RP->RL->RG->GW) and remember that settings further down the
flow over ride the settings on the former.

ANI transformation patterns placed on the gateway(s) will also work, but
they are not introduced until version 7x.


-----Original Message-----
From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Norton, Mike
Sent: September-07-11 12:57 PM
To: Pawlowski, Adam; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Dialplan Woes

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

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