Vodia PBX

No, the PBX is not using .net (at all). Maybe you are a CRLF victim or something went wrong with the download. I downloaded http://www.pbxnsip.com/snomone/beta/win32/pbxctrl-2011-4.2.0.3979.exe and I get this: PBX>dir ... 01/24/2011 02:32 PM 9,672,704 pbxctrl-2011-4.2.0.3979.exe PBX>.\pbxctrl-2011-4.2.0.3979.exe --dir . --no-daemon --log 9 --no-check-ports Then the PBX starts up. I also have a couple of ports blocked (5060 for my soft phone), so the --no-check-ports was neccessary on my system. OF course for a real server operation, I would have to make sure that noone else takes the SIP port. Also check if you have the same size, if the size is different there must be a problem with the download.

Too many people complained that the custom files could not be found, so we took it out... Anyway, you can easily put it back in by adding the line snom_821_custom.xml in the web interface (web page control/templates): <?xml version="1.0" encoding="utf-8"?> <setting-files> <file url="{http-url}/snom_3xx_fw.xml?model=snom821" /> <file url="{https-url}/snom_820_phone.xml?model=snom821" /> <file url="{https-url}/snom_820_fkeys.xml?model=snom821" /> <file url="{https-url}/snom_web_lang.xml?model=snom821" /> <file url="{https-url}/snom_gui_lang.xml?model=snom821" /> <file url="{https-url}/snom_821_custom.xml" /> </setting-files>

I would cd into the PBX directory and try to start it manually with "--dir . --no-daemon --log 9". Then watch the output.

Looks like port 389 (LDAP) is also occupied by another service. You can edit that port also in the pbx.xml file..

You need a shell (a "terminal"); I think you can find more information here: http://macdevcenter.com/pub/a/mac/2001/12/14/terminal_one.html. But you don't have to read the whole book, all you need is the "cd" command (change directory). You can use "ls" to see what is in that directory, just to make sure that you are in the right place.

Is xx.xx.xx.xx the public IP address of the device? I see the private address is 192.168.1.13. The PBX should put the private IP address here I guess? What is the routing table of the system looking like (route print)?

Oh it is generated the first time the system starts up... Obviously you di not get to that point yet! You can fix it with this: cd into the directory where you installed the PBX, then start the PBX process manually with this: ./pbxctrl-mac --http-port 8080 --https-port 8081 --no-daemon This will also print the console output, in case there is other trouble you will be able to see it.

Take a look at the pbx.xml file and set the ports that you like.

M3 will also work (the configuration files are available in the pnp.xml, you can check yourself); however there are many features missing like TLS and SRTP and the m9 is the newer design, so I would go for the m9.

Consider moving straight ahead to snom m9...

Thats a well-known problem. The "snom ONE" way to address the problem is to represent the numbers in the "readable" format. That means, for people in the USA domestic numbers have ten digits and for people in the ROW (rest of world) international numbers start with "00", national numbers with "0" and local numbers start with "1"-"9". The PBX prefixes we know from the 70s are out; today people are using cell phones and are starting to replicate their address books also into the desktop phones, where PBX prefixes would mess things badly up.

Habe ich bis jetzt noch nicht selbst gesehen. Die Karten scheinen ja recht günstig zu sein. snom ONE unterstützt aber nur SIP, so dass vermutlich noch eine SIP-Software die von HFC auf SIP umsetzt (SaphirVOIP scheint sowas zu machen). Wäre aber sicher einen Versuch wert!

First of all, service flags are an independent concept regardless of auto attendant, hunt groups or agent groups. The point is that multiple accounts might be affected by an event ("office closes"), so it makes sense to define this event once and then reference it in multiple accounts. Lets assume you are talking about the auto attendant and how to use the service flag. So right, if there is no flag defined, then we just go ahead and always do what the AA does. If there is one flag used, the AA will transfer the call to the provided destination when the service flag is "engaged" (what ever that means, typically "night mode"). What is a little bit confusing is the possibility to specify multiple service flags (seperated by spaces). Then the PBX will start with the first flag, if that fires it will redirect the call to the first redirection; then with the second and if that fires with the second redirection, and so on. Here are some old links that also might help to understand the idea behind the service flags: http://kiwi.pbxnsip.com/index.php/Service_Flag http://kiwi.pbxnsip.com/index.php/Auto_Attendant#Night_Service

The goal of the PDF manual was to come up (quickly) with something that we can print out and put into the snom ONE boxes. The good old wiki (now still alive under the name kiwi) was probably the best way to deal with the dynamically changing contents; PDF are always outdated by the time they are finished or even printed. We are currently putting another Wiki up, and that's going to be the place where we can edit with multiple authors at the same time whenever there is something that should be documented. Right now the workaround is this forum and the-search-engine-of-your-choice. As for the trunks, people have to understand that the classical CDR is the trunk CDR which tells you how long the PBX was connected to an "outside" number. Extension CDR are the classical "missed calls, placed calls and taken calls". The account CDR are the inner view of all the waiting, transfers that a call went through (one account CDR entry for each segment); they are most interesting for ACD reporting. Maybe we should rename the extension CDR and account CDR to something else, so that Joe Doe does not jump on it and believes it corresponds to his old CDR from the PBX in the 70s. We are in the process of coming up with a "service pack" after the first release of snom ONE that fixes a couple of bux that have been found in the meantime. It should have been ready this week, but obviously it will take a few days more. We are not picky spinning versions as we go, as the real-life feedback is always better than pure lab tests; once the "service pack" is out IMHO it makes sense to backup and upgrade to that version.

You should also remove these settings from the templates in the web interface, so that a re-provisioning of the phone does not ste LDAP again.

Is it an option just to call *98xxx and delete each recording with the "*"?

No the are "TLV" (Tag, length, value). It is also a very simple format. We did this for the CDR because we had so many cases where the parsing of the CDR entries took so long during the bootup, and TLV is much faster to parse. The format is like this: First comes the length of the name (2 bytes), then the name, then the length of the content (4 bytes) and then the content. Then repeat for all ame/value pairs in the record.

Well, if someone pulls the plug on the phone and the other side does not disconnect (or there is no other side), that call will stay up for one more hour... Not good. Is this one-way video and there is no audio going on? In two way video it should actually not hangup. In one-way audio (and fax) it will hang up; that#s debatable and maybe we need to change this.

Okay lets see if that was the problem then we can come up with a proper solution for all phones.

Well 100 Trying is typically not the last result you will see coming from the gateway. Search for other messages with the same "Call-ID". If you see a code between 180 and 199 then you will hear ringback (which is good), if you see a 200 code that means the call got connected (not good if is comes right after the INVITE request was sent out). VoIP providers are usually better as they dont have to run the calls through analog lines, which makes it a lot easier to find out if the call got connected. That is actually a killer reason IMHO for SIP trunking. You know when the call actually got connected...

Try http://kiwi.pbxnsip.com/index.php/Office_with_private_and_public_IP_addresses, we need to move this one also to the new Wiki.

I am pretty sure that the problem has to do with your network setup, most probably with the router. If you have the chance to run the PBX behind another router, you should try this. Otherwise, you have to "prove" that the problem is with the network, and Wireshark is a good tool to do that.

Just set it to something like 3600; this is a workaround if you are doing video-only calls.

And check if the address was blacklisted.

The LDAP stuff looks suspicious to me... It could be that the phone when it goes offhook gets the address book from the PBX, which contains something that is beind dialled and then it would pick this one. There are many settings for LDAP on the phone, see http://wiki.snom.com/Category:Setting:Directory:LDAP. I am not hte big LDAP expert, but it might be worth turning some LDAP settings off locally on the phone and see if that is the problem.