Vodia PBX

It will take at least a day after the upgrade before you will see the new reports. This is because the new version introduces more information about CDR that is used in the CDR emails.

Yes, the /etc/resolv.conf looks good. If it all does not work, try to get a PCAP and filter for the DNS packets.

This is to tell the PBX that a insecure call on a trunk is still considered secure, e.g. when a local PSTN gateway is connected to the PBX with a very low risk of someone getting physical access to the device. Then a call that requires a secure line (sips) would be run over that line even though the PSTN gateway does not use SRTP.

No. However OPUS is on the list and as far as I understand SILK is kind of part of it anyway.

The new Vodia mini PBX is also based on the beagle board. No point in making new hardware for such a device!

Well, SAVP would mean that the PBX insists on SRTP, which would lead to a lot of interoperability problems. So it says more or less "if you support SRTP, lets use it" otherwise not.

The PBX can probably not resolve www.snomone.com (thus the 0.0.0.0). Check your /etc/resolv.conf file. You can also add an entry to /etc/hosts if DNS does not work for you. If you do that, you should also add a entry for www.vodia.com which will be used in 5.2 and later.

Generally, the CANCEL problem does not occur as often if you are using TCP or TLS for SIP instead of the unfortunate UDP. This is something that you can also do with version 4. And do not open multiple tabs in the web interface. That may screw up the session and you get strange results.

Hmm so we don't have any calls from one domain to the other? Then I would track it down with appropriate logging, check out what is being fed into the dial plan. Maybe you have old patterns there that don't match any more. 5.1.3 does a strict formatting of the phone numbers.

As far as I remember the official statement about the number of allowed non-snom phones was 2. But if you want to try out before purchasing the DECT phones, you can try registering some free softphones to see how many third-party devices you can actually run in your installation.

The direction makes only sense when you report trunk calls (or extensions). The new call display deals with calls per se; however it might make sense to add a flag to the trunk indication so that it becomes visible if the call came in on the trunk or went out on the trunk.

As for the extensions creation, my guess is that this is related to the session which has still a reference to the old extension. Especially when opening several tabs with the PBX, the session easily gets garbled up. The problem with the "phantom" calls is that the call cleanup procedure is more complicated than it might look at first glance. Especially because the PBX has to wait until the final QoS reports are in, there were some race conditions that could cause a clogging of calls. However after 8 hours the garbage collection kicks in and deletes those calls. Yes those calls don't pose a danger for the overall system stability, but they can count against the domain limits. If you are running the PBX in hosted mode you should consider a migration to V5 anyway, as there are several other topics that have also been addressed especially for the hosted PBX.

Das kann man auch alles von der PBX aus steuern. Der Codec wird über die PBX erzwungen; ebenfalls das NAT Keepalive Interval. Das Telefon soll da auch gar nicht rumfummeln, z.B. mit STUN! Das macht mehr Probleme als es löst.

It might have been a transitory issue as CDR are historical by nature.

Google nach Intel Edison!

Well it seems it also has problems getting the time? Did it upgrade to 8.7.3.25? We had seen cases where you need to "nuke" it (factory reset) to make it work properly.

Can you check the generated folder on the PBX if that links was generated by the PBX? It should not. Actually all files should end with .xml, and usually the link is snom_3xx_fw.xml. Also check if you have any leftovers in webpages or html directories.

Are you using a global trunk for inbound calls?

For hostedi.am we leave it to the hosting provider to provide virtualization.

I wanted to give you a heads-up for a solution that significantly increases the stability of the PBX. As you might know, ZEN is a virtual solution that can run OS like CentOS or Debian, and thus also the PBX. I got a call today where we talked about failover for the PBX. Check out http://www.halizard.com/ It is a topic that comes up frequently and this looks like a simple, affordable and easy solution that can be rolled out in minutes.

Looks cool let us know if we should add something to the drop-down...

Sometimes the phones need a factory reset to clean up some undefined settings that cause problems with the provisioning. If the phone is in the LAN and the MAC has been assigned to the extension (and it listens to sip.mcast.net) it should all happen automatically then. If the phone is outside the LAN, you need to set the address of the PBX in the phone settings, according to the document above.

5.2. will have a new banner anyway. Not sure why it takes so long for you... But the customization topic is on the to-do list. We also tried to play with background images for the phones. However it was a frustrating experience. It seems to be impossible just to change the background image without having to re-do the whole idle screen logic.

Ja, das IVR Node würde einen SOAP-Request absetzen, das Gerät würde aber den ganzen XML-Klimbin ignorieren und einfach den Schalter umlegen. Ein VoIP zu Action-URL-Gerät gibt es: Vodia mini PBX!

Oh, We did not test with wildcard certificates... Maybe the Polycoms have a problem with that! As for the PBX, it treads all certificates the same, including wildcard certs.