Vodia PBX

Right now the simple CDR format is a global settings. But it does not hurt to have an optional third argument after the port! So next version will allow cdr:192.168.1.2:10000:$w$5g$10c$5d, however obviously the port must be there then and the pattern cannot contain spaces.

There should be a lot more options that just the 1 minute... Anything wrong with your drop-down?!

The process with the session looks right. Are you sure there was not a little glitch somewhere? Maybe you can get a PCAP just for the HTTP traffic and send a private message (or open a ticket) so that we can take a look at it.

The description can be found in the pbx.xml and in the https://vodia.com/doc/cdr page.

I believe support tried to ask you to send the key in a private message. Anyway, we have redesigned the Aastra provisioning from the ground up, you should try version 57.2.

Of course you can always script it, e.g. using curl. You might have to login and get a session token, but AFAIK that is not so difficult with curl. The key point is that you need the username and password. If you have it, it should be relatively easy.

This would work only if you have the username and the web password for the account. Using the admin username and password is not really a solution as this user then you have admin right, and could access admin content as well.

I would try with looking at the SIP packets and check if the routing there makes sense. Next step would be a PCAP on the phone (from phone web interface) and then also on the PBX, just to see if they look the same. Sounds to me like a glitch in the VPN setup, like a wrong netmask.

Sounds to me like dialing some well-known numbers would be the easiest solution to this?

We do have the schedules playback, it is using "playpage.wav".

This must be an attended transfer then? We had some major problems with GXP1628 where a INFO message was not well received by the phone... This issue was fixed in 57.0; maybe you can give the new version a try.

There is plenty of information available for wireshark, e.g. on https://www.wireshark.org/

Seems like there is on HTTP request that blocks the rest of the requests. If you can easily reproduce the problem, I would suggest that you take a Wireshark trace to see which requests blocks it and why. Maybe the HTTP server gets non-responsive and that turns the PBX off.

So far this file this only available on global (system) level. So you have a problem saving the file from the web interface? That should actually work, and take immediate effect. Maybe you can use an online XML validation to make sure there is no typo something in the XML spaghetti. What you can also do is just save it in the html directory as "ringtones.xml", that makes it easier to do quick changes. For that you will have to restart the system, though.

Eh yea this is still in progress... Unfortunately TAPI is kind of hard to build these days, we need to dust off old laptops to find the kind of build environment that can still produce it. I am not even sure if it is still officially supported by Microsoft.

Rates are actually a feature that must be licensed. It comes with the hosted license by default, but for the other CPE licenses is has to be added.

Yea that is actually a common problem. Thanks for sharing that with us.

Seems like when using certbot, all we need to do is to write a piece of code that drops the challenge answer into the tftp folder of the PBX, so that the bot can pick up the answer from the PBX. If the PBX trusts localhost for REST API commands we could also script something that automatically uploads the certificate into the PBX.

The final stage works different than the other stages. The PBX essentially redirects the call to that number, which means this call is not a hunt group call any more. Instead it is a call to the extension (which is actually an auto attendant call), which means that the mailbox may kick in, or other things like cell phone forking. What you could do is to move the 201 to stage 3 and have a long timeout there, e.g. 60 seconds. I would then use 8201 (the mailbox of 201) as the final stage, so that the call eventually ends up somewhere.

The key to make sure that the firewall is not the problem is to watch the traffic on the PBX, e.g. log REGISTER requests and get PCAP traces e.g. for calling the mailbox. Also for single-domain (e.g. CPE) deployments make sure that the domain name is "localhost" and not changed so something else that does not match what the phones are using.

The client is included. When you log into the PBX web interface and switch into the user mode, then the PBX will provide the needed code. In the Android app, it is similar.

OK, WUC stands for wrap-up-code. It is not used yet, but eventually will be used a add a tag to a call, e.g. a rating.

I just tried that over here on our domain, it works here. Not sure where the problem is. Maybe you can open a ticket and include a username, password and hostname where we can try this out.

Ehh root.wuc? Where? Agreed, could be wake up call but where did you find that?!

Well but how otherwise would you redirect a user to the http login page? Keep in mind that this is optional, and make most sense when you have a valid certificate installed.