Vodia PBX

Damit sollte das Login auf das Telefon möglich sein. Die "47;domain=pbx.core.local" sind deswegen so komisch weil eine alte Firmware-Version kein @ zugelassen hat, und das wird auch nur verwendet wenn das Telefon etwas von der PBX will. Vielleicht gibt es schlichtweg ein Encoding Problem beim Copy & Paste. Das Passwort ist zwar ziemlich kryptisch (was gut ist), sollte aber nur reine ASCII-Zeichen enthalten. Ich sehe da allerdings ein A mit einem Dach drüber, das riecht nach einem Problem.

Well the thing is exclusive hold and non-exclusive hold A.K.A. park. You can pick up parked calls with *86. However if the calls are on (exclusive) hold, things get difficult from the m9. The snom 320 uses a different feature for this, which is not suitable for the m9.

Grundsätzlich ist es besser, für jedes Thema einen eingenen Thread aufzumachen, kostet nix extra... Der typische Fall für Kurzwahl ist die Zentrale in einem Hotel, wo nicht jeder sehen muss ob die nun aktiv ist oder nicht und wo man das System stark stressen würde, wenn alle 500 Räume ständig auf den neuesten Stand gebracht werden müssen. Ich glaube "Lampenfeld" ist so wie Kurzwahl, steuert aber auch die LED. Es gibt noch Besetzlampenfeld (BLF), bin mir nicht sicher welches hier das richtige ist. Es geht darum, ob man mit dem Drücken der Taste auch eingehende ANrufe annehmen kann. Das ist ein "Dauerbrenner". Die große Frage ist ob und wie der Provider es zuläßt, dass diePBX fremde Telefonnummern anzeigen darf. Das kann leicht missbraucht werden, z.B. könnte man als Caller-ID die Nummer der Kanzlerin angeben und so tun als ob man ganz wichtig ist. Praktisch macht es jeder Provider anders, und SIP ist bei dieser Frage leider auch nicht sehr klar. Damit nicht jeder einfach Anrufe starten kann, muss man sich authentifizieren. Dazu kann man den parameter auth verwenden. Dazu gibt es noch einen alten Link http://kiwi.pbxnsip.com/index.php/Click_To_Dial, unter dem Strich muss man die Authentifizierungsinformation in der Form user@domain:password verwenden und ordentlich URL-encoden. Wenn man einen normalen Broswer verwendet, sollte der eigentlich nach dem Usernamen und Passwort nachfragen (Popup Fenster).

Sieht so aus, als ob es bei ISDN ähnliche Probleme gibt wie in der SIP-Welt... Ich würde das Thema auf jeden Fall mit Sangoma eskalieren, das Gateway muss auch solche Fälle behandeln können.

Hmm. That looks good. Can you send me a private message with the base64-encoded certificate? Then we can try out to see what is wrong.

Certificates are unfortunately not an easy topic. You need to import the Root CA for that certificate (the one that signed the cert for the email server), in base64-encoded format. This starts with ----BEGIN CERTIFICATE--- and ends with -----END CERTIFICATE----. At the bottom of the import dialog, there is a select box, there you have to select certificate for server authentication. Please the field for the private key empty. Then the certificate should show up on the list of trusted Root CA (see http://wiki.snomone.com/index.php?title=Certificates).

Nein, das ist nur ein Dummy damit der Parser Ruhe gibt. Ich würde mir mal die Pakete ansehen, die an das Telefon geschickt werden--dort sollte der Header dann auftauchen. Das Telefon muss das natürlich verstehen, z.B. kann das m9 das schlichtweg nicht über den DECT-Äther senden.

Was steht denn im generated Directory der PBX? Dort sollten alle FIles stehen, die an das Telefon geschickt wurden, inkl. der Passwörter. Vielleicht wird dann klar was da los ist...

On many servers, the account name must include the domain name (e.g. voicemail@alabu.com); not sure if that is the problem here as the server seems to be local. The PBX probably does not accept the certificate from the email server. You can either import the certificate into the PBX or disable TLS in the Encryption dropdown.

Das Ganze geht vom Webinterface aus. Dort kann man sowoh lim Admin, auch im Domain oder sogar auf Extension-Ebene die Templates änder (Web Page Control). Ein guter Anhaltspunkt sind die Dateien, die im Directory "generated" abgelegt werden, dort kann man sehen welche Files die PBX generiert hat und auch was drin steht. Dann braucht man nicht alle Files zu durchwühlen. Settings für die Telefone gibt es tonnenweise. Die sind unter wiki.snom.com dokumentiert.

Das kann man in ringtones.xml einstellen; die Datei sollte sich eigentlich bequem vom WebInterface aus editieren lassen (Templates). Das kann man dann auch auf Domänen- oder Nebenstellen-Niveau machen.

There is lots of information available on the GuruPlug Wiki at http://plugcomputer.org/plugwiki/index.php/GuruPlug.

Ich würde einfach das Template ändern, dort kann man leicht einstellen ob das Telefon nun im Admin-Mode sein soll oder nicht und welche PIN verwendet werden soll.

Wochenende im Mai... ich bin mir nicht sicher ob Sangoma auch am Wochenende Support hat. Könnte sein dass die das Gespräch sofort verbinden. Daher fällt dort das Problem nicht so sehr auf. Ja Zeit gewinnen ist sicher eine gute Idee. Ich würde mal folgendes probieren: !130$!130! !730$!730! ([0-9]{3}$)!\1!t!100!

Das kann man sehen und auch ändern in WebPage Control, dann PnP auswählen, snom_3xx_phone.xml: <http_user perm="RW">{admin-user}</http_user> <http_pass perm="RW">{admin-pass}</http_pass> <admin_mode_password>{admin-pin}</admin_mode_password> <admin_mode_password_confirm>{admin-pin}</admin_mode_password_confirm> <admin_mode perm="">off</admin_mode>

Das ist mit Sicherheit ein Problem mit Sangoma NBE. Es gibt ein SW-Update, welches Probleme mit dem Deutschen ISDN angeht; das würde ich auf jeden Fall mal einspielen. Ich weiss allerdings nicht wo das herunterzuladen ist, die Leute die das wissen kommen Montag zurück ins Büro in Berlin.

Hmm. snom ONE plus does not make any difference when it comes to checking certificates. There is no special firewall between the PBX process and the interface that could check for virus or something else. At least no email should have get lost, they are stored in the spool directory until they are sent out.

Nothing I can think of... I guess other clients could use the service during that time?

In the trunk settings, when you send the call to an extension, you can have the PBX match the From-header instead of the To-Header or the Request-URI. Using multiple patterns, you can first check if it comes from a specific source, and then run the other patterns. For example: !8001234567!123!f !900[0-9]{7}!124!t 125

Sounds like a bug to me. One step forward, one step back... Hopefully it was one bigstep forward and one small step back.

Sind die Geräte mit Plug and Play configuriert? Dann werden standardmäßig die Angaben die in der Domäne im Bereich PnP angegeben sind (username, password, PIN) provisioniert und alle Telefone haben die gleichen Login-Daten. Bei Telefonen die auch mit zwei Logins klar kommen (snom m9) kann man sich darüberhinaus auch mit dem Benutzernamen und dem Benutzer-Passwort anmelden.

I would like to provide some background information about some changes we did in the transfer area. Attended transfer is all fine and we did not touch it; however for the blind transfer we felt that the blind transfer had to be improved. The overall problem with the blind transfer is that it might fail. That is very unsatisfactory for the one who called into the system. The one who initiates the transfer must know if the transfer failed, and if that is the case the call should not be just disconnected (callers thrown out of the system), but the call should get back somehow. If you want, the PBX is overlooking the blind transfer and if something goes wrong make sure that the call does not get lost. The answer is to use a temporary conference where the transferer is part of that conference until the call is successfully transferred, especially the transferer can hear if there is a ringback tone after the transfer and then get out of the conference. I believe that is a huge improvement compared to the situation when you never know if the transfer worked or not. Maybe we should involve the marketing department. They might propose to rename the blind transfer to automatic transfer, because there is a machine (the PBX) taking care about the details.

I believe it is easier to follow the PnP. Otherwise, you'll get easily stuck in outbound proxy, transport layer, buttons and so on and at the end of the day spend more time on the proper configuration than using the PnP.

Oh so the PBX is running on public IP?! Then everything should be "automatic"... I would not mess with the setting on the router that the phone uses to talk to the Internet. If it does not work out of the box, you simple need to use a different router; but thats typically only in the case for < 30 USD routers or very expensive routers where you have to define a policy for each device. Plug and play might be the wrong description, but it is also possible to provision the phone from behind NAT. You should do that. http://wiki.snomone.com/index.php?title=Plug_and_Play is a good starting point.

I thought that the new header feature is able to take care about this?