Vodia PBX

If you just want to playback a message, why don't you just use a IVR node instead of a mailbox?

We have introduced as "smart transfer" setting last year; however it caused a tremendous amount of problems so we keep it low profile for now. The way phones behave in the blind transfer case is just so much different from model to model and from firmware to firmware that we decided to use only the classic blind transfer model.

Did you PnP the phone? There are trouble tickets pending with snom in this area. For example, click to dial does not work when the phone is on DND. Other phone vendors work fine with the synchronization of the DND and redirection status; the PBX side seems to be okay.

Sounds like a problem with the routing of the ACK request. What service provider are you using? Does this service provider has a "session border controller"? If not, then you must operate the PBX on a public IP address. If you like, filter in the LOG for the IP address of the service provider and attach the SIP packets here; then we can take a look.

There is a problem when you use a PnP URL like this: http://pbx-adr/prov/snom360.htm. Then the PBX translates that into something like this: http://pbx-adr/prov/prov/snom360-000413123456.htm (double prov). The problem will be fixed in 5.0.10. In the meantime either use http://pbx-adr/snom360.htm, http://pbx-adr/snom360-000413123456.htm or just http://pbx-adr.

My first question is: Is there a firewall involved? If the PCAP was done on the PBX host and you can hear the stream, you can rule out problems with the firewall. Then the question is how the phone is connected. Did you use PnP? At least TLS or TCP transport layer (not UDP)? Try a setup where the phone is in the LAN to make sure that there is no problem between the phone and the PBX:

Well it does not mean it is a secret... All it does use the domain name instead of the IP address of the server when provisioning devices. That affects for example the outbound proxy setting when provisioning snom phones. It cannot be default as most of the installations don't use DNS. Can you check the log file of the phone after it rebooted? Then you can see what DNS addresses it is trying to resolve.

You can see here which web browsers can be used: http://caniuse.com/websockets.

Features like call recording, call barge-in, MOS measurement require that the PBX stays in the media path; at least if you want to have a simple setup. Especially in the LAN this is no problem.

You need to have a license for this (see the admin status screen). You can get a 30-day trial license free of charge from snomone.com. Then there is not much to configure. Just make sure that the call hits the mailbox (e.g. by using the tone "F" in the auto attendant to redirect the call into a mailbox, possibly using the 8 prefix that sends calls directly to the mailbox) and make sure that the extension has an email address set up.

If you provisioned the phones, the phones will likely use a IP address as outbound proxy. There is a (hidden) global settings in the PBX that controls this (provision_domain_name), but I guess it is too late for that. Anyway, you should be able to reboot the phones remotely and then they should start with the provisioning URL, which should be a DNS address and then fetch the settings from the new server.

You could check-sync the phone from the old PBX web interface. A hard reboot (triggered by the user) also does the job. How was the provisioning server for the phone setup? If that was done using the IP address, you will have to do it again (use a DNS name this time). Otherwise a change of the DNS name should do the trick.

Sounds like there is no outbound proxy specified.

The phones might stick to the old server until the registration fails. Only then they feel the need to look the DNS up again. Apart from that for single domain moves, I would still prefer to make a backup of the working directory (excluding the executable) and restore it on the new server. This will really take everything, including DID but also the global settings that were made on the system.

snom deleted the videos from their website. Unfortunately we are not sure if there are backups. However we plan to do some webinars with up-to-date information that will serve similar purposes as the videos and that can also serve for becoming trained partners.

The SoHo has a very long delay committing files to the flash. This will not change with the upgrade, this is an issue with the Linux or the setup of the Linux on this device. The bottom line here is: Do not reboot the device if you can. Or at least let is sit there for ten minutes (yes) to make sure that all files are in the flash. The SoHo can also run the version 5. You might have to edit the /etc/init.d/snomONE file to make sure that it uses the pbxctrl executable (not snomONE-ctrl) and you might have to install a newer version of the libstdc++ library (see http://forum.snomone.com/index.php?/topic/6489-snom-one-mini-and-soho-upgrades/).

Windows 2008/64 -- is that still XP or already Vista? With XP we had problems that will be fixed for the next build. We will do this only the 32 bit versions as we believe that 64 bit is always on post-XP machines.

Well, we changed a lot for the provisioning for snom phones between 4 and 5; this was done for a reason and to save precious time when rolling the phones out. That also required code changes on the PBX back-end; not only on the templates. If you run version 4, you could do the provisioning in the LAN then take a look at the files in the generated folder and then use the settings when provisioning over the WAN so that you don't miss anything.

What OS? Windows XP?

It is indeed strange. Could this be because the previous REGISTER ended up in a timeout after the PBX has already sent out a new registration? We'll put something into the code that will help find out if that is the case. But if this should be the case, then the PBX would override the previously received 30 seconds timeout and re-try after 60 seconds, leaving a few seconds gap where the trunk would really not be registered. It would be "missing a beat". Anyway, thanks for the good trace. Hopefully the next version will be even more robust in that area.

Well if you use STUN then you obviously also use UDP--both a bad idea. Your router probably messes with SIP packets which is causing such hard to track problems. The easiest is to use plug and play, because that will set the phone up to use TLS and also sets also other important parameters so that the number of problems is minimized. If you can't use PnP (4.5 does not support snom 710 yet), then at least use TLS transport layer. This way you don't need STUN (there is a permanent TCP connection anyway) and the router cannot change the packets.

I would first reboot the 710 to make sure that everything is fresh there. Network failure in general means that there is some problem reaching out to the PBX.

Maybe you are just blacklisted on the PBX? That would explain the 408.

Well, that caused actually a lot of trouble. But if you want a snapshot, send me a PM with the OS that you need.

Does the user has mailbox messages pending and the callback set? Does the PBX say something like "extension xx is not ready, please press 1 to call now"? Or something else? Maybe it is time for an upgrade, I think 4.0.1 must be from 2008.