Vodia PBX

Version 5.0.8 has been released. The release notes can be found on the wiki http://wiki.snomone.com/index.php?title=Release_5.0 at the bottom.

I would try firmware 8.7.3.19 or 8.4.35 (see http://wiki.snom.com/Firmware/V8/Download).

Is that problem only happening with the MeetingPoint? Does it work from other phones? What version are you using on the MeetingPoint? The special thing about the MeetingPoint is that is always operates in handsfree mode. That might result in problems with the sending of the DTMF tones. I remember that older versions had some bug in the DTMF area.

During the FAX setup both parties have to agree on the parameters for the transmission. For example, FAX can transmit color pages with high resolution and many other interesting things. However our perception is that this has no practical relevance: Users that want to send high-resolution images use a scanner and send an email. That is why the snom ONE FAX implementation focus on that one standard FAX mode. One important parameter for FAX is the resolution. Interestingly, it seems that it does not make a big difference if you are using A4 paper size of US letter. However the vertical resolution obviously does matter. The PBX supports only the vertical resolution that everybody uses, well almost everybody obviously. Anyway, the resolution negotiation should be visible in the T.38 packets. It would be great to see the T.38 traffic, then we can see if we can change something so that the vertical resolution negotiation becomes clear.

It remains a difficult topic. Some versions are stable, but lack some important features. Those who have them, are not ready for production.

Oh, don't change that. This will mess up the routing. If the provider is even remotely SIP compliant, it will allow anything in the contact field that allows the PBX to identify what incoming requests are about.

This is the "setting URL" (advanced, then update on the phone). The name of the setting is "setting_server", so in XML you need to add a line like this <setting_server>http://dns.name</setting_server> and then it should take it. I did not test this, though.

Hmm. I don't see the difference between the French and Italian XML... I tried with 5.0.8 and it worked also for Italian, though it did take a couple of minutes. In V4 there are many error messages that you can ignore during the update. Check if there is anything in the file system.

If the server is offline, the config will not be changed. It will just take a long time to boot up. Generally the PBX does not provision the address of itself. But you can change that in the template. Then you have to reboot the phone and it will fetch it.

You are right. We need to take the BLF functionality and just put the *90 in front of it. Let see if we can get that into 5.0.8.

Yea... is already fixed and will be part of 5.0.8. In the meantime, white-list your addresses. Sorry for the paranoia.

In principle, if the provisioning server is not available, the phones will take a little longer to boot up... no problem here. If you have set the phones up to use the provisioning DNS name of the server, they will go to the new address after the address was updated and the server is available on that address. No problem here either... If you have set the address to an IP address for the provisioning address, then you have to update that address on all phones. That would be a problem.

Did you try "intercom"? That actually does prefix the monitored extension with *90. As far as I can tell it does what you need?

Can't really say anything about Patton... However the PBX does attempt to switch to T.38, so a lot of things went right before this step. The G729 codec cannot be the problem. I don't understand why Patton would reject the T.38 re-INVITE. Maybe there is a way to get a more detailed log from the gateway why it does that.

Hmm. Almost looks like FAX is not enabled on the gateway. The traces look "beautiful". AFAIK other Patton installations do work fine with FAX and T.38.

This is indeed weird. It should not make any difference if the OS is native or a guest OS (that's the point about virtualization). AFAIK the PBX code does not differentiate between the codecs by the OS. Are you sure the systems are otherwise the same?

Hmm. Looks like the installer had a problem. Should be fixed now and hopefully also for future versions.

I assume that you are using plug and play with snom ONE? Then all you need to do is to edit the template from the web interface of the and add one of those lines above and reboot the phone. You can verify if the PBX really sent that to the phone by taking a look at the "generated" folder in the working directory of the PBX.

Eh did you also install the audio_en folder? Was that also missing?! Are they in the same directory where the PBX has all it's data (e.g. pbx.xml)?

Well... if your service provider supports only G.729A and you have only 10 G.729A licenses, then you can have only 10 calls. Workarounds with transcoding obviously causes significant challenges. That's why we added the a-la-cart item "calls" on V5. But it should make any difference if you are using VMware or Windows. If that is any difference, it must be caused by the performance of the system.

Step #1: Backup your configuration (make a copy of the working directory). Then after the upgrade, apply the license key that you have received. This is a key in the form 5XX-XXX-XXX-XXX. This will have the PBX talk to the snomone.com back-end and load the real license key (base64 code) into the PBX. The code is locked to your hardware and cannot be transferred to another hardware. Then it should be running. Common problems are that the firewall is blocking the PBX from reaching out to www.snomone.com or that there is no DNS server configured on the system. After it is running: Make another backup. The reset comes into play when your hardware dies and you need to move the PBX to a backup hardware. Restore the backup from the system on that hardware; the license will not work then. Here comes the reset into play: Go to www.snomone.com and reset the license. Then you can reactivate the license on the new hardware. The point here is that this reset mechanism is automatic (24/7). You don't have to wait until someone wakes up and comes back from weekend or holidays. In a case of a hardware failure, you have no time for that and need an automatic mechanism to restore the PBX service.

The PBX rejects additional calls when the media thread has a active/idle ratio that is getting about the performance limit (the blue line in the status graph). By default, there is a generous buffer so that the overall call quality does not suffer too much. This makes sure that you don't have to worry that all users will experience bad call quality. Also, if the PBX rejects calls, you will get an email as administrator. This is a kind of warning shot that you need to take a serious look at this. I would have the PBX send me a graph every night and from time to time check how much CPU is shown there. Usually you will get a Gauss-like curve there. If during the middle of the day, when everybody is busy on the phone, you are staying I would say below 40-50 %, things are okay.

Transcoding always reduces call quality. Don't try to mix other low-rate codecs like GSM or G726 in, this will result in even worse quality. VMware could be another risk factor. While it is possible to run the PBX in VMware glitch-free, AFAIK it requires some special resource assignments to make sure hat there is not another VM eating up CPU resources. When packets are garbled, it is very audible with G.729A while other codecs still sounds okay.

For 3xx series stay with 8.4.35. That seems to be old, but solid. For the newer models, the only workable solution right now is 8.7.3.19. SLA is obviously bleeding edge for that version.

G.729A is not good with music. Nothing will change that. My recommendation is to keep the volume as low as possible; everything else will be painful.