12-08-2011 11:13 AM - edited 03-16-2019 08:27 AM
Greetings to all. I am a bit stumped and would appreciate somebody pointing out what I'm missing. We use 7 to initiate outbound calls instead of the more traditional 9 (we were having too many false 911 calls). It all works fine, except a couple of our DID's start with 71, so you end up with a case where, when a user needs to call a long distance number, say 714-xxx-xxxx, and they dial 7-1-71, the translation pattern matches and they get routed instead an internal number.
I can't figure out a way around this other than have the phone company deliver more than the last 4 digits on the PRI. If anybody has an ideas or the answer, I'd be very grateful.
This is a CUCM BE5000 running 8.6
Thanks in advance.
Solved! Go to Solution.
12-08-2011 11:31 AM
Hi Bill
If 7171 is an extension, then you have put yourself in a corner really...
However if it's a translation just used to map a DDI to an extension (i.e. SP sends 7171, you translate to 8071 or something) then all you need to do is create a new CSS for the gateways to use in the 'inbound' direction. Only the gateway that receives these calls needs to be able to send to 7171, so put this translation in a partition that only exists in this new CSS (also adding anything else that the GW needs to reach directly). Ensure that the new PT containing the translation isn't in normal people's CSS.
Regards
Aaron
Please rate helpful posts..
12-08-2011 12:19 PM
Good information from Aaron (+5 A.). Though there is some fundamental concerns I would have with the dial plan approach you appear to be taking. Buidling overlap in your dialing behavior will lead you to systemic problems down the road. That being said, it sounds like you have tried to mitigate the overlap by forcing internal extensions to use leading digits that do not overlap with your offnet dialing prefix. If that be the case, then I guess it is an adequate work around for the time being.
Longer term, I am a fan for asking your carrier to present all digits. In NANP, that would be 10-digits. I always approach CUCM DP design by enforcing a rule that any foreign system (like a PBX or CO) be required to give me fully qualified number patterns. This helps me avoid all kinds of trouble, especially in environments where growth/expansion/or just plan churn is inevitable.
Coupled with this FQDID approach, I am with Aaron on having your PSTN GW use a complete separate CSS/partition arrangement than phones. This also helps control digit overlaps and gives you some additional control over call flows (such as instituting ToD routing for broad ranges of DNs or redirecting/blocking access based on calling or called number). Seems small at first, but it is a huge benefit long-term.
HTH.
Regards,
Bill
Please remember to rate helpful responses and identify
12-08-2011 11:31 AM
Hi Bill
If 7171 is an extension, then you have put yourself in a corner really...
However if it's a translation just used to map a DDI to an extension (i.e. SP sends 7171, you translate to 8071 or something) then all you need to do is create a new CSS for the gateways to use in the 'inbound' direction. Only the gateway that receives these calls needs to be able to send to 7171, so put this translation in a partition that only exists in this new CSS (also adding anything else that the GW needs to reach directly). Ensure that the new PT containing the translation isn't in normal people's CSS.
Regards
Aaron
Please rate helpful posts..
12-08-2011 11:34 AM
Hey Aaron, thanks!
It is indeed just a DID that translates to a DN (the DN is 2201). I'll give your suggestion a try and report back, thanks again.
Bill
12-08-2011 11:56 AM
good from aaron
but easiest is to change this 7 to another predot as 77 or * or 99 to simplify your dial plan
12-08-2011 12:19 PM
Good information from Aaron (+5 A.). Though there is some fundamental concerns I would have with the dial plan approach you appear to be taking. Buidling overlap in your dialing behavior will lead you to systemic problems down the road. That being said, it sounds like you have tried to mitigate the overlap by forcing internal extensions to use leading digits that do not overlap with your offnet dialing prefix. If that be the case, then I guess it is an adequate work around for the time being.
Longer term, I am a fan for asking your carrier to present all digits. In NANP, that would be 10-digits. I always approach CUCM DP design by enforcing a rule that any foreign system (like a PBX or CO) be required to give me fully qualified number patterns. This helps me avoid all kinds of trouble, especially in environments where growth/expansion/or just plan churn is inevitable.
Coupled with this FQDID approach, I am with Aaron on having your PSTN GW use a complete separate CSS/partition arrangement than phones. This also helps control digit overlaps and gives you some additional control over call flows (such as instituting ToD routing for broad ranges of DNs or redirecting/blocking access based on calling or called number). Seems small at first, but it is a huge benefit long-term.
HTH.
Regards,
Bill
Please remember to rate helpful responses and identify
12-09-2011 09:08 AM
Thanks, everyone, I implemented Aaron's suggestion and it works perfectly.
Thanks for the info, Bill, I agree with you that really the longterm solution is having the carrier deliver all the digits. I intend to get them to do that.
Thanks again, you guys rock!
Bill
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide