Vodia PBX

We have made builds for all operating systems for version 5.1, including the installers for Windows. The release notes can be found on the Wiki as usual. Thanks for all for the numerous feedback that we have received for version 5.0.10[b-p]! This version is for sure the best version ever .

At first glance it sounds like a bug. Is there any newer software available? A possible workaround could be to use the trunk failover feature of the PBX. When the TG784n fails, just try again! Because the PBX is a B2BUA, it will have a separate Call-ID, which might fool the gateway and have it process the new request as separate request. That should lower the probability of this behavior significantly and if it is still too high, maybe add a third one . It is definitively a dirty workaround, but one that actually might do the job.

Out of sequence problems are not the problem. Maybe just private message us the trunk login data and we are taking a look from here.

No you can also log in by SSH. Username "root", password is the one that you have set for the web interface admin.

Ahh... There are settings in the pbx.xml file that you can tweak. Search for "rtcp_" and change the settings all to false, then restart the service. This completely disables RTCP-XR on the system, including the phones. But at least you can make calls to that service provider.

Version 4 was dominated by the idea to promote snom. Probably that functionality was not so much in the spotlight. But you can edit the pbx.xml file, check out the setting "app_help".

This feature was introduced somewhere around 5.0.10h. What version are you using?

Na dann können wir nicht weit entfernt sein vom erfolgreichen Anruf in das System hinein. Zentrale Rolle spielt folgendes Setting: Ich würde erst mal alle Anrufe auf eine bestimme Nebenstelle routen. Das sollte auf jeden Fall klappen. Wenn nicht gibt es noch Probleme mit dem Trunk. Steht vielleicht noch "1.2.3.4" in "Adressen für eingehende Anrufe explizit angeben"? Falls ja, löschen oder die IP der Fritz-Box angeben.

Check out the latest blog entry... http://blog.snomone.com/2013/07/rtcp-xr.html It is a shame that so many carriers/SBC have problems with this. Anyway, we have added an option that turns RTCP-XR off in 5.1 (available also in 5.0.10o).

Dafür haben wir jetzt ein schönes JavaScript Programm geschrieben, wo man nur noch seine Nummer eintippen braucht:

Plug and play is don't using HTTP; I doubt that the phone router is blocking it (my only idea would be that it blocks the request because it does not trust the PBX certificate). You can try this easily by entering the URL in your PC browser and see if you can load the document. I bet it times out like it does on the phone. I would review how the HTTP and HTTPS requests are being routed by the PBX router. Maybe you have forgotten to port forward 443.

Not yet...

Maybe some crazy Silicon Valley VC wants to invest in a company that supplies a HTTP API for finding out if a number is complete. Big data!

Automatic dialing remains to be a major pain in the neck. Put it this way: Think about a customer who wants automatic dialing on the cell phone. The cell phone network is simply not designed for that. So is SIP. On Android, you could modify the dialer to hit the green button automatically once the number is so-and-so long. Who knows, maybe there is really such an app out there; but I don't think it is a big success. Anyway, for SIP we did some workarounds for the US region where codes are usually 10 digits long. However my experience it is still easier to tell customers "SIP works like your cell phone". The number of button presses is the same, considering that they don't have to grab an "outside line" (which is not happening on SIP anyway). You can take a look at the dialplan.xml file (which is in the templates). There you see how it works in the US; and that could be a starting point for Mexico as well.

No... Can you load the resource from the LAN? E.g. http://192.168.1.2/prov/snom710-000413745EF0.htm? For the PBX, it does not make a difference if the request comes from LAN, WAN. VPN, IPv4 or IPv6.

When I am trying to get http://that-ip-address/prov/snom710-000413745EF0.htm from my web browser, it also times out. It should at least ask me for a username/password.

That's not a binary, that's just ASCII. You can use vi to edit the file. That editor is a pain in the neck, but you have to change only a few characters so it should be fine. See http://ss64.com/vi.html for more information. If you prefer, just give us SSH access and we'll quickly do it for you.

We'll record the whole session again in one go and make it available as MP4.

Wenn der Anrufbeantworter annimmt, ist das schon mal ein gutes Zeichen. Können sich die Nebenstellen gegenseitig anrufen? Ich würde mal zwei Telefone registrieren und versuchen ob die sich anrufen können. Vielleicht ist ja eine einfach nur auf DND gesetzt oder hat eine Rufumleitung eingeschaltet.

There is a way to perform from-based routing on trunks (http://wiki.snomone.com/index.php?title=Inbound_Calls). The point is that you have the PBX look at the from header instead of the Request-URI or the To-header. This is indicated with the "f" flag in the ERE pattern list. Not very convenient, but possible. For example, if you want to send all numbers starting with 33 to the French ACD (81), all numbers starting with 34 to the Spanish ACD (82) and all others to the English ACD (83), you could use the ERE "!^33!81!f! !^34!82!f! 83".

Hmm. Good point. Right now I cannot think of a simple way to achieve this. But it makes sense. I thing we have to add that.

Aha... Es gibt eine etwas veraltete Anleitung zur Fritzbox http://kiwi.pbxnsip.com/index.php/AVM; vielleicht hilft die noch. Ich vermute das Problem ist dass die Fritzbox nicht weiss wohin mit dem eingehenden Anruf.

Wie soll denn der Anruf terminiert werden? Über einen SIP-Provider oder über ein PSTN-Gateway?

Wie ist denn die Leitung konfiguriert? Unter "Routing und Umleitung" was ist dort ausgewählt für "Ziel Konto"? Steht im Log etwas wie "Receive incoming call on trunk so-and-so"?

As far as I can see that is at the moment hard wired. A (dirty) workaround would be to send the call first to a dummy IVR node which always connects the call just to time out after a second and send the call to the callback service.