Vodia PBX

Usually people dial 011 (in the USA and Canada) or 00 (in the ROW = rest of world) first, then followed by the country code. In the trunk you can override the domain setting and specifically tell the trunk to present numbers in 00 or E164 formet (which is, 972xxx).

You could try a pattern that will wait for a thousand digits: !.*!123! this will practically also ignore all input...

The package is also ready, however we have some weird problems with the Image. :-( Always something.

You can set the authentication also with websockets; just watch what the browser is doing. We could add something with websockets that checks the authentication and set up the session for you; but the question is if that would really help you.

Just a heads up we have made 5.4.0 for MacOS (just the image). Next up is a new installer for new Mac installations.

Looks like only in English speaking countries the 12 hour format is (still) used. We will turn it around to make the 24 hour format the default and the 12-hour the exception.

Currently the 24h format is used for German language only. I guess this is something we need to change. I tried to find a page that lists which countries do 12 hours and which 24 hours, but that seems to be complex problem. What country/language are you using?

Double topic?

It is a little bit difficult to test, as the event happens only once per month. I guess you have copy & pasted your API information from the Freshbooks page to the PBX. You need to make sure that every domain has the billing information filled out, otherwise the PBX cannot create invoices for those domains. Also you should have at least one billable item, for example 10 USD per extension per month, so that the billable amount is more than 0. You might have to wait for a day before you can hit the "test" button on the PBX billing page. Then you should see draft invoices for those domains in your Freshbooks account. You should also turn the log level for billing events to 9, so you see what the PBX is doing when you hit the test button.

Is this a duplicate topic?

We did that in the old days for Polycom phones, and the file looked like this: <?xml version="1.0" standalone="yes"?> <directory> <item_list> <item><sd>1</sd><ln>{speed-label 1}</ln><ct>{speed-number 1}</ct></item> <item><sd>2</sd><ln>{speed-label 2}</ln><ct>{speed-number 2}</ct></item> <item><sd>3</sd><ln>{speed-label 3}</ln><ct>{speed-number 3}</ct></item> <item><sd>4</sd><ln>{speed-label 4}</ln><ct>{speed-number 4}</ct></item> ... <item><sd>46</sd><ln>{speed-label 46}</ln><ct>{speed-number 46}</ct></item> <item><sd>47</sd><ln>{speed-label 47}</ln><ct>{speed-number 47}</ct></item> <item><sd>48</sd><ln>{speed-label 48}</ln><ct>{speed-number 48}</ct></item> </item_list> </directory> Yealink often uses formats that are very similar to what other vendors have done before, so maybe it is very straight forward.

If you are using PnP for Yealink, you can use LDAP to access the address book. This way you don't have to copy the address book into the phone. Are you aware about this? Or is there another reason why you would want to copy the address book?

I would just leave the field empty. Then the PBX will keep collecting digits, but not trigger any action...

Usually you will be able to see who is charged for the call by looking at the SIP packet, especially if it contains the authorization information presented to the SIP trunk provider. Ultimately, the trunk provider must derive the billing information from it. This is the charge from the SIP trunk side; who is internally in the PBX accounted for the call is another question.

We have made version 5.4.0 for Windows 32/64, CentOS 32/64, Debian 32/64, FreeBSD 64 and the snom mini. Later today we will have also Vodia mini PBX (BeagleBone and Raspberry Pi). MacOS will take a few days longer, as our Mac mini is really really slow these days and needs to be replaced. If you are using CPE licenses, please check at http://vodia.com/en/mplan if this upgrade is covered with your license. Highlights of this release are: It contains an API for voicemail to text, so that your customers can get a text preview of the voicemail (available only for hosted PBX) There was something not working well with Fax-to-email which seems to be working better now The PBX can now write MongoDB CDR records (also only for hosted PBX) We have added some more phone models for automatic provisioning, giving you a better choice of devices that ever The release notes are available as usual at http://vodia.com/doc/releasenotes540

With Office 365 you will most probably have to undo the registry entry that Office 365 does for you so that SFB gets all calls (see https://vodia.com/doc/tsp, https://community.office365.com/en-us/f/166/t/8900). I don't have Windows 10 will have to ask someone else to try to install the TSP there, but in theory I don't see a reason why it should not work.

Our Mac mini seems to be getting too old... We have ordered a new one, should be arriving in a few days. Then we can build 5.4.0 for MacOS again, and we'll update the installation as well.

Well it should work. Maybe you can try to turn logging to log level 9 and see what the system says.

Correct. But that is by design. If every hunt group member call forwards calls coming in on a hunt group, it would create a forwarding mess with potentially lots of loops (A forwards to B and B forwards to A), which are unmanageable in an office. If they don't want to take calls, they should just use DND or in the case of a ACD, log out.

Couple of topics, couple of answers. 1) We had the certificates topic on the table since Google changed the policy for their SHA2 signatures. What the PBX could do is to act as a certificate intermediate and provision certificates instead of passwords. Many phones are today able to do this. I think we had done that for Polycom phones at a point where they would not allow TLS without a valid certificate, maybe we should resume that in 2016 as the whole industry has moved forward. I think one core problem is that people need to trust the Vodia Root CA. That would make it really easy to build up that whole tree of certificates. If people want to use other trusted Root CA that would of course also work, but I would say most of the services running the Vodia PBX don't want to spend the money to purchase a certificate every year. 2) Well, that could work only with "piggy back" information inserted into the provisioning files. We could think about adding parameters back into the provisioning as we used to have a couple of major versions ago. 3) The real problem here is that Missed Calls is essentially like Message Waiting; however while we have a standard for the MW, we don't have it for MC although they could really use the same mechanisms. As far as I can tell this would work only with a proprietary extension today.

Are you sure that you have the right timezone for the domain and extension? The GMT-04:00 is generated for the Atlantic Time Zone.

ACK. We have come up with a manual installation procedure. We can share that with you and it might also end up on the installation page.

You might want to give the TSP another try. The post above is a few years old. I think for Outlook TAPI is still the way to go.

Well if you automatically provision the Yealinks they can use LDAP to see the extensions in the domain. Maybe you can skip all that work! The problem with provisioning XML directories is that when something changes, you need to do it again. That is why a live query like LDAP is much more useful. Apart from that, in the old days as had a XML file I think for the Polycom phones that was automatically generated for provisioning. If you really have to do this, that might serve as a starting point.

If you leave the default password on phones, well don't be surprised if someone takes them over. We get criticized for provisioning long passwords, but articles as the one you mention make again clear that this is necessary.