UKenGB

What's the advantage of using a hunt group vs. multiple registrations to the same account/extension? IOW, when you have several phones that need to respond to the same incoming calls, you could either set them up on individual extensions and then place all those extensions in a hunt group, or you could simply register all those phones to the same single extension. What are the advantages and/or disadvantages of one method compared to the other. I can think of a few differences, but how do others view these alternatives?

SSH into the actual server is no problem, but with no idea why the PBX is refuses the connection request, it didn't help much:-( Do you mean the 'accesslist' folder? Is that where the PBX stores its blacklisted addresses, or is there some other way to find out what it thinks is blacklisted?

Why would that cause the browser to not be able to find the server? Would it not just generate a message to the effect that there was 'no permission' or something like that? I have no idea as I've never been blacklisted. Is this a PBX issue, or a server issue?

This is NOT a login problem. The browser just says "Cannot find server" (or some such wording). PBX was working prior to a S/W update of the server which required a restart, after which there is the above problem. The actual domain name being used is correctly resolved by the DNS and according to pbx.xml, the port setting has not changed. So the URL used to access the web interface has not changed, but is now not working. Strangely, the PBX is actually working, it's just that admin cannot access the web interface. Anyone ANY ideas on this. How can the PBX be running, yet its internal web server be apparently NOT running?

Simple. The change in the software that allows the shared mailbox messages to not be emailed also comes with a new configuration option to specify whether the messages for the 'sharing extensions' (50 and 60 in my case) should follow those extensions' email settings or not. Set the default to ensure nothing changes until that option is altered and no existing customers need to be upset. I'm a firm believer in providing the user with full configurability as no developer can ever predict what their customers will want. So give them the tools and let them get on with it. BTW, what will occur if the shared mailbox is set to email the messages and ALSO is set to allow access by other extensions?

Almost. Just forget 3. Oh and you'll need to ensure PIN access is OFF in the settings for the domain.

I don't entirely understand what you're saying there. Let me ask a simple question. Can I have personal voicemail (i.e. from calls to 50 and 60) emailed to their configured addresses, but messages for ext. 40 (the shared mailbox) to NOT be emailed and be available for 50 and 60 to access via the handset?

Unless I am misunderstanding you, that doesn't really fix it. Even though the sharing mailboxes (50 and 60) are set to email messages, since the shared mailbox (40) is set to NOT send emails, any messages to 40 should NOT be emailed, so 50 and 60 can pick them up using their extension phones (M9 handsets in my case). IOW, whether to email or not should be specified by the configuration of the extension whose mailbox took the message. At the moment, if the sharing extensions (50 and 60) are set to email, then ALL messages are emailed, even the shared ones. This is not only my issue, it doesn't really follow the apparent configuration settings. The way I am requesting, it is easy to distinguish between the messages since individual/personal messages are emailed, but joint/shared ones need to be accessed via the phone (and hence are truly shared messages).

OK, that's good news. So it IS shared. But I still have the problem with it being emailed. I have specified that messages for 60 get emailed. But messages for 40 (i.e. the shared mailbox) are also being emailed. However 40's config does NOT specify emailing its messages, so it would appear to be the MWI that triggers emailing of whatever message that initiated the MWI and that occurs with ALL other extensions that share this mailbox and since they then each receive a COPY of the message, we've lost the whole 'shared mailbox' concept. What I am trying to achieve and what seems entirely logical that many users would want the same, is for the individual extensions (i.e. 50 and 60 in my example) to have their own messages emailed, but messages in the shared mailbox (40) are NOT emailed and instead accessed from the phones which allows true sharing as we've now established. I realise this is currently impossible (I guess this comes down to snomONE's inability to distinguish between the 2 message types), but any chance we could achieve this in the future?

I see what's happening now. If a message is left for the shared mailbox (40) it is indeed sent to 60 (and maybe 50 too), but that extension is set to forward received messages by email, so the message received for 40 is simply emailed exactly the same as if it was a message for 60. As you say, there is no distinction. This is a problem on several counts. First of all, it indicates the messages to the shared mailbox are NOT shared, but simply duplicated to other mailboxes. This is NOT sharing, it is copying and doesn't allow for real message sharing. How does one recipient know what has been done by any other. So in my case, 60 might receive a message and act on it, then later 50 listens to it and acts on it again. The idea of a SHARED mailbox is precisely so this doesn't occur and in fact if you do want this, it can already be achieved with email. SO there's 2 ways to copy messages to multiple recipients and no way at all to truly share a mailbox. A shared mailbox should be just that. So in my case, if a message is left for 40, either 50 or 60 can listen to that message, deal with it as they wish and the result will be the same for the other recipient. So if 50 listens to the message, then it is no longer a new message for 60 and vice versa. If either deletes the message, it is also deleted for the other. It should work for the user just like IMAP mailboxes. Any chance we can have a true 'shared' mailbox?

The problem is that what you describe simply doesn't happen. I've disabled PIN at the domain level, so that's not a problem. I've set account(40) to "Allow Access for Extensions" field (50 & 60) But neither 50 nor 60 can access that shared mailbox in the manner you describe. If they dial 50 or 60 respectively, they simply access their own mailbox (which is as I believe it should be and it works fine). So how do they access the mailbox at 40? If they dial 40 it just rings extension 40 and if they dial 840, they are only given the option to leave a message. But this is standard behaviour for ANY extension dialling ANY OTHER extension's mailbox, so exactly what has "Allow Access for Extensions" done? As far I can see, nothing. So, how do 50 and 60 access 40's shared mailbox. Sounds simple but AFAICT, it cannot be done.

You realise of course that you are referring to 2 entirely different facilities? - Assigning an M9 handset to more than one M9 Identity - Registering more than one M9 Identity (or any other SIP client) to a single extension on the PBX (i.e. account on any SIP server) Mixing and matching the above is the job of the system provider/admin, to make the process transparent for the user and I agree it can be tricky. The important point is that the admin MUST have full control of the systems and that's where the problem currently lies. The simplest example of this is that once an M9 handset is assigned to more than one identity, the user has NO control over which Identity is actually used, which for outgoing calls can be a real problem. It's like a more traditional SIP client phone (e.g. Snom 3../8..) being registered to more than one extension, without being able to choose which to use for outgoing calls. How successfully could you sell that idea to a business user? I suspect not at all. Anyway, the idea of M9 handset naming and Identity control is covered elsewhere (different forum even). Which leaves the 'shared mailbox' issue of this topic that is still unresolved.

I am also still puzzled. My domain setting is to NOT require a PIN and if from my handset (whose main Identity is registered to ext 60) I dial 60 or 860, or press the RH softkey (marked VM and dials 860) I am taken to the main menu of my own mailbox which is all correct. But ext 40 is set for a shared mailbox with 'Allow Access for Extensions:' 60 and 50. My ext 60 is also assigned to the Identity which is registered to 40. I want to be able to retrieve messages from 40's mailbox. So first of all, from my handset I should be able to use Identity 40 to simply retrieve its own messages, but it is impossible with the M9 to choose an outgoing Identity (that would be a useful feature:-) so when I dial it will be from 60. But this is specified as being able to share 40's mailbox, so according to how it is configured, I think I should be able to dial 840 and retrieve the messages. However, I am just asked to leave a message as if I had dialled any other mailbox. IOW, having configured 40 to allow 60 access to its mailbox, in fact, 60 has NO more privilege to access the mailbox than any other extension. This is my main concern. AFAICT, it is impossible to access any such 'shared mailbox'. Happy to be proved wrong, but exactly what does 'Allow Access for Extensions: ' actually do. Currently it seems to do nothing.

Why do you say it's "hardly advisable"? For example I want 2 users, each with their own extension AND a shared extension, to be able to receive by email VM messages to their own extension, but to be able to easily listen to messages for the shared extension via the handset. Each of the 2 handsets (I'm using an M9 here) is registered to 2 Identities, each of which is registered to a suitable extension, i.e. a personal one for each and the shared one. The personal VM is emailed ok, but how can the handsets dial in to listen to the VM messages for the shared extension? Even though the handsets are 'assigned' to the Identity that registers to that shared extension, I cannot find a way to listen to those messages. The 'main' Identity of each handset is the personal one (that's the only way to ensure they call from the personal number and display the correct name - maybe we could improve that in the future:-) and those extensions are listed in the shared extension's "Allow Access for Extensions:" setting. So My understanding would be that those handsets should be able to simply listen to that shared extension's VM WITHOUT having to enter any PIN. Isn't that the whole point of entering other extension numbers in "Allow Access for Extensions:". Otherwise, what's the point?

Just tried both accounts again and this time they are BOTH giving 'Loop Detected' errors. Irrespective of which account the PBX chooses to fail or not, what is causing this? What do the log files tell us?

Everything for 'Ken' and for 'Cathy' is identical, apart from the obvious. For each there is an account with the VOIP provider, a Trunk, an Extension and a Dial Plan. You're right, with 'Loop Detection' turned on, it does still report that as the problem, but why does it still fail when it's turned off? This morning I checked again and find that the success/failure situation has reversed. Previously it seemed quite reliable that my number worked, but Cathy's did not. Now, Cathy's is working and mine is not. Whichever the PBX decides to fail, it then seems seems quite consistent for some time, but at some point it can switch. So this would indicate it is not related to any configuration differences between the accounts. I have been trying out some Dial Plan changes and had thought that this might somehow be involved, but I switched both Extensions to the default Dial Plan and nothing changed. So it's not that. However, why does it report "Dial Plan not found"? When is it looking for a DP? That's only involved when the call is initiated and it works because the correct Trunk is used. So the question remains, why does it consistently have a problem with one account, but not the other - even when 'Loop Detection' is OFF? I am sure that this problem did not exist originally, but the latest update has introduced some instability (see earlier post) and this is beginning to look like a bug has been introduced.

They should be attached to this post. failure.txt success.txt

Back to the original problem, but it's no longer reporting 'Loop Detected'. One of the Trunks is still causing grief. If I call the VOIP number to which the trunk is registered, I get 'unobtainable'. But if I call the Hunt Group to which the Trunk is directed, or any of the extensions in that Hunt Group, the call works as expected. Why is the call to the external VOIP number failing? I have another account which should be identical to this and also another which may differ slightly and I can call both of them from any extension and it works. There is just this problem Trunk. If I call the same external VOIP number from outside the LAN i.e. the call going direct to my VOIP provider and not out via the PBX (I've tried from other PSTN number, or VOIP number or mobile) it works. The problem only manifests itself when calling this Trunk's VOIP number, from INSIDE the PBX. I turned off 'Loopback detection:' as suggested and it made NO difference. I've got the logfile entires from both calls, i.e. when it succeeds for one Trunk but fails for the other (in fact each is calling the other). Where can I best send these for you to have a look at? They're both identical initially, but then there's a small divergence, but it's not clear to me where the problem is occurring.

I'm wondering if that 'Loop Detected' problem is related to my VOIP provider. I'll have to check with them. But I have now experienced what looks more like a snomONE problem. All registrations appeared normal and correct and I could dial out using either of the 2 SIP Trunks, but incoming calls to those numbers indicated they were 'unobtainable'. In the end I stopped the PBX, waited a minute and re-started. Incoming calls now work again as they should. But, was this a PBX problem or some issue with my VOIP provider which cleared once the Trunk registrations were dropped and then re-registered? Either way, this is a bit of a big deal since although everything looked correct, in fact incoming calls were failing completely with NO notifications being generated that this was occurring. As I said, this is a fundamental part of a PBX, calls failing silently is no good at all. Anyone comment on whether this is likely to be PBX or VOIP provider related?

There is a Number which is used when you need to address that account and also a Name that I thought was just to visually identify the account. Some of my accounts already have names that contain spaces, but I see no indication that it thinks these are 2 different names. In any case, I didn't think you could use these Names when addressing the account. Am I wrong? What do you mean by "put a space between the names"? Another unsettling fact about all this is that the docs CLEARLY show a separate field for the Alias, but you are now suggesting it needs to be created in some 'secret' manner that is NOT in the docs. So first of all, haw are we supposed to find out about these procedures when we're so definitively wrongfooted by the documentation and also, why would you change the interface to hide the Alias and make it difficult in this way?

Yes, I can appreciate all that, but it doesn't answer my question. Since the 2 accounts are with the same VOIP provider and the PBX is apparently set up identically for both accounts, why do I get this problem with just one of the accounts and NOT the other? As I said, could it be a PBX issue or is it likely/possible that it's my provider?

Sounds like a plan. How would I do that? The manual shows that an account page should display an Alias field, but it doesn't for me so I cannot see how to add an alias name to an account. Is there some sort of arcane ritual I need to conduct to allow me to add an alias?

Here's my 'motivation' for wanting to re-direct to multiple extensions and/or a Hunt Group. I want to set up a simple and easy to remember number that can be used to call everyone, I.e. All extensions. The actual extension or Hunt Group numbers are likely to have been created to fit into a numbering plan and hence not obviously easy to remember. But the dial plan could be used to to allow a simple memorable number to be dialled and that to be re-directed to the appropriate destinations. But to do that I really need to be able to send it to multiple extensions, or a Hunt Group. In fact it is inconsistent that in this instance you cannot do either since elsewhere in the PBX config the use of extension or Hunt Group number seems interchangeable and multiple extensions are allowed. What are the chance of this being included? The basic feature to 'Call Extension' is there, it just needs tweaking to allow what I need.

Yes, but the 2 accounts are (as far as I can tell) identical, so why do I get this problem when calling one but not the other? What are the circumstances that might trigger the error? Is it possible I have unknowingly introduced some variation into the configuration, or is the PBX somehow screwing up, or is it possible my VOIP provider is somehow causing it?

I have 2 accounts with my VOIP provider (each with their own external number of course) and snomONE is configured to have 2 each (identical matching) Trunks, Hunt Groups and Extensions (and Dial Plans). Nothing should be shared. They should both behave identically and you can ring the either's Hunt Group or extension number directly and it all works as it should. In fact calling either external number from anywhere except out through the PBX produces the correct results for both accounts. But, I am now finding (no idea when it started) that if I try to call one of those (external) numbers out through the PBX, the call fails with a reported "482 Loop Detected", although calling the other number in an identical way works PERFECTLY. This has me very puzzled since both these accounts ought to behave exactly the same, they use all the same settings (apart from the obvious) and there is no forwarding configured. I simply cannot see why it might think the same call is traversing the trunk in both directions simultaneously. What could be causing one of them to fail in this way?