cwernstedt

No change to the timestamps of pbxctrl and pbxctrl.dat . (They still have dates prior to the attempt to update.) I know I'm looking in the correct directory because log2023-09-04.txt is present and recently updated. ./pbxctrl --version reveals: Version: 63.0.1 Debian64 Date: Apr 26 2019 So no luck…

I'm trying to update from v63.0.1 to a later version (v68 or v69) using the web admin interface, but after reboot, the server version is the same and nothing has changed in the directory of the pbx ( /usr/local/pbx ) . Web interface reports "The software update was successful. Please restart the system to complete the update." Disk space usage is at: 53% How can I further troubleshoot why the update isn't happening?

Does Vodia v63.0.1 support RFC 5746? If not, it's not a surprise that Bria has problems now.

Thanks @Scott1234 . At least now we have some hope of resolving the problem.

User devices are set to auto-update (iOS users don't normally select updates a la-carte), so the date of the onset of the problem dosen't correlate with when Bria release notes claims that RFC 5746 begun to be mandatory. In any case, I'm really pissed of by Bria who pretends to offer an enterprise/teams solution when they don't communicate compatibility-breaking changes well in advance. All normal companies do this. Usually we're given a heads up of multiple months if not years, if there's a new requirement. Thanks for the info on 68.0.28 / 68.0.32 . When you say RFC 5746 was enabled by default, does this imply that in earlier versions, RFC 5746 could be manually enabled by setting some parameter? We have 63.0.1 . I'm not a fan of having to panic-upgrade as past upgrades have tended to break things.

Yesterday the Bria client for iOS stopped working for all our users. The reason according to Counterpath: The PBX must support RFC 5746 (aka Transport Layer Security (TLS) Renegotiation). Is this supported in any of the later versions of the Vodia PBX?

It is arguably a different world today when few have local PSTN gateways and most traffic happening over the Internet. Eavesdropping on the Internet or public WiFi (if using soft phone) is a much bigger threat than local packet sniffing. So today, if admins don't think they need the servers' assistance with ensuring encrypted links at all times, they are insane. There's an interesting discussion here about detection of encrypted vs non encrypted RTP: https://www.twilio.com/blog/srtp-deep-dive Twilio for their SIP trunks has an option to enforce SRTP and TLS for SIP, so since we use them for trunks at least we are covered in that regard. You mean a general parameter on the phones, such as setting "RTP Encryption" to ON on a snom phone? Is there a way to check that phone settings are working correctly, except by sniffing packets and looking for, for example, "digital silence" as described in the link above?

Thank you for these suggestions. "As for SRTP, there are various settings for the devices that you use to enforce SRTP. E.g. you can use the snom General parameter to enforce SRTP. The apps all use SRTP and TLS anyway, there is not even an option to do it insecure." It seems SRTP is the biggest "hole" right now with regard to enforcement of encryption at the server. (A user knowing their SIP credentials could connect a misconfigured or malfunctioning device and use unencrypted RTP = nightmare in a corporate IT security context). It would be an essential security feature if the server could detect such connections and not accept them.

Hi, I have a requirement such that no calls can take place unless all involved protocols and traffic are encrypted using up-to-date protocols (e.g., TLS 1.2) Old devices/endpoints with configs that don't adhere should stop working. What would be appropriate settings to make sure that this is the case? (In 2023 it is no longer acceptable to have no guarantees on the PBX with regard to secured links, just like most web pages now prevent the use of non TLS requests.) Best, Christian

Update: Twilio will never install wildcard certs on their localized endpoints. Their stated reason and workaround: "Twilio does not present wildcard certificates for SIP as most standards-compliant devices don’t accept them. So you may not see a certificate that matches their personalized domain name exactly. If you can configure an “outbound proxy” or route on their SIP device, you can set this to “pstn.frankfurt.twilio.com” which will match the certificate our edge presents." This solution seems to work.

@Roozbeh I'm running into this issue too, and Twilio support is clueless. Did you receive any responses from them regarding fixing the issue?

Where does this setting (c2d_root) reside in recent versions of of the pbx? Can it be changed from web interface or is it inside a file?

I upgraded to version 68.0.1 . Certificates are still not successfully updated. I see "Could not retrieve directory from directory https://acme-v02.api.letsencrypt.org/directory " in the log.

OK. This is what I see in the log (the real domain name and IP address I've censored out) after renaming the System Management DNS address and then renaming it back. The line with "Could not retrieve directory" looks suspicious. Any idea? LYNC: Creating pbx-admin.xyz.com [6] 13:28:32.009 LYNC: Using IP address 20.203.51.134 for creating DNS A record for pbx-admin.xyz.com [8] 13:28:34.526 LYNC: Create new account [3] 13:28:34.921 LYNC: Could not retrieve directory from directory https://acme-v02.api.letsencrypt.org/directory [8] 13:28:34.921 LYNC: New order pbx-admin.xyz.com [8] 13:28:34.921 LYNC: Done creating pbx-admin.xyz.com

In this case it's Let's Encrypt which sends me expiration warning emails, so it's the PBX which failed to renew the certs for some reason, and they do expire within a week or so, indicating failure to renew quite a long ago. Version is 63.0.1 . I haven't dared to update for fear of breaking something. Some way I can troubleshoot further?

Let’s Encrypt Certs have suddenly begun to expire on our PBX with no configuration change. What might be the cause?

How could that happen? Bug? Server wasn’t touched except for a reboot.

After reboot, the call history shows all calls as having been made on 12/31/1969 7:00:00 PM . Version is 63.0.1 (Debian64) . Any idea of what happened here and how it can be prevented in the future? (Fortunately this time, the log isn't needed.)

DNSmadeEasy provides a user name, and two keys: API Key and Secret Key . From these three, what should go into the two fields provided on the pbx (user name and password) ? [Solved on my own: Should be API Key and Secret Key for user name and password ]

To clarify, this is the situation, and maybe there is a misunderstanding: Twilio utilizes, for example, the below IP-addresses and with 3.122.181.0/24 network for Media being put into use on Monday next week. Is it perhaps the case that only the signalling IP-addresses need to be configured in the Vodia trunk settings, and that media will flow regardless of if the originating Media IP-addresses match trunk settings? If so, Twilio users should be fine...If not, there's a lot of trouble coming. Signalling IPs: 35.156.191.128/30 which translates to: 35.156.191.128 35.156.191.129 35.156.191.130 35.156.191.131 Ports: 5060 (UDP/TCP), 5061 (TLS) Media IPs: 35.156.191.128/25 3.122.181.0/24 Port Range: 10,000 to 20,000 (UDP)

I have this problem now with Twilio as they just added a class C network , and things will stop working next week unless I add it. (Trunk doesn't get properly identified on incoming calls without the IP-addresses specified.)

Ok. Where do I configure these things in this version? Ideally I would like to prefix +423 to all numbers lacking a 00 prefix (local numbers) and replace 00 prefixes with + for international numbers. So 2371336 would turn into +423 2371336 and 0013343456666 would turn into +1 3343456666 . (Incoming calls only)

Hi, Well, it's the inbound (not dialed) that I'm looking to change. In other words, the number that is presented on calees' phones and in logs etc. The trunk provider presents local numbers without the correct international prefix, which makes it difficult to process these calls correctly.

One of our SIP-trunk providers isn't particularly good about how they present the CIDs on inbound calls. Is there a way to rewrite these according to some rules, for example replacing 001 with +1 , or adding a country code to local numbers. Note for clarity: I'm talking about how numbers are presented in the From field in CDRs, logs, etc.

Can you take a look at the packet captures zipped and attached to the earlier message? ( )