Vodia PBX

In version 5 we have introduced the feature to perform trunk-to-trunk routing, with the dial plan in the trunk settings. You don't need to "assume" that the call comes from an extension any more...

Gmail advertises IPv4 and IPv6. If you server does not have an public routable IPv6 address, you will see this message. What version are you using? In the newer versions the PBX will first try IPv4 then IPv6.

If you automatically provision the phone, you will see a SUBSCRIBE from the phone to the PBX with the as-feature-event type. If this subscription does not make it to the PBX, there may be something wrong with your network (firewall). If the message is not being sent from the phone, you may be using a very old firmware on the phone. A manual setup for the DND subscription will be very difficult, that is why we added that to the automatic setup.

Well technically the PBX is a B2BUA but it does what you want. Just plug the phone into the LAN and provision it from the web interface. Then you should already be able to make your first phone call.

Did you automatically provision the phone? Then you should be able a as-feature-event subscription in the PBX.

Thats a custom-made license. Please give sales a quick call, they should be able to resolve this.

We currently support the following snom models: - 3xx (300, 320, 360, 370), although we recommend to use a pretty old software for them - 7xx (710, 715, 720, 760): Those phones should be used for new deployments. 715 might make some initial trouble with the firmware that is coming from the factory but can be manually upgraded to the right firmware. - 8xx (820, 821, 870): They are also fully supported though some models are already end of life - m9: The DECT handset - Others like MeetingPoint and PA1 are also possible, though there the plug and play is usually not so critical.

If you are upgrading from a snom ONE blue or yellow license, you can use the activation code (starting with B or Y) as coupon on vodia.com. Generally you will get 50% off for any bundle.

A common problem with the snom ONE plus is (was) that the logs from the PSTN gateway were filling up the hard drive and eventually crash the system (time bomb). In some systems we found literally millions of email warnings scheduled for delivery. If you know how to set up the gateway, you can fix this yourself or have either the Sangoma support or us take a look at this.

In France it is the easiest to "match extension after prefix" for inbound trunk routing. For example if your company has the number +3312345xx (xx being the extension, for example 40, 41, 42 but also 0), then you can use the prefix 12345 or 2345. it is really just about matching something in the number and then taking the rest to determine the destination in the PBX.

1) There is a 4.5 version out there, for more information check out http://wiki.vodia.com/index.php?title=Upgrades there you find the links with the 4.5 builds. 2) We do encourage everyone to do so. In the days of security vulnerabilities it is generally a good idea to stay up to date. We try to make the upgrade as smooth as possible; however introducing new features creates upgrade problems. As for 4.3, there were changes in the trunk level that could cause problems with the SIP headers (generally, when moving from 4.3 to 4.5 or higher). But a few minutes of tinkering SIP headers should usually solve the problem. As a general rule, do make backups of the working directory of the PBX, especially before upgrading the software. If anything goes wrong, you can move back without burning bridges. For example, we started to encrypt passwords in newer versions; if you don't have a backup, this does make it very difficult to move back because the old version would then read garbled passwords.

Update: So we have the images also uploaded. The links did not make it yet and the logo is also still missing; but at this point we are operational again

Well we are working on it. Text seems to be back. Images are still a challenge. The mid-term goal is to get rid of it altogether and just use good old plain HTML for the documentation. The downloads do not depend on the Wiki. For the 5.2.4 image we did not make an installer, please use the 5.2.3 versions and upgrade them to 5.2.4. (Just corrected the link in the documentation.)

For the snom ONE minis, we have a problem updating the bash. It seems that there is no new version available yet. Anyhow, for those who want to give it a try here is what I have tried: env x='() { :;}; echo vulnerable' bash -c 'echo hello' apt-get update gpg --keyserver pgpkeys.mit.edu --recv-key 8B48AD6246925553 gpg -a --export 6FB2A1C265FFB764 | sudo apt-key add - gpg --keyserver pgpkeys.mit.edu --recv-key 6FB2A1C265FFB764 gpg -a --export 8B48AD6246925553 | sudo apt-key add - apt-get update apt-get install --only-upgrade bash The update gave me an error because obviously some servers have been moved or added. That is why I added those keys to the apt-key list. Then the update actually did realize there is a new bash, and the new bash installation did something. However it seems that the upgrade did not fix the problem yet .

We currently experience some trouble with the wiki server.

Seems like we have the next meltdown in the Internet. The PBX itself is not affected, but the underlying platforms might call for action. More information on the blog with the address below: http://blog.vodia.com/2014/09/how-big-is-damage-this-time.html

With the snom phones (which don't support SIP/SDP video) the only way to see something on the screen it to use MJPEG. There is a how-to on http://wiki.snom.com/Category:HowTo:Video_Streaming This solution bypasses the PBX and has much higher refresh rates that the "hack" version with the version 4 PBX.

The problem is simply that with the switch to Vodia, those files were on the snom servers and are not available any more. Yes, if you want to have a supported and maintained version, you better move to version 5. For example, the new phone models are not available in version 4.

With "hack" you mean that the phone was pulling each frame with two HTTP requests, going through the PBX? Apart from that we did fix a few things in the video area, that should actually improve the interoperability. We tested that essentially with the Grandstream video phones; but "in theory" this should also work with 2N.

No, everything should be visible in the browser. We are mostly using Chrome, where you can see the traffic between the PBX and the browser nicely listed at the bottom. If it is still not clear, you can as well use Wireshark to see what is going on on the network level (use HTTP instead of HTTPS).

I don't have the Bria in front of me, but a quick search gav eme this one: https://support.counterpath.com/responses/how-do-i-make-an-attended-transfer-using-bria-3-for-mac

I get your point. But a softphone without the attended transfer? Which one are you using?

Well on many ATA the hook flash holds the call. If you have a SIP phone, you would of course press the hold button. But on such phones, you usually also have an attended transfer programmed, so that you don't have to use star codes for the transfer.

I would definitively check the logs. It could be that the trunk was temporarily not registered, or that the number of maximum calls per system/domain/extension has been reached. Those things would be visible in the log.

It is debatable if this should be possible (bug or feature). Not everyone who is allowed to review the calls should be able to store them. Only the file system access so far gives full control over the recordings.