Vodia PBX

We actually did start with a little script language that could take care about it. For example, something like if (flag1) return "2121234567"; else if (flag2) return "123"; else return ""; However franky we got deeper and deeper into this interesting topic to the degree why don't we script the whole PBX. At that point we decided to keep on with incremental changes and put this topic on hold...

One of the points of the SoHo is that we are using a standard platform, so that all features are available to the installer. In the first versions of the SoHo, we attempted to privide all features through the web interface. But we had to give up. There are so many features today (VPN, VLAN, 802.1X, 2nd IP, 3rd IP, DHCP server(s), web servers, SNMP, you name it), and it is impossible to have them all through the web interfaces. The debian documentation is excellent and there is no point to copy it. Instead, it is better to offer the installer a standard login through SSH, and tten everything else is just a debian computer. The only thing specific is actually the PBX, and thats what we need to program & document. By keeping the focus on this component we can make sure that we have a collection of outstanding components instead of one so-so attempt to solve all those problems.

Nein, jede Nebenstelle hat seine eigenen Settings für die Weiterleitung. Man kann aber z.B. angeben zu welcher Zeit eine Nebenstelle auf dem Handy anrufen darf. Das ist wichtig damit die Mitarbeiter nicht nachts aus dem Schlaf gerüttelt werden. Das System kann mehrere Ein/Aus-Schalter haben, darüber kann man auch komplexe Szenarien abbilden.

My input here is that you might have only one physical interface, but that does not imply that you can have multiple interfaces in Linux. You could set up a 2nd IP address and use that one for the DMZ (everything must be done from SSH, sorry no web interface for that kind of stuff). I guess you have seen http://wiki.snomone.com/index.php?title=Server_Behind_NAT, I favour the IP routing lits to get this job done. All in all, your customer might have saved a few bucks on the hardware and software; however having such a complicated setup does cost money unless you work for free. A server needs a routable address. The end of IPv4 is near, welcome IPv6. Hopefully then we dont have to talk about routable IP addresses any more.

Es gibt wohl ein Problem zwischen NBE und der PBX; wenn man dort die RTP-Daten aufzeichnet, kommt in der Tat nur Schrott an. Wir sind im Gespräch mit Sangoma um herauszubekommen, was da los ist.

cdrt stands for cdr with trunks, cdre for cdr with extensions, cdri for cdr from the internal objects (e.g. ACD). If you make a call with a registered handset, you should be able to see that in the cdre folder.

If you have two interfaces then you must (1) make sure that the traffic towards the public internet is using the designated interface (thats a topic for the routing table, which can be influenced with the metric or otherwise explicitly with the route command) and (2) make sure that the PBX replaces the IP address on the interface that points to the internet with the IP address that the router will insert later. This can be done with "IP Routing List" of the PBX, for example "192.168.0.0/255.255.0.0/192.168.1.2 0.0.0.0/0.0.0.0/123.124.125.126" (note the space between the route entries) if 192.168.1.2 is the private IP address of the interface that points into the LAN and 123.124.125.126 is the public IP address that is used on the router. I know this is all very complicated, it would have been a better world if SIP have been designed with NAT problems in mind. STUN does also not solve the problem, because this is the server, not the client :-(

My only explanation is that the phone responds with a 6xx code, which means "stop all call legs" (the PBX respects that). Lets see if someone from the phone support can chime in.

Thats the default. Does the PBX fork to the cell phone also when the phone is not on DND? Maybe what you want is that the PBX *redirects* the call to the cell phone when you push a button on the phone?

Did you see http://wiki.snomone.com/index.php?title=Server_Behind_NAT? I think that pages describes pretty much your situation. Once we all have IPv6, life will be a lot easier

For the PBX, DND is a extension feature. The extension (including the cell phone) is on do-not-disturb. The user simply does not want to be disturbed... However, if you have the device on DND, then you will probably get what you want. By default, the PBX provisions the DND key of the phone to be a PBX feature; but you and take that out in the provisioning template and then the DND button will be local to the device, and then then the user pushes the DND button, the cell phone will still ring.

Did the phones perform a software upgrade? Maybe that is the reason why the phones behave differently.

Wenn das ein leichtes Rauschen ist (Comfort Noise) ist das ein Schritt in die richtige Richtung. Irgendwann sollte dann aber der Rufton kommen. Ja. Dazu kommt dass das Gateway das auch unterstützen muss.

Das ist ein "Klassiker" in SIP, da die Standards da einfach nicht klar sind. Selbst zwischen snom und snom gibt es immer noch Auslegungsprobleme (snom muss ja nicht nur zu sich selbst kompatibel sein). Wir haben bei snom ONE das Thema bereits wieder auf dem Tisch und werden das mit der neuesten Telefon-Software nachvollziehen.

It all depends on the random number generator. But even if you have the same number, it should be no problem between different systems. As far as I understood the system, the EPID is a identifier inside ONE system and for that the randomness should be super sufficient. The content in the working directory is all XML. If should be possible to make a quick check if there is any overlap.

Yes sorry used the wrong, incomplete name. Just cat the files there and check if you see anything familiar.

Not the biggest expert here, but you can set the metrics of the interface to make sure that the public IP is used when sending traffic out to the Internet. Use route -print to show the route.

The thing about blacklisting is that the server does not answer to requests from the blacklisted address. Otherwise it would be very easy to DoS the system. After one hour (thats the default) the address gets un-blacklisted again and you can try again. Or just try from another IP address. This is all stuff from the PBX. You can still access the system through other methods like RDP or SSH and take alook at the working directory of the PBX, especially the access folder.

If the problem is between the phone and the PBX, I would first try something local, e.g. calling the auto attendant. Then it is easier to nail the problem. From the above, the phone is able to send and receive SIP packets to and from the PBX, which is pretty good. However it tells the phone to send the media to an unroutable (private) IP address, which is not so good. Your PBX has a NAT problem :-( maybe it is just the routing table on the PBX that needs to be fixed, if you have already a public IP address.

If you download through the web interface, the file must end with .xml, for example http://downloads.snom.net/snomONE/version2011-4.5.0.1050.xml (view it in a browser to see what this actually does). The other files are pure executables that you can load with wget into the working directory.

Yes the DNS seems to be okay. It seems that the certificates for provisioning.snom.com are expired. You can reset the clock to 2011 or just update the software through the web interface. Or you just pull down the latest image with wget, see the link on http://wiki.snomone.com/index.php?title=Coma_Berenicids. If you rename the executable to "pbxctrl" after the download, the next updates will be possible through teh web interface. Sorry for the inconvenience, but the way the Debian package update was done, was (obviously) not maintanable for snom. That's why we changed to a unified update procedure OS-independently from the web interface of the PBX.

Well you are one of those who really need handover. Thats possible in DECT, however a different price tag on it. Or maybe you can try a repeater, this is another way to stretch the range if you dont have too many calls going on.

Check if you have been blacklisted. You can do that by looking at the filesystem, access folder.

What is in /etc/resolv.conf? Some SheevaPlug versions are set up to use 127.0.0.1 as the default (dnsmasq), IMHO that is not neccessary.

Problem mit G.729A? Was ist das denn für eine Lizenz (G.729A ist kein freier Codec)? Der Klassiker bei 4.5-Upgrades ist dass die Trunk-Settings (Header) nochmal gespeichert werden müssen. Vielleicht liegt es daran dass 403 vom Provider zurückgesendet wird.