Vodia PBX

1) We had that in an older version and will bring that back 2) Usually you dial 00 or 011, but this is a good point 3) You can redirect users into conference rooms (even through attended transfer); we will sugarcoat this eventually. Hosting an audio conference on the phone itself is usually not a good idea. 4) Yes that is another topic that will eventually be available.

1) That is why they can enter it directly into the web interface - stripe takes actually care about the CC number and the sensitive information and this information never hits the PBX or any of our or your servers. They can also enter it into stripe.com however this is not easy. 2) That is true. One solution could be to lock everything down, so that the may be able to see e.g. the call logs, but make no changes. 1) You can do that, however this would require that you set up another web server. With the REST API you can set the stripe subscription ID into the PBX, so that the PBX can check if the subscription is still active and e.g. shut the domain if that is not the case. Might be interesting for the automatic charge function when their prepaid credit falls below the reload number. 2) That would be just a simple change of the template for the billing page (dom_billing).

I agree one avenue is to do this locally on the phone. This will give you 100 % control. Try to use the snom general parameter, then you don't have to change the template for provisioning. And if you have to change it, change it only for this extension. The other thought is to set the extension to type "hotel room" - this also limits the features and you can e.g. define if rooms are allowed to call each other directly.

There is a list of SIP User agents that are rejected - this should include SipVicious. Another simple thing you can do is to give the PBX a real domain name (not "localhost") and then block any request that does not match the domain name. This is a little bit like a password that can very effectively block such attempts. This makes a lot of sense if you are on public IP.

The default behavior is not to hang up. Which is kind of reasonable - especially a short timeout would be unreasonable.

That would be a scenario where something fishy was going on - for example a device was trying to start a call but could not get past the authentication phase. If the IP address of the source was blacklisted because of this the admin would get an email notification about this (important) event.

Ahhh yes very good point. We have the same problem when all agents are suddenly logged out. We will add something that will do the redirection also to the calls that are queued up if the redirection flag is set.

We have that problem in many places of the we front end and we are aware that this is an issue. Default so far means "reasonable" - if you want something specific you'll have to select it from the drop down.

In the redirection settings (night mode) for the ACD there is a dropdown called "No agent has phone registered" - just use that one. You can use the mailbox prefix (usually "8") to send the call directly to the mailbox without ringing the extension.

We need two background image set - for dark background and for light background. Most phones have a fixed scheme (Cisco 88xx figures this out automatically) where only dark or light images look good. That is why we require uploading different background images or choosing different background colors. If you don't upload the images the save button will be disabled. BTW it seems that this is also becoming the norm for cell phones where the app designers also need to deal with night mode.

Not sure if this is obvious - as long as you can hit the Vodia voicemail somehow you just enter your PIN code and then you can listen to you messages. BTW this is another reason not to use 0000 or 1234 as PIN code.

It will not be too long - we have some important feature updates that we need to release for the mobile apps anyway.

Second thoughts. When we send the QR code to the user cell phone inbox, it is useless unless that user takes a photo from the mirror! There must be an easier way where we can send the link to the play store that includes the credentials. If the user's email is the gmail account we can use that for authenticating the user.

OK I guess the best solution is to offer the QR code email campaign and leave this topic to the system admin.

If the PBX keep blacklisting the address there must be something wrong. How many attempts does it tolerate? Maybe that number was set accidentally to low? Usually the automatic blacklisting does not require any attention, also when Grandstream devices are in use. We had a case where a Grandstream had a wrong password stored and it would immediately after being rejected try again, generating something around 100 requests per second. That did cause automatic blacklisting - the solution was to set the right password and everything was fine.

Paper makes sense in some environments, e.g. teachers that get paper everyday anyway. But I agree, in other environments it is not practical at all. But there are other ways as well - first of all the goal should be that you don't have to distribute any passwords at all. If customers use Google email addresses, then you can use them for logging in without a password at all. This is also possible with Facebook accounts, LinkedIn accounts and also (though not very popular) with Office 365 accounts. Our feeling is that we should do Office 365 next. As for the QR codes, I am not even sure if it would be okay to send the images in emails. It might be unreadable for humans, but for robots QR codes are very easy to read. Maybe we'll leave this decision to the admins - a trade off between security and practicality.

I would check if the URL <custom_bg_image_url> is set to something that makes sense. If you load a SVG into the domain portal, it should automatically generate something that is useful for the 785. On of the big challenges with the snom is that it keeps the background image across all screens, so that even when you dial a number it is still there and it is very hard to come up with an image that looks reasonably good everywhere. That is why we use a "watermark" image with the logo very faint. If anybody has a better idea we would be open to it.

Generally speaking, passwords should be (and mostly are) write-only parameters. It can be a problem if passwords leak out, especially by email; that is why we took the passwords out of the welcome emails. So you would have to set the password as admin and then have a way to pass it to the user - preferably not with an email

Ok we made a fresh 64.1 beta image - which should include that feature on domain level. User level will be added at a later point.

Hmm indeed - not sure but it seems it did not make it into the build process yet. What OS are you on?

Ok the address book feature is now in version 64.1 available as a beta (currently CentOS64, Debian64 and IOP/Raspberry Pi)

Set the ANI for the Agent Groups - then log into one of them and (by default) it should then use that ANI for the call. Check the logs on how this is passed to the trunk. By default the {from} pattern in the trunk will use this ANI.

Branding means that they present a certain caller-ID for outbound calls (ANI)? That is for sure possible. There are many ways to achieve this, depending on what they need. Inbound is relatively easy - all they will need is to assign DID numbers to the extension. In 64, there is a new page specially for this task.

A reason could be that the ringback WAV file went missing for whatever reason or a country for the tones was selected that is not present on the system. I assume that calling e.g. the mailbox works fine?

I agree. Maybe we'll just add a way for the admin to enable showing intercom "ring tones".Then this will work with every phone model without having to change any template file. Adding a ring tone selector to the address book is also a good idea. Workaround for today is to set up a hunt group, make the extension the only member of that hunt group, change the ringtones.xml template, change the ringtone for that hunt group to the changed entry and have the ACD call the hunt group instead of the extension.