Vodia PBX

Oh so you are talking about the domain setting "CMC authentication for outbound calls" when it is set to "#"? Hmm, in this mode just pressing # without any input well in theory that should also work. Why don't you set up a second dial plan for the extensions that don't need to enter a CMC and assign it to those extensions?

Well you could as well use a calling card account in the domain for this, where the user has to login with extension and PIN before making the call. If you want to use CMC for this purpose, you need to make sure that the domain address book has an entry with the CMC. This is how the PBX verifies the CMC code.

Yes there was a bug in that area (not sure which version exactly). Can you try 5.1.3 (backup first)?

I would not change the template for this. This will cause issues with the next update when we make changes to the template. You would not get these templates (we need a merging algorithm eventually). Just use the old name in the html/img directory.

What OS is that? Maybe you have an old installation where the executable name is not "pbxctrl" (or "pbxctrl.exe" in Windows). You can check in the startup script, usually /etc/init.d/snomone what the name is. If it is not pbxctrl, change the name in the startup script and also in the working directory of the PBX.

It runs the DNS NAPTR, SRV, AAAA and A resolution and comes up with one IP address. When verifying the domain, the IP address does not matter (unless it is in the domain name or outbound proxy). It checks if what is being presented as certificate matches the domain name, and if yes, it proceeds. Actually when I try, I can connect using TLS (certificate works). DNS resolution did not work out of the box, needed to add transport=tls but then the TLS connection was find.

Do you mean CMC or PIN? The CMC for outbound calls is used to track for which client the call is being made. The PIN is simply to avoid that someone makes an expensive calls from a random phone in the office.

No, the attendant console is it's own application that also does the audio. It is a soft phone, specially optimized for snom ONE. The history of soft phones is long. Starting with the snom 360 softphone, the m9 soft phone, then we had the PAC, the WAC, the UCClient a.k.a. attendant console. Today we are leaning towards WebRTC for the audio subsystem and have everything running in JavaScript in the browser, so that you don't have to actually install any software any more. But the field is highly dynamic, not only in the snom ONE environment.

cd /usr/local/snomONE tar cvfz /whereever/backup20140116.tgz --exclude tftp --exclude 'audio_*' . Note that there is no "-" before the options to tar. You might want to exclude also other directories, e.g. the recordings in case you are performing automatic recordings. For more information, search for "man tar" in the search engine of your chioce... In Windows, you can just ZIP the folder.

When you click on the edit button in the domain list, you will see a field "Alias Names". Make sure there is something in there, even a bogus name.

Yes, this is a known issue. You must use a alias name, even if it is just a bogus name. Then it should work.

No, TLS trunk don't require that (though it is a good way to further secure the trunk). You might stumble over the certificate problem, where either the PBX does not trust the client certificate from the SIP client or the SIP client does not trust the cert of the server. The log will show this on one of the sides.

Did you see https://vodia.com/documentation/pnp_prerequisite_steps and https://vodia.com/documentation/pnp_snom?

The idea to make a backup through the web interface was a nice idea; however it causes more problems than it solves. File system backup is the way to go.

The CDR are now simple from where to where. If the call was "inbound" or "outbound" is actually not so easy to say any more. For example, if someone from outside of the company calls any extension which gets forked to the cell phone of a user, is it inbound outbound or actually both? Or one extension calling the other? Inbound to me is something that is related to a trunk. However we got away from the pure trunk view, so that you can also e.g. internal calls in the CDR.

Hmm. Are we hitting a ceiling somewhere? In the old days there was a limit on how many CDR are included in the email, but that limit has been removed. The logic when to remove CDR is in 5.1.3 still not perfect; all CDR types are treated separately leaving the possibility of stale entries; though I don't think that this is the problem either. I think what we need to do is adding more logging in this area so that we know what happened.

Better take the 127.0.0.1 out; who knows maybe the PBX fails over the the 127.0.0.1 one and then the problems come back. Or configure your local DNS server correctly (probably it is easier to just take it out).

Well I would just set all log levels to 9 and do a quick call, then reload the log. This way you can be sure that you have all relevant information... You will see how the PBX sends the call through the dial plan and what patterns should match, but don't. Then probably it will be easy to see where the problem is.

Probably a mixup of pbxnsip and snom ONE license. Send support at vodia.com an email with the activation code and if you have it, also the base64 license text. We'll take a look at it.

Well that says that there is no DNS entry for www.snomone.com. It seems there is a DNS server running on 127.0.0.1. Either configure that one correctly or change the /etc/resolv.conf to point to an external DNS server, e.g. 8.8.8.8.

Well then the phone did not subscribe. We did work with the SPA112 (ATA), but that one does not have buttons. We probably need to get a SPA phone to try this out.

In centos you need to install tshark, "yum install tshark" if i remember correctly. Then you can run it with something like "tshark -i eth0 -w dns.pcap"

In domain mode, click on an extension and then select the registration tab.

Okay, we can rule that out then. The only thing that I can think of are global trunks that make it a little bit more difficult for the PBX to send the CDR into the right domain. Or do you see any other pattern in what is missing? Also, do you have a relatively short CDR duration or a small CDR capacity (maximum number of stored CDR)?

Do you see the dialog subscriptions in the web interface? That is a must-have to see anything.