Hi all, is it possible to block some extensions from being accessible via the auto attendant? I want the users to be able to dial an extension if they know it, but there are some that they should not be able to dial. I would like to keep the extension that needs blocked in the same range of extensions that all other extensions are in. For example, all site extensions are in 1100-1199 range and I would like to keep the allowed and dis-allowed extensions in that range. Is there a way to block certain extensions from being available from the auto attendant?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
SV9100 - Make extension unavailable via auto attendant
- Thread starter chrismec
- Start date
- Thread starter
- #3
Thank you CoralTech. We are on INMAIL. So I guess the only option is to put those extensions into a different extension range and set inmail to not transfer in that range... Learning a new system is always fun : ) I've also just learned that you cannot dial the auto attendant from inside they system, only trunk lines can be routed to the auto attendant. Thank you for your advice CoralTech!
Hi all,
I dealt with a similar request.
We replaced the PABX from the original manufacturer MATRA (NeXspan), a technology that is about 30 years old.
The customer had an IVR (Automatic attendant) - 1 digit code attendant created on the system.
It was normal for the customer to be able to restrict the choice of the number to be called, to choose which callers can call and which cannot.
I asked the NEC solution manufacturer and was also told that this is not possible in the NEC Univerge SV9100 system.
In the end, the solution was to talk the customer out of the idea.
In my personal opinion, the absence of this feature in the NEC SV9100 PBX is very frustrating.
Thanks for the confirmation that even using INMAIL I am not able to reach this function.
Thank you CoralTech for explanation.
I dealt with a similar request.
We replaced the PABX from the original manufacturer MATRA (NeXspan), a technology that is about 30 years old.
The customer had an IVR (Automatic attendant) - 1 digit code attendant created on the system.
It was normal for the customer to be able to restrict the choice of the number to be called, to choose which callers can call and which cannot.
I asked the NEC solution manufacturer and was also told that this is not possible in the NEC Univerge SV9100 system.
In the end, the solution was to talk the customer out of the idea.
In my personal opinion, the absence of this feature in the NEC SV9100 PBX is very frustrating.
Thanks for the confirmation that even using INMAIL I am not able to reach this function.
Thank you CoralTech for explanation.
OzzieGeorge
Programmer
ok so I have never done this but it seems to me that there is a way to achieve this. My idea would be to send the option to a Virtual loopback (or group of them) then bring that in as did/s assign them as a group and allocate that group to it's own translation table then only translate the ones you want to work to the appropriate extensions and the rest to an announcement telling them it isn't possible. Is there a reason this wouldn't work?
answer for
Ozzie George
and
Coraltech
Your solution solves a situation related to the possibility of banning calls to specific offer numbers.
This means that:
For the sales department, choose 1
For the technical department, dial 2 We knew that.
The problem arises in a situation where the following is offered before the one-button offer: "If you know the number (extension) of the called party, dial his number"
This cannot be solved.
And that's what I was talking about in the previous thread.
Ozzie George
and
Coraltech
Your solution solves a situation related to the possibility of banning calls to specific offer numbers.
This means that:
For the sales department, choose 1
For the technical department, dial 2 We knew that.
The problem arises in a situation where the following is offered before the one-button offer: "If you know the number (extension) of the called party, dial his number"
This cannot be solved.
And that's what I was talking about in the previous thread.
It is interesting,
I believe it.
I don't know how you try. You have more experience than me.
So I have to think about how to set it up as you describe and try it out as well.
Don't have a configuration backup available?
It would help me a lot.
I believe it.
I don't know how you try. You have more experience than me.
So I have to think about how to set it up as you describe and try it out as well.
Don't have a configuration backup available?
It would help me a lot.
OzzieGeorge
Programmer
With my solution (I haven't set it up in the lab) you use the option that aligns with the first digit of your extension range to transfer to the virtual loopback and then (assuming 3 digit extn numbers) set the indial to 2 digits to translate and that is it. so for example if your extn range is 3xx set option 3 to the virtual loopbacks and then the last two digits are translated to achieve either a transfer to the extension of rejection. That said, If Coral tech has set his solution up in the lab and proved it works, I would suggest asking him to help further. (I am not going to be available for over a week as I am about to go on holiday to Bali! 
- Thread starter
- #13
Hello gentlemen,
I went through all your advice. Thank you very much for your advice.
I found in testing that your advice does not apply to my problem.
The setting of restrictions between individual groups of departments is clear to me and I understand it.
But what do I need?
Screenplay:
In the PBX, IVR is used, which is ensured by Auto Attenadnt 25-XX VRS/DISA Service.
We have a VRS Message destination set from an external number. (501) a voice message is recorded in this VRS: Hello, you have called the company XXX and if you know the employee's internal line number, dial his number (3-digit extension number.
The request thus refers to the fact that we need to ensure that in this case it is possible to set restrictions for specific internal extensions that cannot be dialed at the VRS 501 level, and vice versa to allow dialing for others.
It is not possible to work in department group programming for this scenario.
My question was related to the above from the beginning. Sorry for the imperfect explanation of my problem.
Do any of you have a solution?
I went through all your advice. Thank you very much for your advice.
I found in testing that your advice does not apply to my problem.
The setting of restrictions between individual groups of departments is clear to me and I understand it.
But what do I need?
Screenplay:
In the PBX, IVR is used, which is ensured by Auto Attenadnt 25-XX VRS/DISA Service.
We have a VRS Message destination set from an external number. (501) a voice message is recorded in this VRS: Hello, you have called the company XXX and if you know the employee's internal line number, dial his number (3-digit extension number.
The request thus refers to the fact that we need to ensure that in this case it is possible to set restrictions for specific internal extensions that cannot be dialed at the VRS 501 level, and vice versa to allow dialing for others.
It is not possible to work in department group programming for this scenario.
My question was related to the above from the beginning. Sorry for the imperfect explanation of my problem.
Do any of you have a solution?
Yes you're right.
According to the documentation available from the manufacturer, there is no problem using VRS as an Automatic Attendant.
The AA VRS feature in the PBX is specifically designed for this use.
Using INMAIL as a priority when requesting a simple IVR tree is unnecessary in terms of complexity.
But if INMAIL had the option of the function I was talking about, it would fundamentally change the situation.
The INMAIL function in PBX is certainly powerful, but I had no idea that it was necessary to use it even for small requests.
This means that VRS/AA/DISA is very imperfect.
If it is possible to achieve what you want using INMAIL, that's great.
According to the documentation available from the manufacturer, there is no problem using VRS as an Automatic Attendant.
The AA VRS feature in the PBX is specifically designed for this use.
Using INMAIL as a priority when requesting a simple IVR tree is unnecessary in terms of complexity.
But if INMAIL had the option of the function I was talking about, it would fundamentally change the situation.
The INMAIL function in PBX is certainly powerful, but I had no idea that it was necessary to use it even for small requests.
This means that VRS/AA/DISA is very imperfect.
If it is possible to achieve what you want using INMAIL, that's great.
Well, the VRS function is a VRS as opposed to an Auto Attendant. Frankly, I had no idea you could use the VRS like that until these forums. Seems like the VRS more of a work around the way you program it. I find the INMAIL WAY easier to use and program.
- Thread starter
- #18
CoralTech tech's suggestion worked like a charm. I'm on InMail for reference, and once I figured out that voicemail was in group 128, it was easy to setup.
Now a new problem though. Auto attendants at remote CCIS cabinets can access those numbers that are excluded locally. It seems the block needs to happen at the remote cabinet. Those remote cabinets should be able to dial the local extension, but it should not be available from their auto attendant. Is there anyway to do this?
Now a new problem though. Auto attendants at remote CCIS cabinets can access those numbers that are excluded locally. It seems the block needs to happen at the remote cabinet. Those remote cabinets should be able to dial the local extension, but it should not be available from their auto attendant. Is there anyway to do this?
- Thread starter
- #20
- Status
