Vodia PBX

Thanks, but the INVITE is missing. It should be right in front of the 200 Ok. Can you also attach this?

Looks like the phone always send a Alert-Info header?! If you look at the SIP packet than the phone sends out you should see it. I remember there is a setting on the phone that tells the phone that every call must be connected immediately. There are a lot of settings... Is it an option to factory reset the phone and plug and play it with the PBX?

If you just enter the IP address like "192.168.1.3" it should work already (at least in the LAN).

snom ONE plus? Soweit ich weiss ist das in Arbeit, sollte eigentlich zeitgleich mit den anderen Updates passieren (theoretisch).

Da gibt es auch mehrere Möglichkeiten. Eine Möglichkeit ist der Einsatz eines manuallen Service Flags (Ein-/Aus-Schalter). Dann kann man diesen Schalter sehr einfach umlegen und damit zwischen intern oder extern umschalten. Diese Lösung ist einfach, jedoch kann muss man vorher die Nummer festlegen. Man kann auch die Nummer jedes mal neu programmieren. Dazu gibt es den Code *80 (siehe http://wiki.snomone.com/index.php?title=Call_Forwarding, Deutsch habe ich auf die Schnelle nicht gefunden). Dabei muss man hinter dem Code angeben, welche Gruppe umprogrammiert werden soll, z.B. *8070 um die Gruppe 70 umzustellen. Das ganze kann man auch vom Handy aus machen. Sobald man es in seine eigene Mailbox geschafft hat, kann man von da aus Codes wählen die mit * anfangen, also auch *80.

Es gibt einen einfachen Trick. Man kann beim SIP-Trunk einstellen, nach welcher Zeit er sich wieder neu registrieren soll. Dann ignoriert die PBX die Zeit, die von Registrar vorgeschlagen wurde. Einfach "Keepalive Zeit" auf 30 (Sekunden) einstellen, das löst das Problem in vielen Fällen.

Not sure, but the problem could be solved with the new cell phone menus on the head version. The whole assistant has gone through a major overhaul.

Ja das geht. Es gibt sogar mehrere Möglichkeiten. Bei den "Tasten" für eine Nebenstelle kann man "Rufumleitung" auswählen. Dort kann man dann auch die Nummer einstellen, auf die umgeleitet werden soll. Man kann eine Taste als "Handy"-Taste programmieren. Dann kann man ein Gespräch auf dem Telefon auf dem Handy "mitnehmen" und umgekehrt wieder am Telefon aufnehmen (sofern das Handy über die PBX angerufen wurde). Beide Möglichkeiten setzen voraus, das das Telefon automatisch provisioniert wurde.

Nein. Wir hatten vor ein paar Jahren ein Setting dafür, aber es war sehr "Support-Intensiv" um es mal so auszudrücken. Im Idealfall funktioniert STUN; aber es gibt halt viele Fälle wo die PBX keine Chance hat, über STUN eine öffentlich adressierbare Adresse zu generieren. Das Stichwort lautet hier symmetrical NAT. Es gibt aber auch viele andere NAT Implementierungen, die ebenfalls mit STUN Probleme bereiten. Kurzfassung: STUN ist ein Hack für ein Hack (NAT), und das wollten wir uns dann doch nicht antun. Die meisten Service-Provider verwenden heute Session-Border-Controller, die das Problem besser lösen. Ausserdem muss man sagen, dass für solide PBX-Installationen auf jeden Fall eine Adresse die vom öffentlichen Internet geroutet werden kann geradezu eine Voraussetzung ist. STUN ist halt oft instabil und man sucht tagelang nach Problemen und kann auch keine Telefone z.B. von zuhause registrieren. Wenn IPv6 kommt, ist das Thema eh gegessen, und es scheint ja nicht mehr lange zu dauern. Für uns ist IPv6 jedenfalls eine großer Erleichterung. Bleibt zu hoffen, dass die Router-Hersteller es diesmal nicht wieder vermasseln!

You should use plug and play and follow the manual. Support is very hard if you use your own settings.

You can send me a private message?! Anyway if that does not work send it to pbx_support instead.

Well, you should use plug and play. For example, the domain registrar is wrong. For the volume, there are keys on the side to control the volume. Anyway, good luck with 3CX and Grandstream.

For the activation, you need internet connection. The codes are 4 x 3 digits. If it does not work, send an private message to me with the actication code and we'll manually activate the license.

I am not sure, but I guess the download location for the english prompts have been updated. Other languages are following.

Then please check if you actually turned SRTP on or use PnP... There is a setting "RTP encryption" and it could be that this setting is "off".

A quick check from here: When I use TLS and make sure that "RTP Encryption" is on, at least calling the mailbox is encrypted. Maybe a configuration problem? Did you use plug and play to configure the device?

One of the big changes was the header prepresentation in the trunk. We simply had to face the fact that there are at least as many "standards" as there are service providers and how they want to use the headers. There is a new wiki page for this: http://wiki.snomone.com/index.php?title=Trunk_Custom_Headers. The new version should give you a trememdeous flexibiity to deal with all kinds of service providers. During the upgrade, the PBX should automatically generate the variable content based on what you selected with the dropdown before; in theory it should be backward compatible, and we know what (sometimes) that means in the IT world. Keep in mind that you probably have to load new prompts into the system. There are a lot of more options for the cell phone user now, and that requires new prompts.

Well, first of all the lock only indicates that the traffic between the PBX and the handset is encrypted. There used to be a feature called "end to end encryption" on the PBX, but in the last five years NOBODY ever paid attention to that and even the IETF is still arguing what exacly "sips" means. I agree the lock on the screen is something that needs to be fixed, but the actual encryption is definitevely more critical. You might want to take a look at ZRTP (the m9 supports that, see http://snom-m9.blogspot.com/2011/09/does-zrtp-solve-key-exchange-problem.html), this implements end-to-end encryption but both sides need to have it. We would have to support the ZRTP packet passthrough also in the PBX, which would not be very hard, but something that would have to be done. The ticket number is just for refenence in the release notes. The ticket system is not public. I agree there is a lot of marketing bla bla in the security area. Only very few people really pay attention to it. For most customers, the color of the handset is much more important than encrypting their voice.

Hunt groups do call waiting, they dont queue up callers. For low densitiy lines, that might be an answer. But especially for busy lines, you need ti distribute the calls and hold them until someone connects the call. So getting closer to the point... What you suggest is that also those agents who are not talking to someone in the ACD (e.g. a regular outbound call) should receive a call waiting? How would that improve the situation? They might be doing their outbound call and constantly hear call waiting, which after a time will probably be very upsetting after some time. If you want to show the agents that the queue is getting too full, maybe i tmakes more sense to inform them about the queue status. I have seen call centers where there installed LED boards on the wall that shows how many callers are waiting, so that all agents know if they need to speed up or not.

The M3 is end of life and never supported TLS/SRTP. So that part is clear. The m9 should always do SRTP. The indication on the handset can be a little bit "misleading", I would consider that a minor problem. Not sure why that is not the case when you talk to the mailbox. The only idea that I have is that the direct call answer screws something up. There is a ticket SMN-343 for this now, so if there is a bug the fix should be on the way.

That's exactly the point. Now you can try changes for the PnP on one extension and see how it goes, then copy & paste it to the domain or system level. That is/was a feature for a project that we are working on in the US office, where we want to be able to see who is at the door. The old way was to make a HTTP request for each frame believe it or not, but it seems that the 8.7 firmware for the phones now support MJPEG so that the feature might already be obsolete. This is for devices that don't support registrations. It can be useful to point a call leg always to the same location, e.g. a PSTN gateway. Not 100 % sure about that, but there are still service providers that cannot deal with early media and always expect 180 without SDP. This is not the CO-lines. You can monitor CO-lines.

TIP: Always make a backup of the working directory before upgrading the system. We tried to make it backward compatible as good as possible, but you never know and disk space is cheap these days.

snom ONE yellow is 10, and snom ONE blue is 40. The plus is a hardware, I think there it depends what kind of license you put on there.

As far as I remember the CS410 had 1 GB Flash (not RAM, which was 128 MB). On the Guru you can put in a SD card and extend the capacity this way. And it has 512 MB RAM, and 512 Flash built-in.

Meeting Point is a specific product from snom. Pro is that it should do plug and play and work without problems with snom ONE. People are also using Polycom confernece phones, though they would count against the third-party license.