GregV

Hi Support, The main issue here is the user cannot disable the Hot Desking using the *70 star code (i.e. return the handset to its own extension) When you try, the system does states that Hot Desking is disabled, but the system doesn't actually disable it. The Extension remains Hot Desked. I'm asking if I'm following the correct procedure to return an extension to its own original extension number. I'm running Vodia 66.0.6 Below is where the user can see if their Extension is Hot Desked to another extension . This is found by logging into the Web Interface of the Vodia PBX as the extension (user level), Clicking the extension on top right, Click Settings, Click the three dots, click preferences. It can also be found at the domain level under the users extension / redirection / Hot Desking at

I'm running Vodia 66.0.6 I have an issue with disabling Hot Desking. To enable Hot Desking the user goes to another extension, calls *70, enters their extension number, enters their PIN, a confirmation is heard "Service is active" and the phone reboots. This works. Now the problem; To reverse the process, the user calls *70 from the same extention, enters the original extension number of the handset, confirmation is heard "Service is inactive", however the hot desking is still in place despite the confirmation. If the user logs into their extension using their web browser, then can see that their extension is still Hot Desked. Can you advise if this the correct procedure to follow for disabling hot desking?

In Australia we rarely hyphenate numbers.. We generally space the numbers out or have no spaces at all. Most SIP carriers present calls with 11 digits including our country code (61). This is then followed by the area code (single digit) then the number (8 digits) Here is the chart; Starts with Replaced with Display format Use 614 04 04xx xxx xxx Mobiles 612 02 02 xxxx xxxx NSW 613 03 03 xxxx xxxx Victoria 615 05 05 xxxx xxxx Mobiles (future) 616 06 06 xxxx xxxx Future use 617 07 07 xxxx xxxx Queensland 618 08 08 xxxx xxxx WA, SA, NT 619 09 09 xxxx xxxx Future use 611300 1300 1300 xxx xxx Inbound Service 613 13 13 xx xx Inbound Service 611800 1800 1800 xxx xxx Inbound Service However it would be nice to have a toggle option that allows the system admin to choose if they want the spaces / hyphens included in the formatting. For me, I like that Vodia does the localizing of the number from 61x to 0x, but I don't like the hypens, so I'd opt to have no hyphens and no spaces, but keep the localization of the format. I tried removing the country code at the domain level, and this delivered the desired result in that the system no longer included hypehens or spaces, in the numbers, however it then also didn't do the localizing of the number in replacing the 61x with 0x and this meant the caller ID on the handsets displayed 61 as well which confuses users as most Australian users are not use to seeing a number starting with 61.

Country code is 61 - Australia. I like how it replaces the +61 with 0. That does help the readability. But the dashes do not. Is there anyway to modify the way the system localises numbers based on country code?

I'm running version 66.0.6 (Debian64) I'm finding the PBX is adding hypens to the CID of inbound calling numbers. e.g. 0291237744 is converted to 02-9123-7744 Hypehens are added to mobile numbers e.g. 0499999999 to 0499-999-999 The hypehs are not present in the SIP INVITE. Also when adding an entry to the Domain Address Book, hyphens are added to the numbers you add. Please advise how to remove this? Thank you. ----issued resolved... remove country code from domain general settings

Service provider Vonex have advised that having this to work is a feature request and not a bug fix. I have directed them to the only manual where it states the feature exists. https://doc.vodia.com/serviceflags Calling a Service Flag "Both in automatic and manual mode, the state of the service flag can be changed from the phone (since version 5.4.2)." Can you please clarify if this is a bug or a feature request so I can inform Vonex to as they seem to be wanting to fob this off. Its a very simple feature, however its important for clients to be able to take their system out of night mode easily if they happen to arrive into work early or on a weekend. Greg

Ok, I'll advise the Service Provider Vonex in Australia to do this and will advise.

Ok, thank you. Would also be nice if the software still completed the intended function, even if the audio files are missing. In this case the feature is broken over missing audio files which is annoying.

Thank you, as I have several (approx 25) client's being effected by this, are you able to advise when the next release will be available so I can set their expectations.

Our PBX provider has advised there is a bug in the Vodia software, which prevents a user from using a function key assigned to an Automatic Service Flag, to manually set / clear the flag. We use a service flag for day / night mode. We have it set to automatic (9am to 5pm Weekdays = CLEAR / 5pm to 9am & Saturday, Sunday = SET) We have this Service Flag assigned to a function key on the SNOM handsets using the buttons profile. Occasionally when staff work back or get into work early, or are on a lunch break / meeting, they will want to override the service flag. They should be able to do this by simply pressing the function key of that service flag to toggle it from CLEAR <-> SET However when they do this, instead of the service flag toggling, they get an erroneous voice message saying "Press 1 press 2 press 4". Our PBX provider has told us that this isn't their problem, and that its an issue with the Vodia software. Can you please; 1> Confirm if this is a known bug 2> Advise when it will be rectified 3> Advise if there is a feasible work around to this issue Thank you. Greg

Sadly out PBX provider will not give us direct access to these log files. All we have is what is available through the PBX. If there any other "inventive" way you can think of as to how we might be able to get these stats? Could we include a something in the hunt groups that would register on the daily CDR?

We are using a Vodia PBX provider operating Vodia-PBX/57.3.4. We would like get a report on what Auto Attendant option our callers have selected in the month. We have a very simple setup. Incoming calls are answered by the Auto Attendant and the callers are given two options. Option 1 will ring Hunt Group 1 Option 2 will ring Hunt Group 2 We wish to gather statistics on a monthly basis of how many callers pressed option 1 and how many callers pressed option 2, and how many callers hung up out of bewilderment (though the hang up stat is not an essential requirement) I'm looking for guidance on the best way to achieve these statistics. The Daily CDR report doesn't seem to provide the information I need and is daily, not monthly. I would also be happy to employ a third party reporting software, but need assistance on which one will provide the stats I need. I am of course hoping the PBX can provide the stats for me without third party software licensing costs. Thank you. Greg

Are you suggesting the user dials a prefix before the number? For example to dial 0299991234 on trunk 1 they would prefix with 99 so the complete number would be 990299991234 and to dial out on trunk 2 they would dial prefix 98 making the complete number dialed 980299991234? The issue with this is the handsets then don't match up CallerID to incoming calling number presentation. Also clients who I have set this up for in the past complain the number is the redial list is not easy to read at a glance. Was hoping for a less tech way and more practical user friendly way, such as "Select Trunk" then dial number. Was looking for any ideas on how this might be able to be achieved. Maybe there is no way and this may be just a limitation of the PBX. With legacy key phone systems the user would select the line and then dial the number, hence giving them easy control over what number they dial out on. I'm not wanting to go back to the dark ages of key systems, but it would be nice to have in the IP world an easy way for users to select on what trunk they wish to use, then dial the number. Would Co Lines be an options? I've read these do not work so well. All opinions and ideas welcome. Thanks, Greg

Vodia, I have a client two trunks, each with their own number. At time of call, client wishes to be able to easily select what trunk they call out on, so the CID is displayed to the recipient correctly. This is actually a common requirement as many companies these days have multiple numbers they wish to use to dial out on depending on the context of the call. I can see many ways of achieving this using individual Service Flags and trunks or pre-dial codes. I'd prefer not to use predial codes, as this makes for confusion with Call history presentation and people forget to dial the precode. My preferred option would be to use two functions keys. The one lit red would indicate the trunk that would be used when that handset makes a call. Ideally when the other function key is pressed, it would go red and the other would turn off. they would toggle. Same as radio buttons do. Not sure how I would easily achieve this though (on a per handset basis). Thoughts and ideas appreciated. Greg

I have a client who would like to add their cell phones (mobiles) into a Vodia PBX hunt group. They would like the cell phones to ring and if no one answers after 20 seconds, the hunt group would transfer the call to a company voicemail box. Problem is they all have voicemail on their cell phones too and if a cell phone is switched off, the call goes direct to that cell voicemail. When that happens, the PBX considers the call as being answered and therefore stops the hunt group ringing and the call never fails over to the company voicemail. I have dealt with this problem before with other IP PBX systems,. They solved the problem by introducing an option you could enable of the hunt group, where the cell phone user would have to answer the call and press "1" to confirm they want to take the call. This worked very well and meant calls never got trapped in a cell phone voicemail. What is Vodia's approach to this problem? Greg