Vodia PBX
-
Posts
11,069 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Vodia PBX
-
-
17 hours ago, Vodia PBX said:
We are still on 68.0.31.beta, 68.0.32 is not out yet. We are waiting for feedback on two issues and then we should be ready to go for 68.0.32.
Ok 68.0.32 is available for download now.
-
There were some issues with groups and selecting specific extensions. IMHO it should be possible to narrow the scope of who can see what recordings in 68. There will be 68.0.32 shortly with the specific extension selection working, and that might also resolve this issue.
-
I don't think you can use websocket but we can take a look how much work it would be to add it as integration. How popular is it?
-
We are still on 68.0.31.beta, 68.0.32 is not out yet. We are waiting for feedback on two issues and then we should be ready to go for 68.0.32.
-
15 hours ago, JCEKen said:
The recordings appear to be uncompressed, even though the PBX setting under System Level->Settings->Recording/CDR is set to 'G.711', however the actual recordings show uas PCM 128kb/s 8khz mono, at a bit under 1mbyte/min of recording time.
The PBX has to convert G.711 to linear because most browsers don't play G.711. That happens on the fly.
-
20 hours ago, mcbsys said:
I’ll change it back to UDP registered or maybe UDP with FQDN.
I am afraid this might actually be a pragmatic solution. Maybe someone should dig out the original decision to favor UDP for SIP — who knows maybe Henning Schulzrinne & Co hat the connection stability actually in mind.
I am not aware anyone using DTLS for adding security, but that might be the next step.
All that said, UDP connections are also not necessarily stable, depending on the behavior of the firewall. When the port changes on the NAT bindings, you'll have the same short window where inbound calls will bounce (unless the firewall keeps both ports open during that time, which I doubt).
Firewall manufacturers could care more about VoIP and what a persistent connection means. Especially the manufacturers that don't have the slightest clue about and/or interest in SIP and their interference does not add anything in terms of security.
-
1 hour ago, koolandrew said:
Is the procedure for 69.0.x the same as previously to recover lost password, or is that possible any longer with the keys element?
In 69 you can click on "forgot password" and then use your email address to reset the password. This works also for admin accounts in 69.
-
Well right now they are dialing into the system then punch in the zone? Some VoIP phones support a DTMF button mode where you could put this on a button.
-
Thanks for the investigation, it's quite interesting not only for the Vodia PBX but generally on how to keep 24/7 up.
For me, the bottom line is that we will never be able to achieve 100 % connectivity with a client and there will always be spots in availability. It's the case for SIP trunk clients, but it's also true for VoIP phones. For VoIP phones, it's probably just a generally fact that they have their ups and downs when working from home and nobody complains.
It would be possible to address this with the OPTIONS architecture where the UAC initiates a connection and the UAS receives it, depending on the call direction. And maybe in situations where inbound calls are very critical, this should be the preferred setup. But even there we will still have the problem that the clients also have their time when they are offline, and calls would still not connect. I would dare to say, that those VoIP client spots are much more significant that the connection between the PBX and a SIP trunk (it would be interesting to have some real numbers).
What speaks for the SIP trunk TCP/TLS connection is that it is easy to setup, it can be secure, the stability is probably better than with the VoIP phone connection when working from home and maybe one more thing to keep in mind: The PBX can report the availability, e.g. through emails when the trunk status changes. That is a lot harder when using UDP or TCP/TLS with OPTIONS where it might be very hard to find out when the trunk is actually down.
-
6 hours ago, RichardDCG said:
... it has now appeared in the certificates with no additional prompting from me.
... probably because of the midnight check. Anyhow, next build will make this easier (to understand as well).
-
When deleting the certificate, well getting it back is not easy in the current version. The reason was that the operation was essentially done every day and this caused a lot of unnecessary cert activity. Anyhow, in the next build the PBX will request a new certificate if you change the addresses for the tenant.
-
14 hours ago, dan003400 said:
We are trying to deploy to a hosting provider but we cant seem to get the server to bind to 0.0.0.0:80 when deploying there. This is causing their proxy to not pick up the service and expose it to the internet.
That probably means that there is another process listening on that socket. You can use
netstatto see which processes are there.14 hours ago, dan003400 said:We also noticed that there is a --config option for the pbxctrl executable but there is no documentation for this file, can this please be shared with us?
The
--configjust gives you the option to use a different file than thepbx.xml. -
-
5 hours ago, RichardDCG said:
ACME log says the name is not available.
Can you paste the exact phrase, so that we can match this with the code? But it does attempt to fetch a certificate? You can also turn on the logging for the web client to see the traffic between the PBX and the LE cert bot. Is there anything?
-
Hmm which command is prompting for the region? The script installs some additional software, but you can as well just skip that part of the installation. E.g. the PBX now downloads missing audio files automatically.
-
The certificates live outside the tenant, and that means that they are not part of the backup. Admittedly, that's debatable but it makes sense if you choose a different name for the tenant later.
The Lets Encrypt certificates should eventually show up, especially if you trigger a name change. When you create a new tenant, it may take a minute before thats the case. There is a ACME (thats actually the name of the protocol that Lets Encrypt uses) log level which will show you some progress messages when the update mechanism gets triggered.
-
Hmm so you can move from 69.0.6 to 68.0.30, but not from 69.0.6 to 68.0.31.beta? Maybe you can double check that the upgrades went through with the --version option from command line and also make sure that the .dat files match. As for the login, please make sure that the browser cache is not playing tricks on us, especially if the welcome.htm page was modified.
-
Hmm... You can check from the shell
./pbxctrl --versionwhat version you are running. Also, you can check what time the.datwas updated. Maybe a file did not make it? -
29 minutes ago, mcbsys said:
I prefer not to run beta software especially on customer systems. Is there a way to subscribe to notifications for software releases?
Of course. Maybe you have a test system somewhere. Anyway, the plan is to release 68.0.32 on Tuesday or Wednesday next week.
-
17 hours ago, mcbsys said:
Unless of course Microsoft sent the FIN outside the machine because ... they wanted to reconnect the interface or something.
I thought TCP would mean more stable connections for a PBX, with TLS a nice security bonus, but it seems to be just the opposite... TCP/TLS, at least as provided by Azure, reduces stability and reliability for long-running connections.
For me, the bottom line is that Microsoft and others choose to establish a new connection for incoming calls because they also found out that keeping a TCP connection alive for a long time is hard to achieve and it is more reliable to establish a new connection (possibly, retry if it does not work on first attempt). After all, browsers literally connect billions of times every hour and it works very reliable. The price for this is that the client cannot be hidden behind NAT.
In other words, as far as I can see it, if you want to stay behind NAT and avoid manual setup of the PBX address, you will have to live with the fact that the connection drops from time to time for a short while and incoming calls will not make it.
BTW the Teams clients are also living with that fact. I am pretty sure that if you watch their connection stability, it will also have their ups and downs. But it is limited to one extension, and not the whole organization.
-
If you can, try the 68.0.31.beta version which should have that "confusion" fixed. We'll make that a 68.0.32 soon.
-
The "SMS not enabled by default" is most likely the problem here. There was some confusion when SMS is enabled for the tenant between the versions. The log message suggest that is should be enabled looking at the settings, but, well, it does not seem to be enabled. Does it work if you enable it in the domain? We will make another 68 build where this should be working as one would expect.
-
12 hours ago, mcbsys said:
So it sounds like the FIN-ACK coming from Telnyx would be a reply (ACKnowledgement) to a FIN from the PBX. But I don't see the FIN. Maybe it was encrypted?
Hmm why would the PCAP miss the FIN? Maybe some firewall in between did it? FIN (still, not being the expert) is not encrypted because its TCP not TLS.
-
On 7/17/2023 at 8:26 PM, mcbsys said:
Is it normal to get a FIN periodically? [Update a bit later: well really it's a FIN, ACK coming from Telnyx to the PBX. So does that mean the PBX sent a FIN first?]
It should not be normal... The FIN, ACK looks good to me (not being a huge TCP/IP expert), I guess the ACK is kind of preemptive. Anyhow the PBX sends the same ting back and that means the TCP connection is closed.
Which raises the question what Telnyx (or, any provider) is doing to keep a TCP connection alive — for weeks, months, years. How do they do software updates? UDP is much easier in that respect, you would not see anything in the PCAP. Microsoft Teams is opening TCP connections in both ways, which does solve that problem: For an inbound call it opens a new TCP connection; however that approach has the disadvantage that the PBX needs to be on a public IP address. Maybe the time of disconnect is the price to pay for TLS with a device behind NAT.
Manage call recordings
in Call Recording
Posted
As you might have seen in the release notes, there is a new setting for groups. With the luxury of hindsight, we should have automatically added a default group right from the beginning; but we don't want to break things in a 30-to-32 upgrade by suddenly changing the behavior. Thus the setting to explicitly turn it on. I would give this a slight chance that it resolves the issue about specifying which user can see what recording. But obviously we need to set up a test environment where we can see this on 68.