Vodia PBX

Right now that is not possible or at least difficult. Where do you want to display that information?

Hmm. I guess you are aware about the daily stat email, which already contains information about how many calls were answered etc. Is that enough for you? Those emails may even contain the list of calls in the attachment.

It is not trivial, but possible. The key is that you need "to assume that the call comes from an extension" on the trunk, so that the PBX knows which dial plan to use. But the trunk to trunk routing capability is something that we need to address in a broader scope in one of the next updates.

Hmm. Workaround could be to press * to tell the PBX that someone is there (no mailbox).

I mean you should do the automatic provisioning of the phone. That makes sure that the important settings on the phone are set up right and you don't have to slide down the learning curve on how to set up the phone right and secure.

Whow I also was not aware about that...

Thanks for the update. That clearly shows that your firewall must be mangling with the SIP. Also we strongly discourage usage of UDP because this is very troublesome. You should use TLS or at least TCP. And you should use PnP--which will by default set up a TLS connection, which are usually not changed by the firewall.

Can you do a quick try with gmail? Just to see if your PBX (or maybe firewall) has a problem or the email server.

Hmm. Seems you have get a 30-day key to try it out.

Ad-hoc is always included. When you use snom phones with that record button with PnP, you can just press the button during the call and start recording from there. For other models like 7xx, you may have to put that on a general-purpose button.

Sorry please remote the dot at the end. The forum is not very good in detecting where a URL exactly ends...

What email server are you using? Maybe that server is filtering attachments?! The CDR emails also have a little attachment, it that also gets filtered out there is a general problem with attachments.

The problem is that snom ONE has changed the authentication. In the old days, it just trusted the MAC address, but today that is not appropriate any more. We have not found a method to put credentials into the phone yet but have a idea on how we can automate the provisioning for devices without credentials while maintaining a reasonable level of security.

If you upgrade from at least 4.5, the trunks should be the same as far as I can tell.

I guess snomONE... However I would recommend today to just install a standard CentOS64 VM and run the install script. This way you have the latest version, the VM appliance is already somewhat outdated. I am not even sure of the download links still work as they point to the snom web server.

Hmm that should work. What version is that? Do you get emails e.g. on missed calls for that extension (is the email working in general)?

At first glance, this should work; especially if the SIP signalling seems to be okay. If it is not to much work, I would use a packet sniffer like Wireshark to figure out what is going on. Then you can see where the PBX sends the RTP packets and if it receives any RTP. Edit: Also, I would first try if it works well with WiFi, then potentially try 3G or 4G. Who knows, maybe your carrier does not like RTP.

Although the page is already a couple of years old, this might help you: http://kiwi.pbxnsip.com/index.php/Microsoft_Exchange. For example, the external voicemail system setting should have a prefix (e.g. 8$u), otherwise it will be difficult to call an extension directly.

There is information about how to handle inbound calls on http://wiki.snomone.com/index.php?title=Inbound_Calls. In addition to that, make sure that the "Explicitly list addresses for inbound traffic" settings is either empty or set to the IP address of the gateway.

There are two different kind of recordings: Automatic and manual (or ad-hoc). The automatic recordings land in the file system and so far this is a one-way street. The manual recording land in the mailbox and are similar to voicemail messages. The problem is that automatic recording usually ends up in a huge amount of data. Having them in the mailbox would not be very useful (you-have-one-thousand-and-three-hundred-twenty-two-saved-messages, great now what). Having those files on the file system is usually a lot easier to handle, for example if you include the date in the file path and make the date a directory all recordings are at least sorted by date. I heard from a customers that he has 40 GB of recordings; you don't want to show them in a long list on the web interface. But we don't oppose improvements with the automatic recording. For example, it could make sense to go through the recent recordings with a simple star code and move back and forth with a DTMF tone similar to what is already available in the mailbox. For example when you have this one-hour ride home and you want to review the calls of the day, it might make sense to have a review function available from your cell phone (assuming that this is legal).

You have to go to "support", there is a link to the support ticket (https://www.snomone.com/ticket). When you purchase a ticket, at the same time you get a credit for future purchases.

In Linux, it is relatively easy to create a symbolic link (ln -s) to another file system. For example, you can have the snom ONE installation on a local hard drive, and make a symbolic link to file system that has been mounted over NFS on a remote system. Or you use a SSD hard drive locally for the PBX, and make a link to a standard HD for the recordings. The PBX can deal with delays when writing to the file system; the playout of RTP does not stop because of this. However when recording filesystem is blocking it does not read more files; the result would be that when your remote NFS becomes unavailable, you would not hear IVR messages any more. That is whyt is ia a better idea to keep the recording folders local and use a replication mechanism like rsync or DropBox to push the data out to an external server.

This is indeed a complex topic. In some areas like the dial plan and trunk setup, we offer also text-based configuration, so that it is easier to copy & paste configurations or we make it possible to use CVS files to set up accounts. You can also "backup" and restore domains, so that they can be moved from one server to another. And we have a SOAP API that you can use to manipulate the internal database; however it is not easy to use and depending on what you are trying to achieve probably too time consuming to program.

Recording is file system based. For example, you can mount a remote file system or you can use tools like rsync to keep local and remote file system synchronized.

US east coast.