Vodia PBX

Well in the latest version 69.0.5 (as we all know 69 is maturing) an administrative account can change the DND status of extensions through the front end by clicking on the account and turn DND off. The permissions to monitor the mailbox does that. I believe that is a workable solutions for most environments where users need some hand holding. But we need to keep this on the radar. I would be hesitant to immediate make that another account permission or feature, after all we were able to survive for the last 18 years without it and we might be able to survive another month or two without it.

But the site ID would not be a general parameter, it would be parameter for the MAC address? Otherwise, if it's just a general parameter YMCS would not take notice?

You would definitively see the OPTIONS packets, e.g. by filtering SIP packets by the IP address. If you don't see them—something is wrong. Originally we did that for Teams (not sure why, probably just the "Microsoft way"), but other vendors are also starting to use OPTIONS as well and this seems to work fine.

The name is "Explicitly list addresses for inbound traffic". The whole logic of figuring out where packets can come from is tricky because of the DNS NAPTR, SRV, A, AAAA records that are in play. Its also tricky to figure out if something is changing!

I have no doubt that the registration is stable. It's just the glitch with the notifications. sip-anycast1.telnyx.com and sip-anycast1.telnyx.com seems to have a random TTL between 1 and 60 seconds, and maybe we see those glitches because it changes and then that address is not on the IP address whitelist any more. I would assume that the glitch goes away if you add the 64.16.250.10 and 192.76.120.10.

You can include the field names like this #alias;first_name;last_name;email;position 123;Gunter;van Dunkel;abc@def.com;President

Thanks for the great analysis. We had a similar problem many years ago with UDP and missing SBC on the SIP trunk provider side. OPTIONS work only for SIP trunks that don't register. If the SIP trunk does register, you can instead the "Keep-alive time" and force the PBX to re-register every 3.5 minutes or so.

Oh great... But can you connect e.g. with Safari?

As far as I can see it might be because the associated IP address has changed, even though the registration status stays the same.

That might be a glitch.

The PBX does not care how the client comes up with passkeys. IMHO it's really more for the humans, not so much for the robots. But it might be an interesting exercise if there is already some code e.g. for nodejs. For scripts, if you whitelist the server addresses, use encryption and a random password, that should be billions of times safer than Joe Doe recycling his favorite password even when using Basic, which is then as safe as any other token e.g. coming from OAuth.

The trunk status change emails are (supposed to be) independent from the registration metrics emails. They are only sent out when something has changed. Are the subjects exactly the same for the status change?

It might be because Bria does not use DTLS (SDES), in other words not end-to-end encrypted. You can see the keys in the SIP messages with SDES, which is becoming kind-of not-okay.

It is actually tempting to add that, seems like some users push any button they can find and then open a ticket. But there is a workaround, you can define who is allowed to call in spite of the DND status at least for internal calls.

If I remember correctly you can explicitly put the names in the first line, after a hash. BTW you should take a look at how it's done in 69. Seems like everybody hates 69, but that part might become an exception.

Yes. Its called "Offer return to previous extension when hitting a mailbox" in the tenant mailbox settings.

Ok it makes sense to use the ANI when possible. There is a little problem with how to present the number in the right format; we'll use the trunk setting for that which should be okay in most cases (the SIP trunk world would be easier if everyone just uses the +-notation).

You need to enable API access for the admin account in 69. Or better create a secondary account for access and enable API access there, possibly add IP address whitelisting as well. This is because the Basic authentication is just very dangerous in terms of replay attacks. V69 offers passkeys also for the administrators, which should dramatically reduce the risk of getting hacked.

The prefix is for admin emails, not for end user emails.

We will have to add an option what to do after a successful login with a password: Ask the user for storing a passkey or not. If the user denies it once, then the next time it would not ask again unless explicitly enabled.

Well computers are obviously always right, it just depends what they are told to do! We also saw the registration numbers sometimes veering off, it seems to be related to counting the wakeup "registrations" as well. It's obviously debatable. But we could argue that one extension can have multiple registrations, and then it could actually be that there are more than 100 % registrations. Frankly, it was not a top priority and the number was supposed to be indicative.

Well, it's a difficult topic. We'll maintain the 68 version for some time, and this should include such topics as SMS providers. We gladly make 68.0.31.beta builds with necessary changes. When it comes to the new interface, it would be good to know what the customers don't like. Is it the appearance? Or does it take too much time, clicks to perform certain steps? Or is there functionality missing. I don't want to get into the general reason why there is a new front end. A general "don't like it" is hard to fix.

Thanks, great contribution! BTW the PBX offers a transfer reminder for the blind transfer; however it remains a difficult topic for example of the extension has already the next call going on. If it ultimately hits a mailbox, the mailbox now has the option to transfer the call back to the last extension that the caller spoke to. This might also help not to loose any calls.

Classroom extensions can't use the apps. But from the desktop phone, they can change their DND status until the next automatic transition happens.

The good news is that the phones have that setting that really enforces SRTP. You can essentially rely the setting. Plus if your SIP trunk provider enforces it as well, you should really be good. There are many ways that trust can be broken. For example, if Twilio accepts SRTP and terminates the traffic to a route that just records anything and sells it to the highest bidder, you would not even know about it. There's nothing you can do about it, realistically.