Vodia PBX

Which version are we talking about on the PBX?

5.1.2 was missing the correct file for the 430, but the rest should work? It is also important that you put the right firmware into the tftp directory, see http://www.vodia.com/documentation/pnp_polycom.

No, the PBX stays out of this so far.

This is nothing serious, is it just the closure alert from the other side, check out http://tools.ietf.org/html/rfc5246#section-7.2 if you want to know more about it. 2,0 means yes that's fatal, and the reason is that the connection will be closed (close_notify(0)).

I don't think 400 calls will be possible with snom ONE; I would say 300 would be a possible number. However as snom ONE always tries to negotiate SRTP I would say in the real world, 200 will be the limit. But what you can do is run several PBX on the same host, and bind each PBX to one core (leave one core for the OS) and to one IP address: So then you can have realistically 600 calls on a quad core system and still run services on port 5060/5061.

Nono, to the outside everything will remain and look the same. It is just how the data is organized internally in the PBX process. For small installations it does not matter; but for larger installations the PBX could get into a kind of doom loop so we had to do something.

This question is difficult to answer. Compare it with the question "how many emails can I send with my email program". While both questions are important to make hardware purchase decisions, they depend on a lot of factors. For emails it is easy to understand that the number of recipients, the email size, encryption, white-list checking, archiving requirements have significant impact on the performance. For office PBX, the situation is similar: Are phone calls are being recorded? That cost a lot of performance. Does the PBX need to perform transcoding? That also cost a lot of performance, depending on the codec it can be dramatic Are phone calls being encoded with SRTP? That also costs performance. Is there hardware acceleration for network packet processing? That's the case for practically all new servers, but embedded systems often don't have that. How many call setups are to be expected. For example, if there are lots of hunt group call attempts, that has an adverse effect on system performance. Is any other traffic on the PBX? For example, when provisioning firmware for phones, those files can be very large and put an additional load on the server. Also, the number of registrations play a role. We 5.1.3 will change the internal database, which should lead to a day/night performance improvement in that area, especially when there are more than 500 extensions on a system.

Oder das neue ringtones.xml durch das Webinterface hochladen--dann ist kein Neustart erforderlich.

Yea we heard this also from other sides. Though I am a big fan of TCP, I wonder why they advertise TCP by default. In V5, when you set up a new Broadvox trunk, the outbound proxy is set to sip:broadvox.com:5060, which means it is UDP; so for new trunks we should be good.

Hmm. Koennte sein dass ringtones.xml-Aeanderungen einen Neustart brauchen ... Es gibt bei Version 4 glaube ich auch irgendwo noch eine spezielle Upload-Moeglichkeit um den Neustart zu umgehen.

There is a setting "auto originate calls" in the TSP. It works only if you have only one registration on your extension. See http://www.vodia.com/documentation/tsp for more details.

Sure, go ahead.

Wenn das das Handy einer Nebenstelle ist, kann es durchaus auch als "internes" Gespräch signalisiert werden. Das ist durchaus ein Feature. Mal mit einer "unkannten" Nummer probieren...

This attack may occur if you don't specify an outbound proxy on your trunk. The PBX may think that the call comes from a trunk if you don't tell the PBX where the traffic will go to (and come from). As far as I remember version 3 did not have IP blocking? Anyway, it would not hurt to block the IP as far as I can tell. I would use 46.4.100.0 with a netmask of 255.255.255.0 instead.

Should be. Try to drag & drop the call to the extension where you want it transferred.

Well version 3 did not have any protection against this. At those times, scanners were not very common yet. You can use the Linux iptables to block certain IP addresses; however this is tedious labor as those scanner keep on changing their IP addresses. But what you can do on version 3 is make sure that your passwords are reasonably secure and your trunks have the outbound proxy set. Then someone might be able to try out a lot of passwords and extension numbers, but will not succeed getting anything out of the system and eventually move on.

No with snom ONE it is not possible. The only scenario where it would make sense would be call redirections after timeout or always; however even there the problem would be that if the redirection fails there is no way the PBX can handle the call any more. Cell phone forking would not work because features like twinning and PVA require that the PBX stays in the loop. Also, when the user presses ## the call will not get back to the PBX.

Ja das ist der richtige Ansatz. Auf dem Telefon sollte man dann sehen dass das INVITE den entsprechenden Eintrag enthält. Wie es dann auf dem Telefon umgesetzt wird ist ein nächster Schritt; aber grundsätzlich sollte es den Header respektieren und entsprechend klingeln.

Die Klingeltoene sind grunstaetzlich in ringtones.xml definiert. Diese Datei kann in den Templates editiert werden. Bei den Anrufen wird zwischen intern/extern, Interkom und Gruppenanrufen unterschieden. Bei Gruppen kann in der Gruppe definiert werden wie es klingeln soll.

The free version does not support CSTA (which is used by TAPI), see http://vodia.com/versions

This number is since the last reboot. I would use a SNMP sensor for this, see http://www.snomone.com/documentation/snmp for more information.

I would say 90 % this is a routing problem. The PBX is probably supposed to send the media to an address that it cannot reach, for example a hosted PBX sending to 192.168.1.100. You will also see this easily in the PCAP or the trace.

That discussion is as old as ISDN telephony. The answer is complex. One of the core questions is who pays for the redirected call. Other questions include how to achieve features like call recording, barge in, park, retrieve and so on. Once the call has left the PBX it is very difficult to get it back. From a SIP point of view, the service provider must support 3xx redirection codes and REFER. AFAIK the number of providers that support it, is limited and the number of providers that support it properly, is very limited. So the bottom line is: Make your life easy and get more lines.

The missed calls are maintained on the phones (there is no SIP standard for this). The only thing the PBX does is indicate weather a CANCEL message was because someone else picked up. In this case the phone is supposed not to add the call to the missed call list. Also, a reboot resets the missed call list as it is a local list on the phone.

We are not living in an ideal router world. Many routers have limitations on how many NAT connections they can have at the same time. You might just run out of them. Usually the tables are separate for TCP and UDP, so that you might have the situation that you still have enough TCP connections thus the registrations are stable, but you are running out of UDP, thus you have problem with media. The other problems is when routers are firewalls and filter stuff out that they don't understand. Check if there is anything with "SIP" or "ALG" on the router and turn it off.