Vodia PBX

One good reason to keep your PBX up to date is when new phone models come out well the PBX cannot guess what features future models will have.

Latest version contains the new OUI. Actually Yealink has added a 3rd one now 80:5E:0C (not a typo).

We have now released 60.0.

Is the browser able to load the JSONP content right from the vodia.com web page (cross site)? You should see that when you inspect the page in the browser.

In the latest (currently 59.8) we have revisited the header parameter "from" so that it should take it from the inbound trunk, if available. So if you want to try this again, our suggestion would be to move to 59.8 and use the {from} header in e.g. in the From header. There is also now a log available that shows all available variables, which should make ths trunk setup easier. Also there should be a drop down for setting up Twilio trunks that do it all for you, so you don't have to fiddle with the headers at all...

It is a common problem that the PBX is "competing" with other services on port 80 and 443, e.g. IIS. In such a case you can manually start the PBX from command line with .\pbxctrl --http-port 8080 --no-daemon --dir . and set the ports through the web interface (port 8080 obviously).

The only way I can think about would be to add an address book entry and use the name "Unknown" there. If you are lucky the phones will display only the name and not the number.

Just send a quick email to sales they can get you a demo license for anything you need. They are happy to help you!

Actually this was supposed to be a feature. You don't have to worry someone else booked the room unless you run out of calls.

I would take a look on what the PBX sends to a phone. It includes a name in the XML where the user@domain should be easy to see,

What is presence... This works well with an IM tool where the user can set status messages, but with the PBX things are different. If you are interested in the extension status, I would subscribe to the dialog state, so that you can see when someone is on the phone. If you want to see more, you can also subscribe to the as-feature-event for redirection and DND. I believe then you should get a picture about the presence status on an extension. Then we have the discussion if you can publish that into Microsoft SFB, Google Hangouts, WhatsApp and so on. That is where things get really interesting, but also really difficult as those networks tend to prefer to stay private and don't offer open API for pushing information.

This is really about the permissions, mostly "dialog state" (BLF). For example you might be able to set up BLF button on the front end, but if the permissions get denied, the subscription will fail.

As for the picture, maybe we just put some very trivial single color picture there and make it easier to replace it with a customer URL. Would that work?

I think for incoming you can only accept the calls (there is no need to make a decision). For outbound, the dial plan determines what trunk should be used. The extended regular expressions are complex, but you should be able to handle all sorts of complex patterns with that and then send them to the right trunk.

This might be a little tricky, but possible. The CDR contain a list of pressed DTMF codes (MongoDB CDR or webcdr). If you are able to process them e.g. with your own PHP server you might be able to "fish" that information out.

We actually added another platform that is mostly used in Europe (Tellows). This is available on all hosted licenses, also if you host yours. However you have to get an account with TrueCNAM if you want to use their service.

Yes that feature did not make it into the release yet. It will be added back later...

Sometimes good things take years to become mainstream. IMHO RTCP-XR makes a lot of sense for service providers as this provides useful information about the call quality, in both directions. The information can be used in several ways: Service provider reporting how good the trunk leg was (IMHO that is the most important, bu (almost?) no provider does that) PBX reporting on how good the trunk leg was (today almost impossible because almost no trunk provider supports RTCP-XR) PBX reporting quality of extension leg. That is done routinely and reflected in the MOS score for every call.

Maybe you can post here what exact expression you are using, the one above would not do it...

Well they will be back in 59.5+; however we are still not talking shared lines, underneath it is BLF.

Internally the PBX always tries to use the global +-form to represent numbers. When using the numbers in a specific context, it converts them into the country-specific format. As long as it works everything is fine.

The MAC for RPS is in the PBX code and cannot be changed. You will need to update if you need that.

Can you make a PCAP trace and sent it to support?

Ja diese Versionen sind teilweise einfach nur Tages-Build. Wir sind inzwischen bei 59.5 angekommen... Sobald sich der Staub gelegt hat werden wir eine Version 60 machen welches eine stabile Version sein sollte.

We have just made 59.3 for Win64. In case that you can update that system, this might be worth a shot. We have had a lot of work on the sockets, in Linux we hit the 1K sockets limit for select and had to switch to another system call. That resulted also in some rework of the Windows socket subsystem for us; hopefully the chapter can be closed with 59.3.