Vodia PBX

Yes, in principle you are right. However, running every RTP packet through the rule would be a huge CPU effort, that's why this subsystem is seperate. Of course iptables is faster; however because we support multiple platforms including Windows thats not really an option for us. Also the PBX operates on "application layer" that means it automatically detects suspicious traffic, which you can only do in the PBX itself, especially when TLS is being used (which rules out solutions that monitor the traffic on the interface layer). One weak point is that the PBX accepts TCP connections even if they are coming from blacklisted locations, just to shut them down right after that. In theory that could be a way to attack the PBX; however this would be only for destructive purposes, not for getting access to the system. In Windows you can actually run a function that checks for the IP address before accepting the connection, however because of the platform independence we did not use this feature.

Well if you are on version 3, things are tricky (4.5 introduced great header flexibility for a reason). All you can do is to "play" (try out) the different options in the trunk, look for RFC3325. If it all does not help, you might have to bite the bullet and upgrade to 4.5. There are a lot of reasons to do that anyway (backup, backup, backup and try to schedule this off-hours).

Okay, we are talking about trunks here, so you can forget about settings in the extension. The access list on system level is not related to either trunks or extensions, it is really for all traffic on the system. It is a good idea to blacklist anything if you dont have to deal with registrations from users on airports, home office, etc. Then of course you have to make sure that your SIP trunk provider can still send you traffic. The access list and the trunk settings are really two different layers in the system, you have to take care about them both, seperately. The word "Explicitly" implies that there is also a implicit way of doing that, which is specifying the outbound proxy on the trunk. In many cases, this is kind of unpredictable and even instable, that's why we (after years) introduced the explicit field where we give you control over what exact addresses you expect traffic from the service provider. This setting only affects SIP. RTP is not related to that at all, and you dont have to worry about RTP. RTP is even not part of the access list mechanism.

Well from what we heared (VMware-based) failover can be done within a second, and calls stay up almost unnoticed. Maybe you can check if the failover heartbeat frequency can be increased in Hyper-V. Syncronization between datacenters is all about bandwidth. If you have multi-gigabit, it should all be no problem; this is almost like the internal bus on the server. If it is in the megabit area, 30 seconds will be pretty good already :-)

For extensions, you can define from what IP the extension may register from. I would not consider that a strong security feature, though it definitevely helps. Disadvantages: (1) Still all traffic visible (2) IP addresses can also be spoofed, potentially at the risk of having an IP address in the LAN (3) Inflexible, DHCP might be your enemy. For trunks and in the real world, yes IP addresses do matter. There is a field called "Explicitly list addresses for inbound traffic" where you can enter a list (seperated by space) which IP address traffic is considered to come from this trunk. If you leave the field empty, the PBX tries to figure out by DNS resolution of the outbound proxy field which addresses are candidates. But if you can, you should make this explicit. The input field also accepts DNS names and also port numbers if you have them, but the DNS resolution does only A and AAAA (no SRV or NAPTR).

I think this is a problem because the hunt group changes the "From" name. This feature makes it possible to show the agent that the call is "from the hunt group" (concatenated with the original caller-ID) in the caller ID of the phone.

We still have a old TSP from pbxnsip times (must be the year 2008 or so). Is TAPI still in use?! I thought Microsoft dropped it with Windows 7. We could take a look at the old project and see if we can port it over to snom ONE 4.5.

TFTP works practically only in the LAN... of course the alternative is to set up a web server somewhere in the network and use that one for provisioning the files. The next problem will be tweaking a couple of parameters, so that e.g. intercom starts to work. Maybe just make a deal with sales and ask them to sell you a pbxnsip license key; that should make it a lot easier for you and also for us!

In such cases, please include the MAC of the physical interface; then we'll manually generate you a key that you can copy & paste into the target machine.

Hmm. Do you also see the traffic on the other side of the B2BUA? Maybe the codec negotiation runs into a problem on the other leg, and the PBX just relay the message "415 Unsupported Media Type". It can also happen if the PBX proposes SRTP, but does not get the SRTP key back.

Hmm. You could use the "calling card" account for that purpose (http://wiki.snomone.com/index.php?title=Calling_Card_Behavior and check also this one out: http://kiwi.pbxnsip.com/index.php/Calling_Card). However then customers would have to first dial the CC account number. Maybe we have to add a domain flag that instructs the PBX to ask for the extension, too.

Ja das hier ist ist die richtige Stelle. Was ist denn bei der Nebenstelle (Webinterface der PBX in der Domänen-Ansicht, Registrierung der Nebenstelle) als "Leitungen" angegeben? Ist das leer?

Whow, good to know. It could also have been solved by setting the codec on the trunk side on the PBX then.

In Linux, you dont have to worry about stabilty. Wireshark is only running when you start it and it does not install anything in the network stack (not like in Windows). You can even run tcpdump instead of wireshark, and then use wireshark on another machine as viewer.

/usr/local/snomONE/tftp

Ich würde mal zu 99 % vermuten dass das Problem auf der Trunk (Leitung)-Seite liegt. Die PBX generiert selbst nicht solche Fehlermeldungen, sondern reicht sie nur durch vom Service-Provider. Bei 4.5 kann man recht einfach die Header im Trunk ändern; vermutlich reicht es aus, P-Asserted-Identity einfach leer zu machen. Welcher Service Provider ist im Einsatz? Am Rande auch hier nochmal der Hinweis: Leute, bitte verwendet doch Plug and Play für die snom Telefone. Damit wird alles so eingestellt dass es keinen Ärger gibt. Hier wird UDP für SIP zwischen PBX und Telefon verwendet, was vor allem bei längeren Nachrichten problematisch ist und darüberhinaus auch noch unsicher.

Oh die Telefone laufen noch mit 7.1.30, und das auch noch mit UDP statt TLS. Die Telefone wurden noch bis vor kurzem mit dieser Version produziert, für snom ONE sind aber inzwischen vermutlich 1000 Bugs gefixt worden, so dass wir definitv den Einsatz von zumindest 8.4.34 oder später empfehlen. snom-PBX/4.2.0.3958 ist auch schon etwas betagt. Gibt es irgendwo noch Links für diese Version? Die sollten eigentlich inzwischen alle auf4.5 geändert worden sein. Grundsätzlich würde ich erst mal empfehlen, auf 4.5 http://wiki.snomone.com/index.php?title=Epsilon_Geminids_(4.5.0.1090) umzusteigen (Vorsicht: Link endet mit Klammer zu) und die Telefone automatisch zu provisionieren. Beim manuellen Einstellen der Telefone werden viele wichtige Einstellungen nicht vorgenommen, die alle potentiell Probleme darstellen und uns allen das Leben schwerer machen als nötig.Das beinhaltet das Upgrade auf eine neuere Version, bei der es wesentlich weniger Probleme geben sollte.

Dazu wurden verschiedene Lösungen vorgeschlagen, angefangen mit Exchange 2007 über andere Software. http://forum.snomone.com/index.php?/topic/3518-fax-to-email/ http://forum.snomone.com/index.php?/topic/1358-fax-to-mail-question/ http://forum.snomone.com/index.php?/topic/1316-virtual-fax-software/ Ich persönlich habe mir neulich einen Drucker für 200 EUR gekauft der analog zu Email verwandeln kann, das habe ich nur beiläufig bemerkt (der kann auch scannen, drucken und alle möglichen anderen Sachen). Das wäre auch eine Lösung zusammen mit einem ATA was man im Bereich 50 EUR bekommen kann. Das dürfte insgesamt billiger sein als so manche Software-Lösung.

Do you also have to use HTTP? Or can you run TFTP? The HTTP server might be a problem with snom ONE HTTP server, as it does not recognize Polycom headers for PnP.

This is strande, indeed. Wireshark can be run as seperate tool (www.wireshark.org), it is free of charge. This will help us finding out if the stream to the provider really goes out and how the packets look like. The tool that we have added in 4.5 is something similar, but has limits e.g. on the selection of the Ethernet interface and it only works in Linux. It is probably easier to just quickly install a standalone tool instead.

Polycom is considered a "third party device" which means that the automatic provisioning does not work by default with snom ONE. There is a optional license option available that takes the Polycom provisioning from the pbxnsip times and enables it also for snom ONE. Please ask sales for details on how to obtain that license. If you dont need automatic provisioning, you can still use the TFTP server of the PBX to provision the Polycom devices; however you must manually generate the data in that folder. Polycom provides provisioning templates for this purpose that you can edit with a standard editor.

Hmm. Everything looks good from the log. Usually audio problems happen the other direction. I assume the audio files are installed, especiall the audio_en/co_welcome_conference.wav file and it is readable. The only idea that I have is to install Wireshark and make a PCAP trace. Then we might find out what is going on with the RTP and if packets are being sent to the provider. P.S. Please try to upgrade to 4.5 (Epsilon), for a new installation that is definitevely a good idea. E.g. 4.5 has the Wireshark PCAP utility already included if you are running Linux.

Es gibt hier mehrere Möglichkeiten. Zum einen kann man bei der Leitung (Trunk) ja über die extended regular expressions (ERE) definieren wo der Anruf landen soll, was recht flexibel und dementsprechend auch kryptisch ist. Zum anderen kann eine Nebenstelle ja auch mehr als einen Namen haben, z.B. "48 49" (getrennt durch Leerzeichen).

Actually we would love to write up a how-to to use the snom ONE mini as a paging extension unit for the cisco unified call manager, so that you can dial from a Cisco extension into the paging account and perform overhead paging (e.g. using snom PA1 with multicast). Because there is only basic SIP call involved, that should be simple--in theory. But a clear step-by-step guide could help to make that a failsave guide for hospitals, shops, airports, and so on. Same for Avaya and other mainstream IP-PBX that support SIP extensions and/or trunks. If anybody could give us temporarily access so that we can set everything up that would be awesome.

Also generell würde ich ausser zu Spielzwechen davon abraten, die PBX mit irgendwelchen komplizierten Tricks ohne eine routbare Adresse zum Laufen zu bringen. Gerade wenn der Provider die IP-Adresse alle 24 Stunden wechselt, führt das immer zu jede Menge Problemen. Mir ist bekannt dass die IPv4 Adressen knapp werden und sich die Provider noch zieren IPv6 anzubieten. Letztlich haben die Anwender den Eindruck dass die PBX sehr instabil läuft und wollen ihre gute alte ISDN-Anlage zurück (was man nachvollziehen kann). Die Adresse auf der PBX ohne script upzudaten dürfte schwierig bis unmöglich sein. Möglich wäre es, ein externes Shell-Script laufen zu lassen welches alle paar Minuten herausfindet welche IP-Addresse vergeben ist und dann über ein weiteres script (z.B. curl) das Routing auf der PBX anpasst (IP-Replacement). Eine andere Möglichkeit wäre es einen IPv6 Tunnelbroker zu verwenden, der letztlich soetwas ähnliches macht (FritzBox unterstützt das ja wohl seit geraumer Zeit!) und Bria einfach über IPv6 laufen zu lassen. Die PBX kann gleichzeitig mit IPv6 und IPv4 arbeiten, so dass es im LAN dadurch keine Schwierigkeiten gibt.