Vodia PBX
-
Posts
11,110 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Vodia PBX
-
-
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.
-
57 minutes ago, mcbsys said:
I could see the issue for hard phones taken home, if that were ever to happen. From what you said earlier, as long as they just use phone/desktop apps, no need to open SIP to the world, right? Just HTTPS and RTP?
BTW I'm curious why you say, "you need only HTTPS to be on the standard port (443)." Is is it just to simplify so users don't have add the custom port, e.g. https://pbx.domain.com:8443 ?
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.
-
7 minutes ago, mcbsys said:
I was planning to just use the Azure firewall to lock down SIP and I guess LPAP (which I'm not using yet) to the customer's IP and trunk's IP addresses. Seems that should eliminate all junk traffic, no? In other words, why change default ports if the only IPs that can reach the system are known and trusted?
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.
-
14 minutes ago, mcbsys said:
@Vodia PBX, good tips, thanks. You're recommending TCP but not necessarily TLS for the SIP traffic from the phones? My thought was to get things working on default ports and protocols, then start tweaking.
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
+3362346532and your US-based provider presents that as3362346532, 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>|*87200then the phone will use the*87200to 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.
-
We definitively have to have something when the password is incorrect. Once the dust has settled a little bit on the new font end, the heat beam will move back to the mobile apps.
-
The Vodia IO runs a regular Linux operating system. If you can get into the system using SSH, that would be an easy way to take a look around and possibly reinstall the PBX. But you can also mount the SD card on another computer. The Raspbian web site certificate seems to have expired yesterday, on a side note... But that site should have an image that you can put on the SD card and boot from there again.
-
It is called comfort noise. There is a file noise.wav in the audio_moh directory. If its too loud for you you could replace it with something else.
-
30 days
-
Well you get notifications on the watch, like new voicemail or text messages. As far as we can see, doing a call over the watch seems out of reach, at least we have not seen any VoIP app that uses the watch for actual talking.
-
We do have updated app versions in the pipeline which will include the close button handling.
Galaxy XCover 5 (android 13) not working on 4G
in Android App
Posted
Wow. Does iOS work the same way?