Extension is not a valid entry

[William Hoover]

We have some extensions that you cannot connect to from outside calls. When a outside call comes in and the caller tries to connect to certain extensions they get a message that the extension is not a valid entry. I do know that the extensions that get this error do not have voice mail enabled. Is a voice mail box required for an outside call to be routed to an internal DN? How can I allow calls to be routed to these DNs without a voice mail box?

Thanks!

Bill

[Bradford Magnani]

Yep, that's correct, to prevent toll fraud.

[William Hoover]

How do I do that? 

Thanks Brad

Bill

[Rob Huffman]

Hi Bill,

Just a guess here .....but I would look at the greeting (setting, allow calls etc.) on the "Opening Greeting" Call Handler instead of the CSDR AA

Cheers!

Rob

[William Hoover]

Ya just to CMA I set it for all of the Handlers previously, I double checked the "Opening Greeting" handler and it is still set to "Allow tranfers to number not associated with.." already. It worked fine yesterday when I tested it and no one else admits to making any changes to the system. It looks the same as when I left it.

The restrictions look correct right?

What should I have under the DN settings for Voice Mail profile? I tried none/sys default, NoVoiceMail and our custom one ATT did when they did the install.

[Rob Huffman]

Hi Bill,

It took me a minute to figure out CMA

The restriction tables look just fine to me and I actually did some testing on this

today just to be sure. Is it possible that a different greeting like the Alternate or Closed

is being used while you are testing? The allow calls ...would need to be set on these

greetings as well.

As for the VM profile, you kind of lost me there. Are you referring to the profile that would be

set on the phones that don't have VM? I would think that "none" should be just fine.

Cheers!

Rob

[William Hoover]

Ya all handlers have it set to allow all on all greetings.

OK so if I remove the checkbox on the "*" field of the Default System Transfer restriction table the calls will go through, of course I cannot leave it that way as it might open a security hole.  I tried changing the order and setting one of the patterns that matched the DN I was dialing to be number 11 (right above the *) but it did not work.

Ya VM setting question was for those DNs that dont have VM.

[Rob Huffman]

Hi Bill,

The Pattern matching works top down I believe from 1 to 12 in your case.

Just curious what DN you are trying to call in your testing?

Cheers!

Rob

[William Hoover]

DN I am trying is 6527 and 7758, I should not allow all by removing the checkmark on field 12 (*) correct? Shouldn't having those other patterns defined as not blocked take care of that?

[Rob Huffman]

Hey Bill,

Well something is messed up with our testing for sure

Our system is currently set to block all transfers (from the main CH) to numbers

without VM. So I tried to call 6777 from the main CH this AM and got the;

"You cannot be transferred to this number, please check the number and try again".

Which is good as this number 6777 has no VM associated. Then I went to the default

system transfer restriction table and added 6??? - Allow as table entry 0.

When I tried my test after this I was able to route to 6777 without issue. This is with the

last entry in the table as * - blocked. So I'm not sure why it doesn't work this way for

your tests???

As for the security risk, if your ports that connect to Unity do not have a Long Distance CSS

your already covered 

Cheers!

Rob

[William Hoover]

Ya like I said it worked initially. I am going to remove all of the enries from my restriction table and then just try one explicitly for a particular DN and go from there. How can I check what CSS's I have available to the Unity server?

Thanks again!

Bill

[William Hoover]

So I went ahead and removed all of the new entries I had created from my Default System Transfer table and then added one that matched exactly to a DN that I have with no VM and I still get the same message

"You cannot be transferred to this number, please check the number and try again".

Any other suggestions?

[Rob Huffman]

Hi Bill,

That's an excellent idea

If you look in Communications Manager via;

Voicemail > Cisco Voicemail Port > Find and List

and then click on one of the ports you will see what Calling

Search Space has been assigned. The chances are very good that

the CSS will be an internal only one. If that's the case you are good to

go as far as the final pattern * - Allow goes. To be very sure I would

look at each and every VM port to ensure there are no holes that would

expose you to Toll fraud.

The only other thing that I can think of is that your testing from the first day

was somehow different than the subsequent tests. Using a different DN/phone

internal vs external calls or something along those lines.

Cheers!

Rob

[William Hoover]

OK so I looked at the ports and they are set to use CSS-Voicemail

It is set to use the following partitions

PT-Blocked-Telescam

PT-PhoneDN

PT-Centrex

PT-VM-Pilot

PT-Local

PT-LD

I tried dialing in and then dialing out but got "call cannot be completed as dialed"

Are there any patterns I should try dialing that are known to work on unsecure systsems?

Thanks again

Bill

[Rob Huffman]

Hi Bill,

If these are the selected partitions I would be worried about

PT-LD as that sounds like your Long Distance access. After

you change the pattern to *- Allow try dialing local, LD, 1-900

etc. etc.

You may really only need PT-PhoneDN and PT-VM-Pilot as

selected partitions in CSS-Voicemail and perhaps PT-Local.

Cheers!

Rob

PS:don't forget to use your dial acces code 9 or whatever you use when testing

[William Hoover]

I tried a bunch of combinations with the PTs set as they are. Nothing seems to work, dialing 9 which is our outside line access code puts you into the search directory by name menu. Now if I could just figure out how to search the call logs I could check for fraudulent calls, but thats another thread