cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
838
Views
5
Helpful
5
Replies

Problem using 7 as outbound prefix

bill.roland
Level 1
Level 1

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.

2 Accepted Solutions

Accepted Solutions

Aaron Harrison
VIP Alumni
VIP Alumni

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..

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

View solution in original post

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

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

View solution in original post

5 Replies 5

Aaron Harrison
VIP Alumni
VIP Alumni

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..

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

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

good from aaron

but easiest is to change this 7 to another predot as 77 or * or 99 to simplify your dial plan

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

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

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