Vodia PBX

Well you can always look into the IVR node. But maybe the auto attendant already does what you need. After picking up the call, you could still transfer the call into a IVR node. Not sure what you are trying to achieve, but you might also look into the generic CRM integration logic.

I would turn on the logging for SIP call packets and take a look at the INVITE. The provider must somehow be able to see what privacy policy should be used.

You can have him press "1" to confirm he is human and take the call. This is in /dom_ext2.htm (Offer special menu when call is answered on cell phone).

Tis heavily depends on the trunk provider that you are using. There is a RFC for that (RFC 5379 if you are interested). Are you using a trunk provider from the drop down menu? IF it is not set up correctly, it would be great if we can adjust the template with the right settings.

Well SIP and FAX have in common that interoperability is challenging. If the switch to T.38 works, that is already a huge help as it reduces the problems with modems. We are still finding FAX bugs and areas of improvements, and we simply need to sit down and go through the details. That being said, the next version (will be 68.0.10) will be able to generate PCAP for the trunk-to-mailbox call which should make troubleshooting even easier. Those PCAP should be attached to a ticket in the support system.

They are deleted when the CDR gets deleted. Apart from that, you can always just delete them from the file system.

What you could do is put into the SLA that a tenant can store so-and-so many minutes of recordings for so-and-so many days. The PBX will make sure that the days are enforced. You can check from time to time if your hard drive is getting too full, which is generally a good idea. In that case contact the tenant (I would not delete it right away). But I think it will happen only in exceptional cases where you will also see a huge amount of calls for that tenant. There are many file systems available today that take care about pushing content somewhere into the cloud. All you need to do is make a symbolic link of the recordings directory or even the tenant recordings directory to one of those file systems. One TB should cost around 30 USD per year, which can store 2 million minutes if I did the math correctly. To put this into perspective at a hourly rate of 10 USD that would be roughly 300 K USD worth of salary. So the storage cost would be 0.01 percent of the agent cost.

Right now it is only turned on when a registered extension is involved in the call. Alternatively you could turn the PCAP recording on for the trunk.

Right now we have the limitation per call I mentioned above and the duration how long the call recordings are stored. In most cases we have see the requirement to keep the recordings for so-and-so many days, no matter how many calls or total minutes that tenants was using. That is why we have the setting for each tenant. Many clients have the legal requirements for example to store calls for 90 days. They would be upset if recordings are deleted because of space limitations.

There is only a maximum duration for call recordings which is a system setting.

We'll make sure that will find its way into the next version (69).

If you use the MAC address for authentication then you also need to use the MAC password for that MAC address. You can see that in the "VoIP phones" page. Alternatively, use the account name and the SIP password like you would register a soft phone.

This device is using a different code base than the other snom phones. The PBX don't automatically provision this phone. However because there are no buttons to configure the setup from the web browser is straightforward and if you install only one phone this should take just a few minutes.

The login information is available like we do on system level however as Support pointed out, changes are not tracked.

In version 68 we'll add a way to control manual service flags. In 69, we'll make it also possible to control automatic service flags through the apps.

Right now this is available in the PC-based and web-based apps. There you should see the groups on the left side and you can toggle between them.

Thanks. Looks like it needed a reboot...

It has already been fixed, will be part of the next version.

68.0.8 should be available next Wednesday.

I guess that is how things should be!

We have the 68.0.7.beta out which contains the fix.

Seems that it breaks with the STARTTLS. That means the switch from plain text to TLS fails. You could try to use TLS right from the beginning (avoid STARTTLS), maybe you'll have go to an encrypted port. In that case I would turn the TLS log level also to 9 and see what messages are being send and received.

Well at this point its just a name. Renaming would cause problems with upgrade, its better to keep the name even if it covers additional models. Please check if you have modified the pnp_grandstream.xml file. Here it shows that the parameters are in that file.

Yea the electrical sound happens because the jitter buffer is "in trouble", but it's just a few milliseconds. It also happens at the beginning of the call, depending on what's in the buffer already. We will take care about this in the next revision. The the problem with the zero is that in your area there should be no number that does not start without a zero (well, that is in theory) unless it is a local number. Maybe setting the area code will solve the problem, however its not a good user experience and the user has no control over this. Its probably better to just don't look at the number unless it starts with a user-entered zero.