Vodia PBX

This link might be interesting for you: http://kiwi.pbxnsip.com/index.php/Microsoft_Exchange. For example, Microsoft does not support UDP transport layer. You must use TCP.

Well for sure you can take a look at the webpages directory on the working directory of the PBX. There you can see all customization that have been done.

Interesting point... The text in the quotes is usually not suitable for routing purposes. Usually there are names, thus there is (currently) no way to use that field. However, it is actually not a big deal to add this (lets say with the flag d for display so that "td" would make it happen) and we'll add it to the next build.

1) Grundsätzlich gibt es zwei Möglichkeiten, eine Konferenz zu schalten: Auf dem Telefon oder auf der PBX. Wenn man die Taste auf dem Telefon drückt, wird die Konferenz auf dem Telefon geschaltet. Die PBX bekommt davon gar nichts mit. Wieviele Teilnehmer an der Konferenz teilnehmen können hängt vom Telefon ab. Es gibt einen Code, mit dem man alle Gespräche die von einer Nebenstelle gehalten werden in eine Konferenz schaltet: *53 (http://wiki.snomone.com/index.php?title=Star_Codes). Dann wird die Konferenz auf der PBX durchgeführt. Wenn man den Konferenz-Knopf auf dem Telefon zum Speed-Dial mit *53 umprogrammiert, kann man das Telefon dazu bringen dass Konferenzen grundsätzlich auf der PBX durchgeführt werden (ist aber Geschmacksache). 2) Dazu muss der Konferenzraum bei "Art" auf "Geplante Konferenzen" einstellen.

Even with a lot of bandwidth, you might experience problems e.g. when sending large emails out. It does take some time before a MB is sent out. The good news is that upstream audio is easier to fix than downstream audio. As you control the router on from the CPE to the Internet, you may also control which packets are being out first. Many routers today have QoS filters that you can program. For example, if the PBX is on a specific IP address in the office (and there is not other service running on that system that sends out traffic to the Internet), you could just give that IP address a higher QoS priority than the other devices. The ActionTek routers that come with FiOS from Verizon for example to my surprise have this feature. But there is also a lot of other router equipment available out there that has a QoS menu. If you like, give us the IP address and credentials for logging into the router (private message, along with the IP of the PBX) and we can take a look around. No need to fly to Seattle for that ;-)

Nee, CLIP Standard/Anzeige von Nummern: auf "keine Anzeige" stellen.

Das Problem ist sicher nicht im Dialplan (Rufschema). Der provider schickt diese Information zurück. Zu SipGate gibt es eine Seite mit Hinweisen, wie die Sipgate Leitung (Trunk) konfiguriert werden muss: http://wiki.snomone.com/index.php?title=Sipgate

Well there are two ways to let the PBX know that the routing has changed. First of all, tell the operating system! The PBX asks the operating system what IP address will be used when it sends a packet to some destination. For this, you don't have to configure anything on the PBX. So if your PBX should use a public IP address, configure it on the operating system level! Second, if the PBX should override the routing table on the operating system level (which is a remarkable step), you can update that settings through a SOAP RPC. Older versions did not update the internal override table, that has been fixed in recent versions. Based on that, you can write a script that does whatever you want to do and then update the routing table in the PBX. Please remember that the PBX is a server, not a client where you can fix NAT issues with a couple of STUN packets.

Comfort noise is only after dialing and before hearing ringback from the remote party. Before going on hold, there is no comfort noise. During that time, the phone is supposed to be quiet (digital silence). Maybe you can use your cell phone to record a MP3 and load it somewhere, so that we can listen to it... Then it probably becomes clear where the problem is.

SSH is not controlled by the PBX. If you cannot login with SSH, you have another problem. Maybe the whole host is gone or your Internet access...

For SSH, you can delete the table entry on the file system in the access directory. However that requires a restart. I think the easiest is to work from another IP and use the web interface to delete the entry or even whitelist it. For example, if you have a cell phone with a web browser, you could use that.

Actually that file should contain comfort noise... this is the phase when the line is not ringing yet, but you don't want to have this feeling that the line is dead. The noise should be decent, not loud.

I agree with Mr X. It might look like a problem with the dial plan, but it is actually a problem with the trunk. The upgrade to 4.5 brings a tremendous amount of flexibility regarding headers... at the price of sometimes not being 100 % backward compatible :-(

Oh other ports are much more flexible than rtp. you can use a list of space-separated addresses like "192.168.1.2:5060 12.23.34.45:5060 [::1]:5050" on SIP UDP, TCP, TLS and HTTP TCP, TLS and also on TFTP ports. It would read as "bind a socket to address 192.168.1.2 on port 5060, then another one on 12.23.34.45 port 5060 and another one on ::1 (the IPv6 loopback address) on port 5050. See http://wiki.snomone.com/index.php?title=Ports for some more information.

The overall problem is that every SIP TCP/TLS connection takes up one thread, at least with the current architecture. Every thread requires about 10 MB virtual memory space. So 100 threads are already 1 GB in the virtual memory space. While that is no problem for 64 bit, it is a problem for 32 bit (in total 2-3 GB memory space). The setting was essentially introduced as a default protection mechanism for 32 bit. It has nothing to do with licensing. Because it is a critical number we show it on the status screen. Maybe we should set it much higher for 64 bit systems by default.

Yes. Unfortunately that setting change requires a restart of the service.

Very good. In this version, you can configure practically anything for the SIP headers (http://wiki.snomone.com/index.php?title=Trunk_Custom_Headers is a great resource for that). Before you dig into the gory details, you might just want to try the available drop down in the trunk header section to see if that solves the problem already. Also, can you tell us what service provider you are using? Then other customers who are using the same, fill find this forum entry with the search-engine-of-their-choice.

Did you check the setting "Maximum number of SIP connections" in the admin/settings/port section?

Binding to IP addresses is a good way to use multiple cores and at the same time allowing users to use the same port 5060 on different IP addresses. For TCP this is relatively easy, because TCP sticks to the local address that was used when connecting to the socket. This does solve a big problem as long as users can use TCP or TLS for SIP. With SIP/UDP, things are more complicated. If you bind a socket to an IP address, the outbound traffic should actually also come from that IP address. Here it is important that the routing table (operating system level) has the necessary entries for that. For media, the PBX does not bind to a specific IP address by default. However there is a settings called "Bind to specific IP address (IPv4)" where you can specify what IP address the PBX should bind RTP ports to. The other workaround is to use different ports than 5060 for each instance. Ports can be "advertised" by DNS SRV if you use domain names. Then you don't even need multiple IP addresses.

snom ONE ist nicht gleich snom ONE plus... snom ONE läuft (auch) unter CentOS, auf einem "ganz normalen" Server. Vermutlich gab es da ein Mißverständnis. snom ONE plus ist ein Stück Hardware, auf dem snom ONE installiert ist und NetBorder Express von Sangoma, und welches unter CentOS läuft. Es gab vor einiger Zeit bei snom leider die Meinung dass es eine gute Idee ist, den Eigentümer der snom ONE vom Zugriff auf das Betriebssystem auszugrenzen; aber inzwischen wurde das aufggeben und man darf sich auch als root einloggen. Als root kann man dann alles machen was man auch auf einen ganz normalen Server machen kann (inkl. alles verstellen, leider). Die snom ONE appliance komplett ins DMZ zu stellen sehe ich nicht als allzu grosses Problem an. netstat sollte zeigen, welche Ports offen sind und ohne es jetzt überprüft zu haben gehe ich mal davon aus, dass dort kein FTP oder SAMBA zu sehen ist. Es sollten eigentlich keine ports sichtbar sein, die nichts mit der PBX zu tun haben, ausser SSH Zugang. Ja, den sollte man tatsächlich absichern, vor allem deswegen weil alle snom ONE plus mit dem gleichen Default-Passwort ausgeliefert werden. Wenn es auf der Firewall geht, wäre eine einfache Lösung, alle TCP/UDP ports ausser SSH/TCP auf snom ONE plus abzubilden. Wichtig bei DMZ ist, dass snom ONE tatsächlich die öffentliche Adresse auf dem Interface konfiguriert hat. Faustregel ist, wenn Pakete nicht zu snom ONE reroutet werden können (und zwar unter der Adresse die im Interface und in den Routing-Tabellen eingestellt sind), wird es auch schwierig mit two-way audio. Die SIP ports 5060/5061 sind relativ klar; Problem ist oft dass ein weiter Bereich an RTP-Ports auf snom ONE abgebildet werden müssen. Wenn es zu wenig Ports sind besteht die Gefahr dass verschiedene Calls auf dem gleichen Port landen. Jeder Call braucht 4 ports, also wenn man 10 Calls parallel haben will muss man auf jeden Fall mindestens 40 RTP ports forwarden. Ich würde aber auf jeden Fall kräftig überdimensionieren, z.B. 100 oder 200 Ports damit es da keine Probleme gibt.

Loop detected on the Sangoma card?! Sounds like something got screwed up in the outbound proxy setting of the trunk, probably you are missing the port number (should be sip:127.0.0.1:5066 not 127.0.0.1 if I remember correctly).

Does your license have enough extensions? What version are you running?

Well it is hard to produce. So we need to find out how we can narrow it down. Wireshark has options to gather 24/7 traces, which would be one way to get more insight. The other way would be to check if there is a special way of transferring the call. I would not exclude that the phone tells the PBX to connect them together; for example maybe it is too easy to choose "conference" instead of "transfer". We can set up automatic testing for 1000 transfers, but I would give that a low probability for problems. We have to keep in mind, that most other installations with less heavy transfer traffic obviously don't have problems in this area.

For automatic recording, it is all or nothing... So you would have to record all of them and remove the unwanted with a script.

Well, you can change the content of the page in the template. At least that should help for the font size. In the next version, those pages will be a lot more based on JavaScript (processing XML content coming from the PBX), so that it will be a lot easier to tailor such pages.