E.164 Dialling Restrictions - How?

[carlnewton]

How do you do yours?

In days gone by the method I would use would be:

Route patterns to match different call classifications in different partitions,set to block the call. (National, Mobile, International, Premium)

CSS on the users line that would contain all the types of numbers I wanted to block

CSS On the phone that simply had a partition that gave it access to a gateway.

That way, if the call was not blocked, it would route out.  Id create different line based calling search spaces to dictate different dialling permissions for different users.

Nowadays with E164 we are using translation patterns to translate local dialling habits to E.164 numbers.  In this case, do you do the dialling restrictions on E164 patterns or on local dialling habits?

What does this mean for when users dial E164 direct? They can get around dialling restrictions.

The only way to really do it seems to be to have two sets of "Blocking" route patterns.  One for E.164 numbers, and one for local dialling habits.  This isn't very clean and is a little more administration heavy than I'd like.

What do you all do when you need to have different levels of dialling permissions and a dial plan capable of both E164 and regular location based dialling?

[yahsiel2004]

Carl,

For dialing restrictions, you would do the same as in the past. Create restricted partitions and CSSs, that would be assigned to extensions and route patterns (which would be set to blocked). The patterns could be in both E.164 and or non E.164.

Regards,

Yosh

[carlnewton]

Well this is it, now I have to make two sets of blocking route patterns, 1 for E.164 and 1 for regular numbers?

Is there not a more streamlined way to do it?

[Richard Simmons]

Use translation patterns to convert from user dialled number to E.164 eg.

90.[1-9]! to \+44.!

Then you just have route patterns as;

\+44.[1-2]! for national

\+44.7! for mobile

etc and have them set with the appropriate partition and then localise the number again at the gateway, I normally do this within CUCM gateway configuration for H.323 or SIP registered gateways

This means you only need 1 set of blocking patterns for the E.164 format.

[carlnewton]

What happened to Cisco's "its so much easier with E.164 because you only need \+.! Route pattern!"

Also, with your example, how do you block? E.g I have two users. One needs to only be able to dial mobiles, the other needs to dial mobiles and international.

How would you achieve that?

As soon as you use a translation pattern to globalise the number you lose the ability to block anything unless you have a set of translation patterns for every dialling permission you need (Due to the need to set outgoing CSS on the translation pattern)

The only way I can see this stuff working nicely is by Cisco adding an "alternate match" field on route patterns.

That way you can have:

Line CSS:

Block Mobiles (9.07! or +447!)

Block International (9.00! or +[012356789]XXXXXXXXXXX!)

Device CSS:

Route \+.! to standard local route group

Since you can't do the above, I think you have to have two sets of translation patterns to block at the line level.  I can't see any other way of doing it that affords you the ability to have different dialling permissions set at a line level?

[Richard Simmons]

Just to confirm, you only need 1 set of blocking patterns and you also need a matching set of patterns to allow users to dial these numbers.

It all depends on how granular you want to get with these things as to how big you want to make you route patterns etc.. Its a minefield out there and as you stated there is still a lot of improvements that could be implemented!

[carlnewton]

I dont understand how you can only use one set of blocking patterns though?

If you have one set of blocking patterns based on E164 then that means you have to translate regular numbers to E164 at the line level.

This means you either lose the ability to assign different dialling permissions, or you have to have a set of translation patterns per dialling permission (Since you have to choose which CSS to push calls out of from the translation pattern, and each dialling permission will need a different CSS)

This is ugly and large for configuration.

I can't see a way to do it nicely that allows you to:

Cater for users that dial in 9.07 format and +4407 format

Apply different dialling permissions for different users

use the "standard local route group" Feature on devices to allow for intelligent gateway choice when using extension mobility between sites.

The only way I Can see to do it is to basically make two dial plans.

I don't see how your example works Richard. I get the theory about globalising and localising again at the gateway, but I don't see how you can provide different dialling permissions on a per user basis with your example?

[Richard Simmons]

You translate all calls to 90.! to \+44.! 

You then have route patterns for blocking certain aspects from that i.e. mobile, premium rate etc...

\+44.7 in the BLOCK_MOBILE_PT

you also have

\+44.7 in the UK_PSTN_PT

If you want to block calls to mobile numbers then in the users line CSS you just add BLOCK_MOBILE_PT, the device will have access to UK_PSTN_PT but as it concatenates the two CSS's the block with stop the user from dialling mobiles on either +447 or 907

Apologies if I have totally missed the point in what you are trying to achieve here.

[carlnewton]

I sort of see what you are saying Richard, but unless I understand it wrong, it won't work. Lets say we want to block user dialling mobile.

User CSS:

Block \+44.7

Translate 9.07 to +447

Line CSS

Route \+44.7

User dials +447590 123 456 from their handset.  Call hits Block pattern.  Desired behavior is achieved.  What if the user dials 9.07590 123 456? The call is translated to +44 format but does not drop down to the line CSS, because you have to pick the outgoing CSS for the translation pattern.  It never reaches the line CSS.  It doesn't get blocked at the line... The only solution I see here is to create two blocking patterns in the block partition, one for E164 dialling and one for regular dialling.

You cannot use the "drop down to line CSS" method of call routing any more because the translation patterns force you to pick an outgoing CSS; Which I Believe is why we now have the "Standard local route group" option.

I will check out that Cisco Live presentation, thank you very much.

[carlnewton]

I have not finished the presentation on Cisco live yet.

However, the parameter in version 10.0 "Use originators CSS" alleviates my issues.

This parameter is not present in version 9.

That, along with "urgent" status on DN's makes creating an E164 dial plan much much easier.

[Jameson Gagnepain · Accepted solution]

I suggest you check out this presentation on CiscoLive.com (get an account on there if you don't have one yet, it's free):

"BRKUCC-3000 - Advanced Dial Plan Design for Unified Communications Networks (2014 San Francisco)"

Johannes Krohn did an awesome presentation on this very subject.

-Jameson