Vodia PBX

The automatic blocking of IP addresses is not related to the open ports. It is just a logic so that the PBX temporarily blocks traffic from certain sources which failed to authenticate. When sendng traffic out from the PBX to an address, that address is automatically considered valid. So this takes care about the trunk. When doing port forwarding keep in mind this works for TCP, but it does not work for UDP. Keep in mind that the PBX will choose the RTP ports from a port range, and it needs to advertize the port and IP address to the outside phone.

If the TFTP port is available for the phone, you can just put the IP address of the PBX into the "setting server" setting on the phone. Then everything else will be automatic. Otherwise you have to put a HTTP url into the setting server, e.g. http://pbx_address/prov/snom360.htm.

There were a couple of Wifi phones available, for example from Hitachi. I did not have the impression they were a huge success. Of course not. I saw that the latest Android has a new dialer that make SIP usable to norma people. Did any Wifi phone ever perform roaming? Really open question... Well, but here have the feeling that the latest smart phones are far better than anything I saw in the pure Wifi phone space. Thats very true. I likes the old Nokia phones E-series with build-in WiFi and SIP. But I think they are probably not available any more and the SIP client could also have been improved. I see the point. Maybe those leather covers can come to the rescue... At the end of the day, it is only a question about volume. Customers expect a quality similar to the cell phones they use every day, and similar prices. It might be very challenging to achieve that.

Das muss beim Trunk ("Leitung") geregelt werden. In dem etwas unscheinbaren Setting "Ziel Konto" kann man eine Liste von Extended Regular Expressions eintragen, die die Zielnummer herausfischen. Die Nummer muss dann als Extension angelegt sein. Damit sollte man in der Lage sein, praktisch alle möglichen Routing-Szenaien abzubilden. Z.B. wenn man "!02281234([0-9]*)!50\1!" verwendet, würde 02281234 bei der Nummer vorne abgeschnitten und mit einer 50 ersetzt. Also z.B. 0228123456 -> 5056.

Auf Englisch heissen die Dinger Hunt Groups ("Rufgruppen"). Wenn da einer anruft, klingeln nach und nach die Telefone, die dort eingetragen werden.

You probably have a problem with the Caller-ID presentation. Try setting the mode from RFC3325 to "No indication" on the trunk.

You should add a telephone number to those extensions, something with 10 digits if you are in North America. Those numbers dont have to be routable from the PSTN; they just tell the PBX that the account is something considered "global". If the two PBX are able to send each other packets on TCP and UDP, then you can just create a gateway trunk on each of the boxes with the outbound proxy set to the other box. From the PBX perspective, the other PBX is like another service provider that you need to add in the dial plan when dialling the telephone number(s) that you have defined for PBX. If hte two PBX are behind NAT, things get a lot more tricky. Essentially in that case you have to set a third PBX on a public and use the SBC functionality. Again, from the two PBX perspective, that third PBX would serve like a mini-ITSP where you can send your calls to. But all-in-all I believe today it is easier to make sure that the PBX can send each other packets on IP level, e.g. using a VPN or putting the PBX on a public IP.

Take a look at this: http://wiki.snomone....rver_Behind_NAT. The point is that you need routable addresses for the PBX, for TCP and also for UDP traffic. The addresses can be IPv4 public IP addresses, IPv6 addresses, VPN addresses, whatever. As long as the snom 360 can reach out to the PBX you are in good shape. The snom ONE mini has only one physical Ethernet port. However that does not stop you from adding more interfaces. In Linux, you can add more IP addresses and adjust the routing table accordingly. For that you need to SSH into the box; the web interface does not give you the convenience for that. The good news is that the box runs a standard debian distribution, and you can look the documentation up on debian.org. If you want a simple solution, you can just put the whole box on public IP. Make sure that you dont see any warning signs in the accounts web page (trivial passwords), so that no friendly scanner will latch onto accounts.

I would consider Android phones with version 2.3 or higher being candidates (unless the SIP functionality was disabled). Practically all smart phones can run SIP clients today. Dedicated WLAN phones dont make sense anymore IMHO. Just buy a cheap smart phone and don't put a SIM card inside.

Oh yea. We were also a little "surprised" the move did take so long... hopefully we can enjoy a better performance now. Just send me a private message in this forum.

You can actually also check the generated folder in the PBX working directory for the configuration that the PBX has generated. There should be something with multicast in it.

Ouch. If you can send me a private message with the RDP information we can find someone who can take a quick look how big the damage is.

The screenshot looks okay. The phones are in the LAN I suppose? Maybe you have to run a PCAP trace to see weather there are multicast packets in the LAN when you do a paging. You can do that from the phone, then you don't have to install Wireshark on the PBX server.

If there is a paging group in the domain with a multicast address it should be all automatic.

The 4.5 version has this certiicate built-in. However in order to preserve backward compability with older versions and installed certificates, the PBX loads it only of all certificates have been removed before the upgrade. You can easily achieve this by renaming the certs directory in the PBX to something else, e.g. certs2 before the upgrade.

Oh I did not see that... That's a server in Italy, and it was used to do the software updates the Linux package way. As you can see, it is not easy to maintain this service and we have the problem that other operating systems like Windows or MacOS will not be able to use this service anyway. We introduced in 4.5 a feature that allows software updates initiated directly from the PBX web interface, using a standard web server for all platforms. Windows users also dont like to swap out executables for software updates! The next batch of SoHo will already use the 4.5 software update, so that we dont have this problem there anymore. For your SoHo, I believe we have to do the update "manually" by logging into the device and pulling the image down with wget. We are right now producing another batch of SoHo, and we will need to have the new build available for this next week. As soon as it is available, we'll publish the link to the image and how to load it on the SoHo device.

This page might help you: http://plugcomputer.org/plugwiki/index.php/QuickStart

Yes. Yes. The system has totally 512 MB; I would say 200 MB are still available for the PBX data. So if you start recording, you can record a few hours then the file system will be full and the box gets into trouble. The box has SSH access, you can read the file system trough that. The price and the operating cost. It has no moving parts and low power consumption. Compared to a PC server, you'll save a lot of money for power and you don't have to be afraid that the CPU fan dies over time, especially in enviroments where there is a lot of dust in the air. The device is running Debian on ARM, and you are free to install things that you like or need. For example, you could think about NFS or mounting external USB memory devices. But this is something that we will definitevely not support, if you do that you are on your own risk and support. I would not advertize this as a recording solution. If you want to have a recording solution, I would stick to standard PC with a lot more drive capacity.

Actually this feature would also be useful or even more useful in other scenarios where the PIN is required. For example, when the dial plan requires that the use enters the PIN or when someone calls from a cell phone into the system and the caller ID has to be authenticated with the PIN.

Oh you mean hang up? I think there is a timeout, but it could be like 5 minutes.

Ja, das mit der Boing war natürlich ein Witz. Es gibt immerhin ein Buch zu snom ONE (rund 550 Seiten) wo die Themen alle erklärt werden. ISBN 978-1-884186-46-2. Scheint aber nicht ganz einfach zu bekommen zu sein (bei Interesse mal beim snom Vertrieb nachhaken). Was ist denn ein Root Server? Ich denke aber dass das nicht notwendig ist. Man kann snom ONE auch auf einem ganz normalen PC installieren. Client oder Server spielt keine Rolle. Ich würde es einfach mal mit dem normalen Arbeitsplatz-PC versuchen, oder vielleicht in einer virtuellen Maschine die man nachher leicht wieder entsorgen kann. Wenn die PBX läuft, einfach mal im LAN ein Telefon mit Ethernet verbinden und einschalten und sehen was passiert. Mit etwas Glück bekommt das Telefon automatisch die Nebenstelle 40 zugewiesen. http://de.wiki.snomone.com/index.php?title=Requirements http://de.wiki.snomone.com/index.php?title=Quick_Installation http://en.wiki.snomone.com/index.php?title=Plug_and_Play (leider nur auf Englisch)

You can just edit the templates from the web interface, this is much better than just being able to changing a few places.

Most of the problems with service providers come from the different interpretation of the SIP headers. If you are on pre-4.5, try different settings for the Caller-ID presentation (e.g. RFC3325). Since 4.5, you have a lot more options, but you can try some of the JavaScript-defined templates that are available on the trunk page.

Ich würde mit http://de.wiki.snomone.com/index.php?title=Hauptseite beginnen (auf Deutsch!). Am einfachsten ist die Installation unter Windows, damit würde ich auf jeden Fall mal anfangen; die Konfiguration kann nachher auch auf andere Plattformen kopiert werden. Leider ist das Thema VoIP recht komplex und schlecht in so einer offenen Frage zu beantworten. Das ist etwas so wie "Ich habe mir gerade eine Boing 747 besorgt, kann mir jemand sagen wie man das Ding fliegt?"... Naja, jedenfalls kann bei VoIP keiner verletzt werden.

Keep in mind every frame causes spaning a new thread, which is a heavy operation for an embedded system. Normally a client that does would get blacklisted very quickly. I am not sure if we explicitly disabled that for the SheevaPlug build. Unfortunately, that is not correct. We verified that multiple times with the phone team, for each frame it did have to load the XML text again. You can imagine that the PBX team jaws literally dropped down.