But why would a true user give out their extension an pin to someone they don't know?
Maybe I didn't spell it out clearly.
User (any, known or unknown) comes into the conference bridge. "Please enter your room number"
Known User -> Enters Number -> Room Created or enters room if already exists. Basically, as is now. (The system should be able to see that this is coming from internal and distinguish between an outside call and an inside call, right?)
Unknown User-> Enters Number -> Room Exists -> Unknown user enters room
Unknown User-> Enters Number -> Room Doesn't Exist -> Sorry, that room does not exist
Unknown User user should be able to press * for "more options" at any time just like the VoiceMail system and can then be given a submenu of commands one of which is basically "log in and create a room"
"Press Star for more options" -> "Press 1 to log in and create a room", "Press 0 to be directed back to the operator"
I'm not pretending to know the complexity of programming behind the scenes, so please don't read this like I'm intentionally trying to make light of what is probably a major programming change. I'm just saying, in my head, this is how I imagine it working. In my head I imagine that:
The Conference Bridge program knows the ID of the connecting caller.
The Conference Bridge already has access to the user database.
Armed with just those two items the Conference Bridge should be able to handle pretty basic security.
The only reason I really need to put a DID on our Bridge is because we are only open xx hours per day and a lot of activity does happen after hours. So there is nobody here to transfer an incoming call to the Bridge.
Again, I'm not trying to be snarky, or anything. Just thinking out loud on ways to improve on a pretty stellar product.
I guess I’m kind of confused. At first you were talking about security and then now you’re talking about letting unknown users in. Which one do you want? Security to block out unknown users or to allow unknown users?
We are able to currently do this:
Detect known user on system, but we will force them to enter their VM pin, anyone could call from their phone so we verify it is them by their VM pin, then we dump them into bridge.
If unknown user, then you can have many options, you can configure it to where you deny them or prompt them for id in bridge or transfer them to receptions. Lots of things we can do in the service editor.
I can't really outline it much better. The absence of a user account is still a security condition and that condition is the unknown user can enter a room but cannot start one.
Exactly like this forum. An unknown user can still come in and enter the forum, but a known user can actually post. It's the same concept. An unknown caller should be able to enter a room, but cannot actually start one.
That's about as good of an explanation as I can give at this point.
What your saying doesn’t really make sense. A conference bridge is not like a forum. Why you would want to allow an unknown user to enter a room, if they are in a room, then the room has already been started.
If you want to submit this as a feature request, than you can post it here under the “NetVanta Unified Communications” thread and let other people vote on it.
If you have any other questions you can post it here.
Thanks mark. I don't know how I could explain it any better. A non identified user should not be able to create a meeting room. That's about as basic as I can get. I'll post it over there.
There are ways with a "service" to apply security. It's not perfect, but it gives you some ways to do it. Thanks for adding the feature request.
Here is a quick, basic, example.
also, using the database functionality of the server, you could do database lookup and compares, and even change passwords in the database.
Mark may have better examples.
Edit: "gather digits 1" is to get a PIN# (not a bridge number)
Thanks Glen for the example. While this would *work* it just pins all incoming callers to conference 1235 and if it doesn't exist, allows them to create the conference. I hope I'm getting my point across that this is very insecure. The default behavior should always be deny unless the caller is somehow known.
The Conference Bridge will work for what I need it to do for my current task, but I was hoping to use it to replace GoToMeeting (we really only use for voice) or FreeConferenceCall.com which we use regularly.
It was just a quick example. I agree we need more features here. That's where your feature request helps.
I recommend other readers vote on it at https://supportforums.adtran.com/ideas/1012
"Gather digits 1" was for a Pin, not a bridge, in case that wasn't clear.
The example was "pinned" to one bridge number in order to prevent an external user from authenticating and then picking their own random bridge number to start. It doesn't have to be that way.
They would not be able to enter the bridge without the pin. but yes, the bridge opens when the 1st authenticated attendee arrives, it doesn't require an owner to open it.
You could add a database for admins with programmable passwords, and prompt the internal user for the bridge and to set the pin/password for that specific bridge every time he/she opens the bridge.
the admin could also set that pin in advance of the call. you could even set up a separate service for setting the pin instead of doing it while opening the call.
External callers would not get the same prompts as internal users, and external users would need to know the pin to enter the bridge.
The downside would be that that pin would be present after the call, so either a scheduled dB job would need to clear it, or the owner would need to manually change the pin after the call (I bet a low % would)
...just thinking out loud.