Flexible Feature Code CPP

[MHutt]

Hi All:
I've recently been asked to enable caller ID blocking (*67) on our PBX, which I've done in LD 57. I configured FFC code Calling Party Privacy with *67 and this works fine. However, I discovered that if I simply enter 67 from my phone, then 9+phone number, this also works the same as entering *67. I had never tried dialing 67 then 9+phone number before, so I'm not sure if this is a system default or something I've done. If I try to out this feature code, I can out *67 OK, but if I out 67 from CPP, I don't get any error codes so it appears to be removed, but I can still use 67 for CPP on our phones. What's going on here?
Thanks,
Marty

 

[Avaya911PLM]

Print a DNB of 67 in the switch and see what comes back, you may have stumbled on a ACOD fo a trunk route.

Fletch

http://PBXTech.Net

 

[MHutt]

That was the first thing I did. 67 was not a DN. I was actually able to create a new DN of 67. 67 still worked for CPP and in order to dial the DN 67 I had to dial 6+67 (I work for a large, multi-property hotel and dialing 6 first is for making room to room calls for guests). Very strange.

Marty

 

[Avaya911PLM]

OK< How about predigit translation? Is there and XLST entry against the set other than 0? If so what is the contents of the SpeedCall list number that matches the XLST?

Fletch

http://pbxtech.net

 

[MHutt]

We do use pretranslation lists. Dialing 6 first will bypass any other speed call digits on the phone and allow you to dial internal DNs. This is true for all XLSTs (we use 4 XLSTs) I've tried dialing 67 from phones with different XLST's and they all work the same, regardless of XLST. When I had setup DN 67 to test things out, I had to dial 6+67 from all the phones regardless of XLST in order to ring it. I've since remove DN 67 as I was just testing it. Basically, I was just curious as to why simply dialing 67 works as CPP without having this setup in LD 57. It is just something that is annoying me and not causing a problem.