Vodia PBX
-
Posts
11,110 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Vodia PBX
-
-
On 6/2/2023 at 4:43 PM, mskenderian said:
Is it possible to add a passkey to a script living on a server?
I don’t know how that works?
if you concerned about basic auth, we should just do what everyone else does. Use API keys.
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.
-
17 hours ago, Scott1234 said:
Is the mailbox setting you speak of a V69 feature ?
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.
-
8 hours ago, mskenderian said:
while passkey become widespread, can we display the passkey prompt in v69. i am not against passkeys, but users will get confused onto why they are getting prompted. a simple system level and tenant level setting can ease the pain while users get used to passkey and how they work.
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.
-
28 minutes ago, cwernstedt said:
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?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.
-
Oh wow we were not aware about buttons on that device... Can you open a ticket and attach the XML config export and we'll take a look?
-
We still don't have usage data for SMS. How are you billing for call minutes? Are you using the rate tables? Would this be a way to add it to the bill?
-
This should not be related to the group permission. I think the easiest way to experiment is to use a service flag and assign it to the extension (is in the redirection settings on admin level right under the DND setting, "Classroom DND control"). Otherwise you'll have to midnight to see any change.
-
You can see the MOS for a trunk in the page for the statistics for the trunk. Same for each extension. But I agree it can take some time to find the exact call that was causing the problem. At least there is some kind of hint.
MOS scores are a little confusing because their range is between 1 and 5. There is no MOS 0. If the MOS is 0 that is more like a hint that there was simply no information about a MOS. For example, there was no call or at least no media.
-
We made some progress. This will be pretty much another SMS provider. You'll have to create an App on the Facebook App Store and point the incoming messages to the PBX. The format of the messages will be similar to what other SMS providers are delivering, but all in all it will follow the same script.
-
On 5/27/2023 at 4:22 AM, cwernstedt said:
It would be an essential security feature if the server could detect such connections and not accept them.
We made that a priority ten years ago, e.g. added a feature so that secure calls can also be terminated over a seemingly insecure SIP trunk. For example when a PSTN gateway is connected through its own Ethernet cable to the PBX, this could be deemed secure. But the feedback was a little disappointment, in a nutshell nobody cared.
The solution to disable all non-secure ports and force the phones to use SRTP through a general parameter seems like a workable solution for now. We don't have to change anything in the PBX, and this is an easy parameter setup that should address your requirements.
-
There are a few things you can do here. First of all, you should set the minimum TLS version to 1.2. This is actually required by most browsers today.
The next thing you can do is to clear the ports for SIP/TCP and SIP/UDP. Then there will be no SIP without TLS.
You might also clear the HTTP port and leave only the HTTPS port open. Same for LDAP and LDAPS.
If you don't have the HTTP port available, you must use your own certificate (Lets Encrypt needs port 80 to be open). Alternatively you can leave HTTP port 80 open and set up the firewall to accept traffic only from the Lets Encrypt servers—though it remains a question what IP addresses it is coming from.
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 will need some tinkering to make sure that everything really works, but at least you can rule out unencrypted traffic is on the server.
-
We have over the years constantly added features to the agent model. As far as I can see these are the differences between agents and regular extensions:
- Queues can play a hotchpotch of announcements to callers, send SMS to callers waiting
- There are various statistics available for the performance of agents and queues, online and by emails
- Call ratings from customers, and call categories from agents
- A new wallboard for full screen display
- Support for remote control of desktop phones (for superiors audio quality in call centers with professional headsets)
- Condition-based inclusion of additional resources, agents have control over "logging in" to individual queues
- Outbound calling from upload able call lists and other sources like missed calls
- Virtual hold for long waiting times
- Call position announcements and wait time estimates
- Handling in inbound text messages with agents
- Integration of mobile agents e.g. through condition based routing
- Management features like call recordings and call log reviews
- Automatic call recording and integration with third party call recording software (e.g. SIPREC)
... and more features will be added.
-
We are currently investigating issues with the caching with the Windows app and version 69. It seems to be working all fine from the browser (at least after you refresh the page), but in the app there seem to be inconsistencies. We might publish an updated version of the app shortly.
Automatic DnD for Classroom extension
in Extension Setup
Posted
That might be a glitch.