Vodia PBX

You can make the DID (actually, in this case it is called ANI) dependent on the trunk that is being used. In the ANI field, you can prepend the ANI with the trunk name. Use space to seperate the multiple choices. For example, "Houston:2811234567 Dallas:9721234567 2121234567" would mean if the call goes out on the Houston trunk, use 2811234567, if it goes out on the Dallas trunk, use 9721234567 and otherwise use 2121234567. This implies that trunk names must not have spaces in the name. If you are using the same trunk for everything right now, you should consider splitting it up into one inbound trunk and two outbound trunks (to avoid two overlapping inbound trunks).

Internal calls and inbound work fine? If yes, we can exclude problems with the server itself and/or the phones. Did the phones update to 8.4.31 or later? Did you use PnP to configure the phones?

Well, it seems that the whole CANCEL sequence is triggered by the very first message in the log, coming from the trunk. It seems that the trunk for some reason wants to cancel the call. Possible ideas: The call was never connected for whatever reason, and after 60 seconds the carrier decides to cancel/disconnect the call. OR the carrier has a problem receiving a SDP in the 18x message (you can turn that off in the trunk settings); although I dont remember any SIP device having a problem with that over the last couple of years. It would be interesting to see the INVITE/183 messages that are exchanged between the carrier and PBX; maybe you can filter for the IP address of the trunk (203.176.185.10) and check everything from the INVITE message on.

I agree this whole idea of keeping customers out of the system is counter productive. Unfortunately, it still seems that the super password is as secret like who killed Kennedy. I would assume that you have logging for the PSTN gateway still turned on. In contrast to the PBX, it does not automatically delete outdated files and just keeps on writing. Usually the Linux command du can help you locate the problem. If you cannot delete it, just ask the snom support to log in to the system and delete it for you. If enough people have this request, maybe they get the point and give users access to the system.

There are two possibilities here: First, if the PBX does not have to send anything, it sends comfort noise. This comfort noise can be relatively loud as we recently found out, bug not the "thundering" kind of white noise you get with SRTP (supposed to be "comfort"). Workaround: Make sure that your external voice system sends RTP all the time or ask for a version from snom ONE with a fix (we have one available). The second possibility is that there is a SRTP problem; old firmware versions had that problem, but if you have something younger than two years the problem should not exist any more on snom phones.

Hmm, there is something on the old wiki about this: http://kiwi.pbxnsip.com/index.php/Installing_the_IP-PBX_Appliance#Password_Recovery_for_Web_Login. This is about resetting the web interface password; but you still need to be able to login via SSH for that.

We tried a couple of things, for example heartbeat with redundant NIC cards. At the end of the day, the easiest thing is to set up a virtual machine and use the VM tools to make sure that the device fails over. We have seen failover times in the 1 seconds area, and even calls in the ACD stay up. IMHO that is a great solution, and the virtualization comes with other benefits that make this really the best solution for failover IMHO.

As for thetwork configuration I would not use anything from the PBX web interface, just SSH into the box and do it the Linux way. As for audio out, as far as I remember you just need to send the RTP to a specific port on a specific IP address... Hmm dont remember by heart what it was, something like 1.1.1.1. Check the config for eth2, and maybe you find the process with ps auxwww and check what port is being used for pagmoh.

The log does not produce anything suspicious... G729 is always suspicious because of the way the codec must be licensed (per call), maybe you just have too many calls and then the PBX drops calls more or less randomly.

Are you using the format 1.2.3.4:123 (ip:port)? Otherwise it might not be clear what port to use for the specific service.

The only thing I can think about is that you have too many 3rd party registrations, only so-and-so are active and the others are being rejected.

Well if you are using the default, the call should not be counted as missed call. The PBX does not provision this value.

Well alternatively you can register the same extension in different locations. E.g. if you have two persons, that list them only on the ACD and register three phones for each one. Or those guys just use hot desking to log in to the ACD extension so they receive the call where they are.

Ja, diese Version ist ziemlich "zickig" wenn die Ports nicht verfügbar sind. Entweder pbx.xml editieren oder mit --http-port 1234 --https-port 12345 starten. --help sollte die möglichen Optionen ausgeben.

The snom ONE plus uses Sangoma with Netborder Express. That seems to be working well.

That looks perfect to me... The phone should not count this call as a missed call. Phone bug?

Are we talking about the time until the mailbox picks up? Or a call redirection after timeout?

Oh, see I got it completely wrong... Lets see if the forum admin can fix it.

Sorry, I don't get it. What should the PBX do? Perform a PTR lookup and then again a forward lookup of the DNS address? How would the mail server know about these steps? Is this a problem in the DNS config? The PBX has no control over the DNS server, it is just a DNS client (sorry if these questions seem to be stupid). If you cant to control what the PBX sends in the EHLO message, there is a global setting "email_domain" (check your pbx.xml file). Maybe you want to change it to whatever the DNS name of the PBX is.

How long is this? There is a upload limit of a megabyte or so; but the templates should not be so long... You can check in the xml directory what the PBX has stored internally.

If you are in the LAN, just put the IP address of the PBX into the option 66 (e.g. "192.168.1.2"). That should be okay. The first file will be TFTP, but then all other files will be HTTP or HTTPS.

Consider upgrading to version 4...

Just send a quick email to sales or a private message to me with the actication code and we'll do it "manually". Sometimes there is a problem with firewall, certificates and who-knows and then it is easier to just activate it manually.

I think the hunt group is just not the right way to do this. The ACD has a lot more possibilities to keep callers lined up nicely and you can record some prompts informing them and keeping them lined up. Then you have all the time to process them one by one. In case there is no line, the caller would still get the ringback tone immediately.

Right now, the park orbit remembers which extension (= neck to grab) parked the call. If we would have to send the call back to the group, the call might end up with someone else, or, even worse, after nobody wanted to pick up, in a redirected number, maybe even outside. I would just not send the call to a park orbit. Maybe just send them to a ACD or to a mailbox.