Vodia PBX

If you permanently blacklist the address you should not get any more notifications. There must be something wrong with blocking them.

Sounds like there are several areas that could be a problem. I would try to isolate the problems by making sure that internal calls are working fine before turning attention to the SIP trunk provider. TCP is generally much more reliable than UDP unless your customer uses outdated routes that have a problem with too many TCP connections. If those internal calls are fine, please check what codecs are enabled for the trunk, and possibly the system and extension. Maybe there is no match for a common codec.

Well maybe for now the generic GET/POST SMS can help?

There is no such thing as the IP address on a modern server. There are many! Private, loopback, IPv4, IPv6, link-local, you name it. We could use the name that you can assign to the instance, however then we have to deal with problems that it might characters that the various SIP service providers out there don't like and that might actually not be allowed according to RFC. It would turn this into a new problem area, especially because everyone wants to play with such settings and try out Japanese characters or just invisible spaces! Plus it makes the packet longer, getting us closer to the magic UDP packet size. If you want to separate the traffic for a specific trunk, we have the feature to turn PCAP on for that trunk, which nicely puts the packets to gather for you into one PCAP file (next version will even have precision time stamps).

We have made a build 68.0.20 with the release notes at https://doc.vodia.com/v1/docs/releasenotes680. It fixes a few things we encountered with the 68 branch. It should be an unexciting release. If you choose to upgrade, please make sure to take the opportunity to make a backup before the upgrade.

The SIP Call-ID that the PBX is generating pretty much hard coded. So are the ones that come e.g. from VoIP phones or SIP trunk providers. Apart from looking better is there any rationale behind changing SIP callerID?

We found an issue with OPUS, it might be solved in the next 68.0.20 version. If you want to try out, there is 68.0.19.beta.

There is BulkSMS, is that the same?

You could as well use an auto attendant and redirect after timeout.

Hmm that would be indeed outdated... But this should be only cosmetic. The "true" version number should be 1.18, which is the latest iOS build.

You can always see what is out there with ./pbxctrl --help. For example, if you want to run it just from the shell without any daemon stuff, you can start it with ./pbxctrl --no-daemon --log 9 which usually will give you an abundance of information of what is going on.

The way this negotiation works is that the PBX decides anyway. The client is only offering a preference, but the PBX will use the preference set on the extension. IMHO that's okay and should work fine.

What is in the pipeline is that when you eat to switch to a video conference, there'll be a popup where you can enter or just confirm the email addresses of the participants which will then receive the URL for the conference. We might also prompt for cell phone numbers if SMS was set up on the PBX. Then everyone has to click on the link and get into the conference.

... also related to that problem we recently found an issue with OPUS which will be fixed in the next version. Those who want to try can use 68.0.19.beta.

You can pick up the call from your mobile app to your desktop app using an icon. It might also work the other way for Android (not for iOS yet). We do have the codes *52 and *53, however they were designed to work with GSM and not the app.

Wow you saw that build before we were able to finish it... Anyway there was a glitch with the build for the web pages, please update one more time and then it should be okay again (F5).

The next version will feature a API for integration CRM systems (see https://doc.vodia.com/docs/integrations-framework). This should be able to address that. If you want to use it, please use version 68.1 which is currently a "alpha" release but the integration framework is already included.

There is actually a setting that must be explicitly enabled to allow empty passwords. Believe it or not, but we have customers with devices that cannot have passwords. But that is clearly an exception. If that setting is disabled, empty passwords might be in the account, but you can't do anything with them because it will just not authenticate. Apart from that, when you create e.g. a new extension, you can have the PBX generate a random password that the user usually will never see.

There is no ticket with that number... Are you sure this is on the Vodia ticket system

Hmm nothing in the ticket system that would match GSC3510. Can you try to open a new one? It would be great if we can use "real" names, those P-values are very hard to read for humans.

Looks like a very cool device. I want a couple for home, so that I can page the kids when dinner is ready! Do you have a working config that we can use as base for the provisioning template (maybe attach that to a ticket)? I guess we need something for multicast and something else for unicast?

Admittedly its really a hack, but you can actually change every web site as you wish. Try it with your bank login (okay, it affects only the front end ). The Vodia backend will be able to change the page if it is actually a page that does exist.

You can customize the template page... Or just edit the page quickly in the browser inspector. Its a hack, but works and gets you what you need.

The problem is that according to the RFC it is totally fine that the codecs for the different directions are not the same. You can try an internal call, and if it fine this might be a trunk problem. Many SIP trunks have problems with different codecs on send and receive. On the trunk side there is a setting "Number of codecs in SDP answer" — set it to 1 so that it is always clear what codec to use. Or force it to a specific codec, e.g. PCMU.

It all depends on the trunk. If you are using a trunk from the dropdown list it should all be set up properly for you. Otherwise you can do it yourself, see https://doc.vodia.com/docs/trunk-custom-headers and https://doc.vodia.com/docs/trunk-ani. If you have a trunk that is not on the list, you are welcome to share the trunk settings, and we could add them to the drop down so that the next customer does not have to figure this out again.