cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7764
Views
25
Helpful
29
Replies

Extension is not a valid entry

William Hoover
Level 1
Level 1

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

3 Accepted Solutions

Accepted Solutions

Bradford Magnani
Cisco Employee
Cisco Employee

Hi Bill,

This is configurable on the Call Handler greetings page:

Hope that helps,

Brad

View solution in original post

Rob Huffman
Hall of Fame
Hall of Fame

Hi Bill,

I'll just add a link to the great info from Brad and Java (+5 each my friends!)

You'll want to look at the system transfers and system transfer restriction table

http://www.cisco.com/en/US/docs/voice_ip_comm/connection/7x/administration/guide/7xcucsag115.html

Cheers!

Rob

View solution in original post

Correct, or just uncheck row #4 that has the * listed to test, but that could be a security risk if you leave it that way for any period of time.

Brad

View solution in original post

29 Replies 29

Jaime Valencia
Cisco Employee
Cisco Employee

Assuming you're talking about Unity because you don't mention what VM system you have, yes.

Unity only recognizes as valid entries DNs that are already configured in something (Subscriber, call handler, etc).

Use a call system transfer if you need to transfer to non-vm users.

HTH

java

If this helps, please rate

www.cisco.com/go/pdihelpdesk

HTH

java

if this helps, please rate

Bradford Magnani
Cisco Employee
Cisco Employee

Hi Bill,

This is configurable on the Call Handler greetings page:

Hope that helps,

Brad

Thanks Brad, well that got me past the initial error. Now I get "You cannot be transferred to this number" 

Rob Huffman
Hall of Fame
Hall of Fame

Hi Bill,

I'll just add a link to the great info from Brad and Java (+5 each my friends!)

You'll want to look at the system transfers and system transfer restriction table

http://www.cisco.com/en/US/docs/voice_ip_comm/connection/7x/administration/guide/7xcucsag115.html

Cheers!

Rob

Confused by the directions, so I need to add the the first number of each DN followed by "???"  like "2???", "3???", "4??? ect and make sure "Blocked" is not checked? And do they need to be at the bottom of the list or at the top?

Here is the current config..

Thanks again!

Bill

Correct, or just uncheck row #4 that has the * listed to test, but that could be a security risk if you leave it that way for any period of time.

Brad

Rob to the rescue, +5!

You guys ROCK!! Thanks Rob and Brad that worked!

OK so its not working again. Yesterday it seemed to be working fine although I did not test from an internal line. After following your suggestions I got it to ring to the extension and I tested a few others that did not have Unity users (VM) and they worked fine too. As of some time between now and then when you call the main line from outside and then enter the extension it says "You cannot be transferred to this number, please check the number and try again". If I cdial the 4 digit extension from an internal line it puts me right into the Unity system, if I then try the extension again I get the same message "You cannot be transferred to this number, please check the number and try again".

Here is my line restrictions table.

Here is my Greeting config for my main (I assume) line

Any suggestions?

Thanks again!

Hi Bill,

The reason why it's failing is because you've got * set to be blocked, which is stating block everything.  * = all patterns  You can define as many patterns as you want but as long as * is blocked, nothing will work.  The default rules do a pretty good job of covering the common #'s you don't want users dialing.  There of course may be more specific patterns that you may want limited, but eventually the * needs to be unchecked - probably once you've defined all of the patterns you want blocked.

Brad

I thought by defining those patterns that I want to be unblocked this would allow them even though all other patterns are blocked by the * in pattern 12. So I should not block all other patterns other than the ones I have defined as blocked? So if I unblock all by using * then I don't even need to define the other unblocked patterns in have in 1 - 5 and pattern 7?

Thanks!

Bill

Adding to that I am pretty sure I never had * unblocked yesterday when it was working, but I could be wrong and you (Brad) even said before that unblocking all is a security risk in a previous post. I just want to make sure I don't screw up 

Keeping it unblocked can be a risk if you don't specify rules granular enough for your environment that you may not want being dialed, but I had just recommended doing it for testing purposes.  Rob is correct, the rules are matched top down, first match wins.

Really its just making sure no one can dial in and use our system to call out right?

Getting Started

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: