Vodia PBX

In 5.2.3 they are serial for each server. Previously it was serial for the whole server, no matter what the destination was. The PBX tries to keep the connection connected, so that the TCP connection overhead is reduced, which is important especially for TLS.

Try 5.2.3; we are pretty confident that the problem with finding the beginning of the day has been resolved once and hopefully forever.

If the email server does not support PLAIN authentication (e.g. LOGIN) then there was a problem. If that is the case, let us know what OS you have and we'll spin you a 5.2.3a image.

Well the SIP messages seem to be unrelated, but could it be that you don't have the name "localhost" in the domain alias list? You can also filter by IP address when setting up the log levels, so that yo use only the SIP packets from the gateway.

4.5 can also send CDR summaries at midnight. If I remember correctly it is a domain setting.

Do you mean a ACG automatic gain control? Or just a static setting for the volume?

ACK. We have a problem with the CentOS32 machine. We'll hopefully get it up again soon.

Update: There was a bug in the email client in the Linux versions. If you have used the build from yesterday, please update one more time. It should show the build date of today (6/25/2014), then it should be okay.

You might have seen it already on the mailing list, 5.2.3 has been released. The release notes are to be found on http://www.vodia.com/documentation/releasenotes523 as usual. The link for the update is http://www.vodia.com/downloads/pbx/version-5.2.3.xml also as usual. The 5.2.3 actually has an improved software update mechanism that shows you the progress now. If you upgrade, pay attention to the email settings. If you have selected that the email settings are in the domain, the system does not automatically fall back to the system settings if the domain settings are incomplete.

The question is how many calls you will need at the same time. Usually not everybody is talking at the same time unless you run a call-center. You can use the drop down load on the PBX to check which trunk providers we have worked with in the past.

Well, for POST you cannot use http_get (sorry). But if you take a look e.g. at http://stackoverflow.com/questions/5647461/how-do-i-send-a-post-request-with-php you see some sample code on how to POST something with an attachment.

That code comes from ancient times. Today you can have PHP do the HTTP client stuff with built-in functions that are much faster, for example http_get.

Your first best friend here is wireshark to see if the HTTP request makes it to your server. Maybe there is an issue with a firewall or something else in the routing area. Then you need to check your access log and error log in your web server. These files are usually in the /var/log/httpd area. Maybe you will find an error. It can also be that you need to include the .php extension or even enable PHP at all. But this should definitively take you to the next level.

It is a complex topic. First of all, it is good if you keep track of the registration e.g. by sending an email out when the registration status changes. I guess that is what you did to get an overview on the situation. What you can do it try to narrow the problem down. If you are using TCP instead of TLS and the connection still drops occasionally, then you probably have a problem with your routing equipment that has only so-and-so many TCP connections and you are simply running out of it sometimes. For example, when the client is using lots of email and HTTP TCP connections, the router might drop the SIP connection. If the problem is related to a specific site, I would say to 90 % it is the router. Also, you can specify the outbound proxy for every site. For example, if you have one client with a trouble router, you can specify as outbound proxy something with UDP, while other sites are still using TCP or TLS. The last thing that comes to my mind is that a lot of equipment had to be updated recently because of the heartbleed problem. That might have have caused ripple effects with unstable TLS connections. Depending on what phone type you are using, the unfortunate OpenSSL version might be in use, which may be part of the problem. In that case, you should update the phones.

Ist mir nicht bekannt dass das geht.

Did you open the right port? In newer installations we don't use the standard LDAP port anymore, this avoids all sorts of scanners trying some NTLM bugs out on the PBX when you run it on public IP. If you automatically provision the phones, they should also get that non-standard port. But if you have to punch holes into the firewall, you must also open the non-standard port. You can see what port is being opened in the ports section in admin mode of the PBX.

At least one problem is that the deviceId is sometimes in the "user@domain" form, and in other cases just in the form "user". What CSTA tool are you using again? In theory it would be possible that the PBX looks up the domain by itself because it has the CSTA session context anyway. But before we start looking into what this would mean it would be good to know if we can instead fix it on the CSTA client side.

Im Gateway-Modus auf jeden Fall. Die andere Seite bekommt dann nichts davon mit, dass auf der PBX mehrere Leitungen verwendet werden. Im Registrierungs-Modus wird es schon schwieriger, ist aber immer noch möglich. Dann muss man eine Leitung bidirektional im Registrierungs-Modus aufsetzen, un die anderen Leitungen im Gateway-Modus, mit den gleichen Benutzernamen und Passwort. Das sollten in den meisten Fällen auch noch klappen, vor allem wenn UDP verwendet wird.

Wo denn? Im Ruhemodus, oder im Gespräch?

Which part? LDAP access? ActiveSync?

Nicht direkt. Wir haben in 5.2.2c eingebaut dass jede Agenten-Queue/Schlange ihre eigene Identität verwenden kann. Wenn man sich in eine der Schlangen einwählt, wird dann automatisch die Identität der Schlange verwendet. Daneben kann man auch den Trick machen, mehrere ausgehende Leitungen anzulegen, die dann jeweils ihre eigene Identität haben können. Dann kann man über den Dial Plan/Rufschema steuern auf welcher Leitung der Anruf dann landen soll.

Check the messages directory. In that XML stuff there you should be able to locate the rec text, e.g. grep '>rec<' *.xml.

Does the call even leave the 4.5.1 PBX? Otherwise, you might need to think about inter-office trunks. This way, you can route calls through the PBX without involving extensions.

Ad-hoc recordings are essentially mailbox messages. That means if you want to do this properly, you should look into the messages folder and filter those out that have the type "rec". The star codes are audible. The PBX cannot hold the * and the 9 back and hope for a 3 or 4. If you are using snom phones, the record button (on the old 3xx series) is downloads XML from the PBX that toggles the record on an off. The button is not there any more with the 7xx series any more, but there is a Rec soft key available that might serve your purpose.