[stuart.rendall]

For small businesses, it would be particularly useful if there was a main or central voicemail, that would notify and be accessible to all extensions.

i.e. In our workplace, the ultimate fallback (both in and out of hours) is for the caller to leave a voicemail (to the company, as opposed to a particular extension). As it is unpredictable who will be present on any day, it may be the case that the extension of the received messages will not be activated and hence not checked.

[leejor]

This sort of feature has been requested in the past, see...general-voicemail-boxes-13279.html#p70813

[salter]

Well I'm all for the implementation mentioned towards the end of that post you referenced. Lets lobby for this for version 10! (I say 10 because lets face it - v9 is in beta and is likely as feature packed as it will get - they're mostly just bug-fixing right now...)

[KerryG]

You could do this today with multiple extensions on phones and things like that. I really am opposed to having multiple voicemail boxes that someone has to check. Why not use voicemail to email and send it to a group account, or have a lobby phone extension set for the group voicemail so you see an indicator, or just have an extension that everyone is supposed to check in the morning. Since this request requires some non-standard methodology I would push to use some other notification method rather than a new feature.

[comresource]

We use the multiple extension method and while it works pretty good on specific phones (Polycom, Aastra) which launch a messaging 'app' showing which mailboxes have mail it limits you on what hardware you can recommend.

Another idea would be to have a 3CX option to tag an extension as a group mailbox and then add phones to those groups. When a user from a group member checks voicemail the system could just tell them they have mail for a particular group.

"You have 1 New Message"
"Group Mailbox 1 has 2 New Messages"
"Group Mailbox 2 has 1 New Message"
"Select 1 for new messages"
"Select 2 for saved messages"
"Select 4 for Group Mailbox Management"

ect..ect

This would make things a bit more phone agnostic.

[salter]

Kerry - I agree multiple voicemail boxes can be a pain - I'm talking about the implementation that was described towards the end of that thread - that you (in that thread) actually said you could get behind.

[KerryG]

My only concern about that is that the implementation is still non-standard. If they can pull it off, then great, but it requires that under the hood the system is not giving accurate information to the endpoint. For example, what does the 3CX assistant see for the number of voicemails? The ones in MY mailbox, or the combined ones? Ideally I could have a line key or dss key on the phone subscribed to another voicemail account but I dont think any device available today supports that.

[salter]

I would suggest that 3cxAssistant would have to be adapted to show X vm in my box and Y vm in other boxes to which I am subscribed.

Here's another thought, Kerry - What if they did something like this:

3cx treats the queue like a regular extension for "SUBSCRIBE" purposes. In 3cx, you could specify that on a voicemail, give a "busy" status for that extension. SIP phones would SUBSCRIBE to it like any other extension and display appropriately on the phone. Your thoughts?

[KerryG]

Again, that feel very non-standard in terms of SIP standards. Even having it in the 3CX Assistant would mean more manual configuration of the Assistant since you are suggesting a client side configuration and not a PBX side configuration.

Any of this just seems like a lot of development for a very very small segment of people that dont want their own individual voicemail. If all you need is something this small, why not go buy an answering machine for $29? Or heck, drop an answering machine on an ATA for this purpose.

[salter]

Actually - I am not suggesting 3cx Assistant be manually configured on the client end... I would see this as being configured on the 3cx server end and the 3cx Assistant just load the information from the server. I imagine someone being a part of a queue as they can be now and as part of that queue, they would have access to the shared voicemail for that queue.

Also - while I appreciate the suggestion of an ATA with an answering machine, we both know that would not suffice or even come close to some of the other options available from traditional PBXs. This isn't necessarily about eliminating individual voicemail boxes. This is about bringing 3cx up to the standard of traditional PBXs (and even one pseudo-voip pbx I know of) in ONE regard in which it is lacking. I'm not saying it is lacking overall - Far from it. But there are features that traditional PBXs provide that OUR CUSTOMERS (maybe not YOUR customers - but OUR CUSTOMERS) ask for. They need general "sales" or "technical support" mailboxes that can be accessed by any member of the sales or tech support groups. I see this as implemented on a ring-group or queue basis.

As far as "non-standard" in sip terms - whats non standard? I'm seriously talking about subscribing to an extension's updates just like any regular (ie phone-connected) extension.

SIP NOTIFY can include a message waiting event per rfc3842.

So again I ask - where is this non-standard in SIP terms?

Again- this isn't about eliminating individual voicemail boxes. FAR FROM IT - I still want my mailbox. I still want my people to have their mailboxes. I just want another option too... so that calls for our "sales" queue don't just go to someone's personal mailbox. Maybe they're out of town this week.... or super-busy with clients. The WHOLE team (or at least a few people on the team) need to be able to access that vm.

[KerryG]

Its non-standard in that a ring group or queue isn't an extension. You CAN use some phones today like a Cisco SPA5xx and if you have one of the line keys configured as a different extension then you can have a visual indication next to the line key of which line has voicemail waiting.

The only thing really missing from those phones that work the way I just described (and there may be one that does) is that when you hit the voicemail button on the phone, it prompts you which voicemail box to log into.

This seems like it would be far easier for the phone manufacturers to implement since the endpoints are already getting the message waiting messages and could easily control this.

[leejor]

Is SIP not (and I'm putting this in simple terms) not a set of standardized "commands" (messages) send across a network to accomplish a "task", ring a set, activate MWI, call a number, acknowledge a message? What you do with these commands should be up to the PBX designer using them to accomplish what they want, actually , what the customer wants. How you "make" a feature work, given a set of "rules" that SIP devices can understand, should be up to the developer. Am I incorrect in this assumption?

And, really, all this suggestion does is to make use of standard SIP features, activating and deactivating a message indicator at a set. In this case it happens to be a member of a hunt group that "owns" a mailbox, and the MWI is to be sent to more than one set. If a PBX developer can't come up with new features such as this because, for some reason, they are considered "non-standard" then every VoIP PBX would have exactly the same functions/features, no more , no less. Because , heaven forbid, a feature, handled by the PBX, is different from what some others are doing.

I'll get down off my soapbox now.