Vodia PBX

We are still struggling with the Mac OS. But the snom ONE mini (ARM) has been done and we even went through the process of upgrading a SoHo to V5.

Thanks Pablo for giving us access. So you also need a new library version: root@pbx:/usr/local/snomONE # wget http://www.snomone.com/downloads/snomONE/mini/libstdc++.so.6.0.13 root@pbx:/usr/local/snomONE # mv libstdc++.so.6 /usr/lib root@pbx:/usr/local/snomONE # rm /usr/lib/libstdc++.so.6 root@pbx:/usr/local/snomONE # ln -s libstdc++.so.6.0.13 /usr/lib/libstdc++.so.6 After that it should *really* work.

For now, I would stick to command line. If you check out /etc/init.d/snomone is that pointing to the right executable? Some systems used the name "snomONE-ctrl" or so. Make sure that the name in the init.d directory is pbxctrl and nothing else. What is the operating system? cat /etc/debian_version should show us what version is on that system. /usr/local/snomONE/pbxctrl --version must print 5.0.2; if there is a error we still have a problem with the Linux version that is installed on that system. The image was compile on debian 5.0.3. Again the easiest would be if you port forward the SSH port (22) and give us a remote login, then we can probably figure this out in minutes.

I would invest a little bit more time into the dial plan. E.g. same-time might not like the "localhost" domain name...

Ja, es müssen Ports weitergeleitet wertden. Mit Port-Weiterleitungen ist es aber leider nicht getan. VoIP verwendet UDP, deswegen muss die PBX wissen welche IP Addressen "beworben" werden müssen. Daher das komplizierte Setup mit der Routing-Tabelle-Emulation in der Beschreibung oben. Am allereinfachsten ist es, der PBX einfach auch eine öffentliche IP-Adresse zu spendieren: Letztlich muss man sagen, die PBX ist ein Server der von den Clients Pakete empfangen können muss, und zwar nach dem IP-Protokoll mit Absender und Empfänger. Wenn das nicht gewährleistet ist, gibt es halt One-Way-Audio.

Vermutlich eine Problem mit NAT. Leider kein einfaches Problem... Dazu gibt es einen "Klassiker": http://wiki.snomone.com/index.php?title=Server_Behind_NAT Version 4.2 ist schon ziemlich alt (wo ist die denn noch gelistet?!). Für neuere Installationen würde ich auf jeden Fall 5.0 verwenden.

You should see where the new RTP stream comes from, and that could lead to the a-ha effect!

We have made a build on the SoHo distribution at http://www.snomone.com/downloads/snomONE/mini/pbxctrl-soho-5.0.2. Please use this one for the SoHo.

Call back probably depends on the number that is presented to the user. For example if the same time user name is "123" the PBX will have problems figuring out that this is a number that is actually outside of the PBX. Usually the best way to deal with this is to use "long" (more than 6 digits) numbers that look like PSTN numbers to the PBX. This will trigger the standard dial plan routing rules, and then all you need to do is add a dial plan entry that routes the call on the trunk.

The media-aware pass through is after the one call leg hung up and it actually is on the other leg. Because there is probably only one leg left, it is very understandable that there is no more RTP pass-through possible! Plug that message comes a lot later than the SSRC change. I would definitively assume that the SSRC change it the problem here. The SSRC should not change unless there is a SIP-style music on hold going on or a transfer without signalling. If the SSRC in the middle of the call "out of the blue", there is something strange going on.

We addressed that topic in a separate Wiki page http://wiki.snomone.com/index.php?title=From_Header_in_Groups.

Well according to SIP, RTP may come from anywhere, anytime! For example, this is the way that the SIP standard proposes the implementation of music on hold, and the MoH server may be sitting anywhere in the Internet... The RFC authors must have lived in a world when the Internet was friendly and nobody would send anything bad to a PBX operating on a public IP! 100 ms does not necessarily mean that the PBX gives up on the connection; it just means it opens it's arms to new RTP stream that would arrive on the RTP port. That does not have to be a call drop. For example, some phone stop RTP when the mute button is active, or they slow it down to a packet per second or so. Some other devices don't sent traffic during silence (silence suppression) to save bandwidth, which is also okay. Unfortunately there is no way on the PBX side that can safely tell the PBX if the call dropped or it is a temporary thing.

If you "borrow" us the account information (in a private message) we can set it up on our system and then let you know what the best settings are. This avoids a lot of "ping pong" posts on the forum or in support.

We were actually so far under the impression that there was no difference between SoHo and mini... But because we did a fresh install on the tool chain, it seems that that broke the backward compatibility on the SoHo. Looks like we have to dig the SoHo out again and make another image there.

The PBX has two ways to deal with media. The first one is that it received the media on the RTP port, decides the SRTP, decodes the RTP packets it to16-bit samples, runs it through a jitter buffer and so on just to do the same thing on the other side of the B2BUA in reverse order. This one is called "media-aware pass-through mode" In many situations all that work is unnecessary. Then the PBX only needs to decode the SRTP on one side and encode it with SRTP on the other side, without looking at the content of the packet. This obviously makes the processing a lot faster, and it also deals better with network jitter. This mode is called "RTP pass-through mode". The goal of the codec negotiation is the RTP pass through mode, but for example when an operator is barging into a call or the two sides cannot or don't want to speak the same codec, there is no other choice but to use the media-aware mode.

Good point with the logging. We'll add that in the next release. Right now you will see that only with PCAP/Wireshark. The change happens only of the other source did not send anything for at least 100 ms. This is to avoid that someone "steals" the stream while staying still reasonably within the RFC bounds, and it does usually mean that the original sender did stop sending traffic. If you are using SRTP, the context has also be re-initialized which raises the question of the value of the SRTP rollover counter. When the SSRC value is changed, the PBX must assume that it has been reset to 0. If the problem occurs only after longer conversation it might point at problems in that area (when the ROC is more than 0).

Ja der Versuch das Wiki auf Deutsch (Italiänisch, Dänisch, Russisch, Griechisch, Chinesisch, Japanisch, ... ) zu übersetzen ist erst mal aus Eis gelegt... Bei einem Kaltstart steht sicher die Frage nach den Vorkenntnissen im Raum. Wer sich bereits mit SIP, Trunks & CO auskennt wird schneller vorankommen als jemand, der mit VoIP eher Skype verbindet. Kunden die von snom ONE noch keine Ahnung haben, sollten auf jeden Fall sich das System von einem Reseller installieren lassen; das spart allen Beteiligten Zeit, Nerven und Geld. Reseller, die sich mit dem Thema befassen sollten auf jeden Fall erst mal Testsysteme aufbauen wo nichts weiter passiert wenn man was kaputt konfiguriert wird. Auch wenn es auf English ist, gibt es doch gute Trainingsunterlagen zum Thema snom ONE unter http://www.snom.com/en/partners/snom-university/classroom-training/ (ST400). Je nach Lernmethode ist es schneller sich die Videos anzusehen als sich durch das Wiki zu klicken.

Oh, this is probably because the snom ONE Soho was using its own Linux distribution. We changed that to a standard Debian distribution on the mini. root@snomonemini:~$ ls -al /usr/lib/libstdc++.so.6.0.13 -rw-r--r-- 1 root root 874176 Nov 15 2010 /usr/lib/libstdc++.so.6.0.13 I searched a little bit in the Internet; seems that problem is a common problem. If you have a mini, maybe you can just copy the lib files over to the Soho. If it all does not help it seems we have to compile the executable again on the old Soho platform.

I think the problem should be solved in the latest versions. It is not always easy to stick with the RFC, especially if they are an invitation for denial of service. IMHO stability of the system has a higher priority than RFC compliance.

The version-5.0.2.xml did not contain the link yet... Please try again, the file should not have the link. From the shell, you can just use "wget http://snomone.com/downloads/snomONE/mini/pbxctrl-mini-5.0.2".

Indeed, it looks okay. If you cd into the /usr/local/snomONE directory, try calling ./pbxctrl --version to see what version you are running. While you are there, you can also just wget the executable and skip the upgrade from the HTTP interface.

It could be that the SoHo is using a different name than "pbxctrl" for the executable. If you can log in on SSH, you can check the file in /etc/init.d/snomone what name the executable has and change it accordingly to "pbxctrl". We included the bi_ced.wav file in the upgrade to make sure that everyone has the file in the audio_moh directory. The log/error is misleading (needs to be taken out from the code); upgrades may include non-executable files. For example, it should be possible to install languages by using the software update mechanism.

Agreed. The snom ONE mini is marketed from the snom office in Berlin (Germany) and not by the snom ONE team (Vodia). Maybe you can check with Berlin if they would give you complimentary upgrades to yellow or blue.

Well, the problem with answering OPTION is that all kinds of scanner use this method to identify their next target. Anyway, we have already a fix. If you want to help verify that the problem is fixed, let us know what OS you are running and we'll provide you with a new build (available for 4.5 and for 5.0).

The backup file is probably too big. Usually this is because there are a lot of WAV files in the package. There is a simple workaround: Go to the file system and just ZIP the working directory of the PBX. Then you can restore it later easily.