Vodia PBX

There is one ".0" missing in the first netmask.

Are you calling into that auto attendant first? Or is this a direct call between two extensions?

There is a field "Accounts that cannot be called" in the auto attendant. You can try putting a "*" into that field. Or use the "Account that can be called" field.

For that you need to look into the states array. If you want to bill only for times when you really talk to a "human" (not a cell phone mailbox), that might be a little challenging as you would have to mix the different arrays.

That rings a bell with WebRTC: At least Chrome works only if the connection is deemed "secure". Maybe this has changed with audio playback as well?

If you want to do this properly, you cannot assume that there is only one trunk leg per call. For example, when forking to cell phones you might have more than one ("press 1 to accept the call"), and when using the virtual private assistant there can actually be many valid outbound calls. I know it might be more difficult, but you need to iterate through the trunk leg array and bill each item separately. The rest makes sense.

It is in the working directory of the PBX, unless you have disabled that feature in the phone provisioning settings on sysadmin level.

There are also other fields that determine the current time on the phone, just next to the timezone setting on the phone. What is their value? Do they make sense?

Did you re-provision the phone (what is in the generated folder for that extension)?

I think the problem is that the key is a PKCS#8 key, while the PBX expects a PKCS#1 key. That is the difference between BEGIN RSA PRIVATE KEY and BEGIN PRIVATE KEY. We will add code that in the next version the PBX will "eat" both versions. For now, please convert the #8 into #1 using openssl: openssl rsa -in pkcs8.pem -out pkcs1.pem

We have added something to https://vodia.com/doc/cdr I hope that helps to understand this complex topic.

Aha! That is a very important hint. The PBX is not able to match the private key with the top certificate (the private and the public key don't match up). We had that problem when the private key is encrypted, and, of course, if the keys really don't match. Can you double, triple check if you were using the right keys? So we are talking RSA keys with 2048 bits? What hash method? What you could do if you have an Apache running somewhere is trying to use the certs there and see if that works.

No, it can be done. We helped some fold with wildcard certificates already long time ago. It is a hassle, but it works (should work). Try to turn TLS logging on to level 9 when you import the certificate. Maybe you can get us another, similar certificate from the same CA so we can try this out. We had the idea to establish a Vodia Root CA, so that we can make this easier for PBX deployments. But the core problem remains that all users need then to trust the Vodia Root CA, which is even more hassle. That is why that dummy built-in certificate is still in there. On a side note, the whole thing around Internet certificates is badly broken IMHO. I few weeks ago I went through the list of "trusted Root CA" on my Android phone, it was shocking who this device is trusting. Maybe we do have a good chance getting on that list is as well!

The fix was made on Feb 13, 2015 for the snom phones. snom also keeps improving their software, making that change necessary... So if you upgrade to a PBX build after that Feb 13 date, it should be fine.

Maybe you can send us a private message with the certificates and the general structure of the private key (without the actual private key), so that we can try this out here in the debugger.

I don't understand why there would be a "USA". In the timezones.xml file there is a entry for snom: <zone name="EDT"> <description>Eastern Time Zone</description> ... <snom>USA-5</snom> ... </zone> In theory, it should render the "USA-5" there. Did you change the timezones.xml file or the snom_xxx.xml templates?

Everything needs to be base64-encoded. Use a text editor to make sure that you can see it. If you are using SHA2 certificates, make sure that you are using 5.2.6 or later. First comes the certificate it self, and then the intermediate certs in the cert input field. The private key goes into the input field for the private key. It must not have a password (this is not supported, as it would require you to enter the password when you start the PBX up). If it all does not help, we can import it for you.

Please consider using the provisioning. If we have to manually configure every phone, we will have a lot of work to do, for example with setting up the right ring tone.

Yes, the PBX only reports whatever was in the SIP packets. If the DID is outside of that, you would also have to have some external logic to determine the "real" DID number.

Actually there are several *60 codes, like *601 and *602. I don't even know what exactly they are about, one is for call pickup definitively. I agree it does not look pretty to have those codes in the call history of the phone; how would you otherwise have a call pickup in the call log instead of a star code (if the phone does not update the number after it was called). I wish today in the year 2016 we would have gotten over those antique codes, but that is probably the price to have those features work on all phones.

The *60 codes are special codes, e.g. for directed pickup of specific calls. E.g. after the code itself comes the PBX-internal index of the call. As long as they are user initiated (usually by pushing a button) that is okay.

The Display Name has usually no meaning when you call out on a SIP trunk, it just goes into the digital dust bin. Most SIP trunk providers are very strict on the numbers they present, so you cannot just pick any number you like. For example not everyone should be able to use (202) 456-1111. If you have a lot of DID on the system what you could do is set up an ACD for every one and have them log into the specific ACD; then outbound calls will use the ACD phone number, not the number of the extension. If the PBX runs outside of the NANPA region (US and Canada), you can easily add digits to a phone number. That might be something that would work.

Can you get a PCAP from the call? Back in 2014 we did not have that feature yet. Also, you might want to try out the latest 'master' build, 5.3.2a (which OS?).

We can send you the script that we are using in a private message.

After all, it is just a Beagle Bone... The network has not much to do with the PBX service, which is probably running "fine" except that it cannot talk to anybody. So anything you can find about the beagle bone would apply here. My guess would be that somehow the Ethernet chip got damaged with a power spike. Do you see the connectivity LED come up on the Ethernet switch? Can you ping anything in the network? If you can get to the console, you might be able to tar the PBX working directory and e.g. write it to a SD card. Then you can resume backup on another physical hardware.