Vodia PBX

Hello there! Can you provide a little more context? How can it be on the same trunk, internal calls are not supposed to hit any trunk... Where you do see it? On the VoIP phone, or on the app? If it's on the VoIP phone, is this visible in the SIP INVITE?

We have a great relationship with QuestBlue (even a few drinks). if it's really them let's collect the logs and talk to them, I am sure they would see if there is something that can be done on their end. Or maybe we just need to indicate that we are using UTF-8, and not something like ISO-4565.

We are now at 68.0.28. There was a problem that the TLS connection was disconnected because of some TLS configuration, but I think that is definitively okay in 68.0.28 now. That would explain what you cannot receive any SMS/MMS. For outbound MMS, this might also be the problem because it cannot pull the content from the PBX — because its also TLS. TLS has become pretty important!

Thank you so much for this great tip!

There is 00, 011, and also 0011. It is indeed very confusing if you have many countries involved. The PBX internally always converts it into the +-notation, and only converts it for presentation reasons. So when a user in the US receives a call, it should show as 011-44-xxx, while the same call would show for the UK caller as 00-1-xxx (probably 001-xxx). That is perfectly okay. In order to make it easier to write dial plans, there is a setting in the dial plan of the PBX how it should present the number to the pattern matcher, and again, if you don't like the default, you can explicitly say there how it should be presented. The telecom world would be simpler if everyone just uses + — but is it not...

For the PBX, emojis are just UTF-8 characters. This works (surprisingly) beautifully between the apps, and as far as I can tell the SMS gateway should take care about conversions if necessary.

Wow. Does iOS work the same way?

From the PBX perspective, the W70B should subscribe for the message-waiting event and then the PBX should send a NOTIFY when there is a change (that's how practically all phones do it). Do you see that subscription in the registration tab for the extension?

If you are synthesizing text to WAV this will always take a little while the first time — but then it in the file system and the delay should be negligible. Setting up two-way media also takes a while. Anyhow, I would generate a PCAP and there you can see in all detail what is going on.

Yes the apps only need HTTPS and RTP. The question is if the user will ever enter or see the PBX URL. In the browser they do, and in that case I would for the sake of simplicity use the standard HTTPS port. If they are exclusively using the apps where you don't really see the port, you can as well just use a random port.

If your customers have fixed addresses, you can actually really cut off most of the junk. This is almost like a SD-WAN or VPN then. The problem are the mobile phone apps and people working from home, where you simply cannot catch up with the changing addresses.

TCP and TLS... If the phones support TLS, this is much better than TCP. Some firewalls start messing with the packet with their application layer gateways, which are usually completely useless for SIP. This makes troubleshooting very difficult and frustrating and this is another reason to use TLS. The problem with default ports is that you attract scanners. Choosing a different port just reduces the amount of junk traffic typically by a magnitude. For example there is no reason to use a default LPAP port because they are always automatically provisioned anyway and so are the SIP ports unless you choose to manually provision phones.

As for port numbers, you need only HTTPS to be on the standard port (443). If you are using LetsEncrypt you'll also need to use port 80 for HTTP. All other ports can and probably should be on random ports. RTP (UDP) needs to be open in any case. Make sure to pick a reasonable large range of ports so that the risk of someone hitting your RTP is lower. If you are using VoIP phones, you should try to stay away from UDP. Most VoIP phones today are able to do this properly. If you are using LDAP or LDAPS, you will also have to make those ports accessible for the VoIP phones. I would try to keep SIP/UDP really just for the SIP trunk provider. That means you can allow traffic only between the SIP trunk provider and the PBX. And if you are using the apps, you need to open HTTPS for the apps in addition to the RTP ports. The apps don't need SIP or LDAP ports.

I would move to 68.0.28 — there was a memory leak in that version that has been fixed. You might just have run out of memory in that version.

Yes you can set this up in the tenant admin view. Just go to the provisioning tab and check out the app settings.

Well the + is there for a reason. It makes it clear, and the Europeans are actually quite used to it considering there are many country codes in Europe. I would dare to say that most SIP trunk providers today gladly accept phone numbers that begin with the +. At least it is worth a try for outbound calls. For inbound calls, things are indeed confusing. When you receive an incoming call from +3362346532 and your US-based provider presents that as 3362346532, is that +3362346532, or is it +13362346532? As a matter of fact, we know that several providers make it impossible to detect a French number in that case. But if you set the country code for the trunk, it will read the number according to the local rules. This is a setting that can be separate for each trunk, e.g. if you have a trunk for a US-based number and another one for a French number, they can peacefully coexist on the PBX. BTW IMHO it's ridiculous that SIP service providers are not using the global form. Whenever possible, please point it out — maybe they will at least offer a setting where you can turn it on.

We are really trying to resolve the password issue for a long time... This is the steps we are taking: The administrator is considered to be careful with password and in the admin interface, the PBX will not check the password history any more The goal is that users should not be able to enter passwords on their own; instead the PBX will generate time-based tokens for login Users should be encouraged to use a password manager; blocking repeated passwords are helping to do that We are introducing passkeys where possible; this eliminates the need to store any password on the server Second and multiple factors come with passkeys without the PBX having to deal with the details and provide superior security along with a great login experience

On the snom phone you can try to put a number like this: <sip:200@mariana;user=phone>|*87200 then the phone will use the *87200 to pick up a call.

Please open a ticket o the support site and attach it there.

If UDP works but the other transport layers not, you can rule out problems with the MAC address range. If TCP does not work, I would bet 90 % on problems with the firewall, and for TLS I would think that it has to do with the certificate and the chain of trust.

There should be a new app in the App Store — does that make any difference? What version of the PBX are you using?

There is a new page on how to use node.js for pulling information from the PBX (https://doc.vodia.com/docs/using-nodejs). Would that be an option?

Did you set the country code for the trunk? That might help reading the number in the right format.

Its certainly not written in stone, but we need first to get version 69 frontend to do whatever was available in version 68.

I doubt that the TLS version is the issue, but you should set the minimum version to 1.2 because many browsers today bark at TLS 1.1 or even 1.0. I would try with TCP if that works. Then check if the device is able to pull the configuration template with TLS/HTTPS. That would mean that the TLS version is not the problem. If SIP/TLS does not work its probably because Yealink does not send the SNI extension by default for SIP/TLS (it does for HTTP though) and the PBX is struggling to figure out what tenant is being used. If that is the case please make sure that the system management DNS address is set and has a valid certificate — this is the one the PBX sends when the Yealink base wants to use TLS for SIP.