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 strongm 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

Status
Not open for further replies.

chrismec

Programmer
Mar 12, 2018
40
US
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?
 
Depends on the voicemail. If INMAIL the answer is no, BUT you can go into the voicemail box for that extension and make it AA direct to voicemail so they cannot ring that ext.
 
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!
 
Well, you can actually but you need to setup and virtual loopback. The good thing about setting up a range of extension that can't be dialed is that you will know just by looking what those are.
 
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.
 
Ok, I set this up in lab. Make a dept group for these extensions to be in. Then, in the inmail dept group restrict that group from being dialed.
 
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.
 
Sorry, not seeing your logic here. If you are making these groups VE then the transfer is set on that dept group setting of that VE. My solution stops the caller from dialing through. I set this up in a lab..it works.
 
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.
 
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! :)
 
16-02 assign a department group you want to restrict extensions.

16-04 go to dept group of your vm and assign that dept group number

 
dept group of your vm? My apologies, I am very green on NEC. We have a single auto attendant which is handle by InMail from what I understand. Is there a way to make this work with this configuration?
 
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?


 
Ah, this is a case of using the VRS as an auto attendant. SV9100 has an auto attendant. In the US the INMAIL comes with 16 ports activated.
 
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.
 
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.
 
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?
 
Each site is 1X00-1X99, with each X being a different remote site.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top