Blocking CLID on Callmanager 5.1

Answered Question
May 29th, 2007

Any easy way to invoke CLID blocking on an adhoc basis ? i.e an internal extn calling either internal or external numbers.

I have this problem too.
0 votes
Correct Answer by lfulgenzi about 9 years 6 months ago

Unless things have fundamentally changed from 4.x to 5.x, the only way to do this is to create a translation pattern that matches specifically dialled digits, then sets the presentation to restricted and then outpulses (called party mask) the digits again.

Fundamentally this works. Unfortunately, it is not scalable. The reason is that the translation itself has a calling search space as well. Take for example, a design which has say X number of calling search spaces. To truly preserve your classes of service, you would have to create X number of partitions with this special translation pattern and insert this partition into each of the X calling search spaces. You would then have to create X translation patterns, and assign each of these translation patterns the appropriate, i.e. original, calling search space.

If you're translation pattern is accessed by a code, e.g. *67, then you can use the same calling search space assigned to the phone. However, if you wanted to implement real time masking without any access code, you're translation patterns would have to be assigned a copy of the original calling search space minus the partition the translation exists in.

It's all in the design, partitions and calling search spaces apply here.

For external numbers, the requirement for adhering to calling search spaces is even more important, because for onnet calls, the worst that can happen is someone calls an extension they're not supposed to. But for offnet calls, it could mean toll fraud.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Loading.
Correct Answer
lfulgenzi Tue, 05/29/2007 - 18:07

Unless things have fundamentally changed from 4.x to 5.x, the only way to do this is to create a translation pattern that matches specifically dialled digits, then sets the presentation to restricted and then outpulses (called party mask) the digits again.

Fundamentally this works. Unfortunately, it is not scalable. The reason is that the translation itself has a calling search space as well. Take for example, a design which has say X number of calling search spaces. To truly preserve your classes of service, you would have to create X number of partitions with this special translation pattern and insert this partition into each of the X calling search spaces. You would then have to create X translation patterns, and assign each of these translation patterns the appropriate, i.e. original, calling search space.

If you're translation pattern is accessed by a code, e.g. *67, then you can use the same calling search space assigned to the phone. However, if you wanted to implement real time masking without any access code, you're translation patterns would have to be assigned a copy of the original calling search space minus the partition the translation exists in.

It's all in the design, partitions and calling search spaces apply here.

For external numbers, the requirement for adhering to calling search spaces is even more important, because for onnet calls, the worst that can happen is someone calls an extension they're not supposed to. But for offnet calls, it could mean toll fraud.

Actions

This Discussion