01-25-2019 02:38 AM
Does anyone know if the installed dial plans represented by the @ (e.g. NANP, UKNP etc) can match +E164 patterns?
My use case is as follows:
1. User dials a number which might be on the PSTN or another global office (via SME/ILS learned patterns) 2. We globalize everything to E164 and try to match our ILS learned patterns as the first choice 3. If step 2 fails, we attempt to use the local PSTN (matching @ with some filtering at the next partition in the CSS) 4. We want to block things like local Premium Rate calls on the local PSTN
If @ doesn't support E164 matching, I think having globalized the dial string, I would have to localize it again then attempt a match. To make matters worse, the local carriers then require E164. In other words, I would have to Globalize, then localize then globalize again! With all that effort, it might be easier to forget @ and just implement lots of country dial-plans, but this seems a lot of effort.
Any thoughts?
Solved! Go to Solution.
01-29-2019 04:12 AM
I hunted around for a while to see if I could find a full list of the NANP numbers supported by the @ wildcard, but came up empty. However, the Route Filters used with the @ symbol don't have a Route Filter Tag to capture the + character, which leads me to believe it is not supported by CUCM's @.
And I agree that stripping the +, going through the filter, and then re-adding the + seems a bit much. But the alternatives aren't much better::
If you don't want to globalize/localize/re-globalize, the only other one that makes sense to me is adding translation patterns to the incoming call CSS with the "Block this Pattern" checked.
HTH
Maren
01-28-2019 05:36 PM
James,
Are you leveraging an SME in your environment?
01-29-2019 01:46 PM
Are you leveraging an SME in your environment?
Sorry I missed your reply. Yes, we are using SME to learn global patterns company-wide in E164 format, but we want to leverage local PSTN breakout on some local clusters which are installed in various countries.
01-29-2019 04:12 AM
I hunted around for a while to see if I could find a full list of the NANP numbers supported by the @ wildcard, but came up empty. However, the Route Filters used with the @ symbol don't have a Route Filter Tag to capture the + character, which leads me to believe it is not supported by CUCM's @.
And I agree that stripping the +, going through the filter, and then re-adding the + seems a bit much. But the alternatives aren't much better::
If you don't want to globalize/localize/re-globalize, the only other one that makes sense to me is adding translation patterns to the incoming call CSS with the "Block this Pattern" checked.
HTH
Maren
01-29-2019 04:45 AM
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: