Vodia PBX

You can check if there is a one way audio problem by just calling that extension. If it works, it will also work for paging. The ports can be different on the phone and the PBX, e.g. sending from the PBX port 1234 to the phone port 2345 would be perfectly fine. I would still use the PCAP feature for the phone to capture multicast traffic. Then you can see what is actually arriving in terms of multicast RTP on the phone—or its absence. If there is no RTP when it should, binding the multicast RTP to a specific IP address (if there are more than one) on the PBX may be the answer.

Where do you see the time? On a VoIP phone (which one?) or when you listen to a voicemail?

Well so far we have only settings for the TLS version and RC4. Down the road we'll probably need more control over this and also add more ciphers for better interop.

We have made builds for 66.0.4, and also updated the release notes. There are a few minor improvements as the number suggests, many of them for better operation with more soft phones connected. Also a few changes were necessary for better SMS support which we hope you can use for better productivity with clients.

Hmm handshake failure. That sounds like it does not like the ciphers that Vodia is offering (TLS 1.2 should be fine, just verified with curl). Workaround could of course be to run this through a regular web server (e.g. PHP) and see if they like the ciphers from there.

Hmm I would also turn on TL logging to 9 to see if there is a problem with the certificate. Maybe you have to reset the list of Root CA (if you are coming from an old PBX version).

It is wget https://speech.googleapis.com/v1/speech:recognize?key=AIzaSyD6XgI-eLss3oX3xl1cLSSUV6Nxg05jCXY

I would turn the log level for the web client to 9 and see what is going back and forth. It sounds straightforward...

There is usually a limit of number of multicast paging groups that you can have on a single phone between 8 and 10 groups. Make sure that you don't have too many groups on each device. The PBX itself has no limit (apart from possible license limits). Depending on the network setup, you might have to explicitly tell the PBX to what IP address it should bind the multicast sockets. If there are multiple interfaces, it might bind to the wrong interface and then the phones would not see any multicast traffic coming in. Unicast makes sense if there are less than lets say 5 phones in a group. Its not only the server load, its also the problem that all phones have to accept the call before the page can begin. There is no hardcoded limit. 10 might be a high number, but it should still work. I would always prefer multicast if the page is in the LAN. You also need to make sure that the extension starting the page has the permission to do so. The page should not go to a trunk. The only case where I can imagine this is when the page number is an emergency number. It is not a good idea to use an emergency number for a paging group. If you have remote access to the PBX you should be able to "see" what is going on in the network with Wireshark, either on the PBX itself or on a desktop phone (most desktop phones have a Wireshark feature from the web interface).

Can you just try curl https:speech.googleapis.com/v1/speech:recognize?key=AIzaSyD6XgI-eLss3oX3xl1cLSSUV6Nxg05jCXY from your machine? From the log it looks to me like there is no TLS negotiation going on at all. Maybe the firewall is just blocking traffic to that location.

We tried this on our own server and it still works... Actually Google changed something in our API settings, and we had to re-enable the API on the Google console. Are you still getting those 500 codes, or now maybe something from Google that says "permission denied" or something like that? You can turn on the log level for the web client which should show you what the PBX is trying to send and what the cloud service responds.

The day has come when we added them to the drop down.

Next build (66.0.3+) will contain a Twilio integration.

The server should be just the address without http or https. The search expression would be what you are looking for, e.g. (|(sn=%)(gn=%)(company=%)(category=%))

Your application server can return a XML object that could look like this (see https://doc.vodia.com/ivrnodes_ext_app for more information) <?xml?> <Envelope> <Body> <IVROutput> <WavFile>audio_en/bi_1.wav audio_en/bi_2.wav</WavFile> <Clear>true</Clear> </IVROutput> </Body> </Envelope>

The latest version should contain a "Swisscom SIP Trunk" dropdown that does it the right way.

In the iOS you can edit the contact where you can see the company. In the Android app, that is not possible yet. In the Windows/MacOS app and the browser, you can also edit the contact but the company is missing there still.

We have to redesign a few things with the parking orbits in the backend. The older versions were relying on web socket-based updates which are difficult when you miss a state update. This will take a few weeks.

Ich denke dass das @swisscom.ch@swisscom.ch das Problem ist. Da scheint im Header der falsche Parameter gesetzt worden zu sein. Welche Werte sind für die Header eingetragen?

Depending on what you do in terms of number of calls, CDR, address book entries and other things that should be still possible. I would even say the newer versions are saving you memory. It would not make a big difference if it is 32 or 64 bit.

Where? In LDAP? Or in the app?

Yea we are trying to phase out the 32-bit versions. How hard would it be to use 64 bit instead?

The label was missing in the dictionary, which should be included now (though it is only in English right now). Hanging up yes indeed that keeps the call still connected. It was like that for years when using this from the cell phone, but maybe we should change that—at least if we are using "vintage" phones.

Ok please try http://portal.vodia.com/downloads/pbx/version-66.0.3.xml there you should see the option in the registration tab for the extension.

We have added the option to the extension settings, it will be in the next build. We re currently on 66.0.3 with the L&G build. This should be available for CentOS64, Debian64 and IOP tomorrow.