ich habe seit einiger Zeit Probleme mit der Steuerung meines SNOM D785. Es ist im Windows-Desktop-Client als bevorzugtes Gerät eingestellt.
Ich wähle am Client, dann wurde bisher mein Telefon angerufen, dann erst das Gegenüber. Das klappt seit einiger Zeit nicht mehr. Meist wird das Gegenüber direkt angerufen und ich höre das Klingeln am Telefonlautsprecher. Oft wird das Telefon gar nicht angesteuert.
Das Problem scheint nur bei mir zu bestehen, jedenfalls hat sich sonst noch keiner bei uns gemeldet
Ich hab bisher:
Das SNOM zurückgesetzt
Das SNOM Template gegenüber dem Standard überprüft.
Das SNOM in der Anlage neu gespeichert (nicht gelöscht)
Das Desktop Client zurückgesetzt
Hat jemand eine Idee was ich noch machen kann?
Vielen Dank!
Gruss
Frank
Firmware snomD785-SIP 10.1.159.12 (war auch schon mit älterer Firmware so)
pascom 20.00.D11312
Clientversion 101.R3368_e8d634819
Das ist eigentlich das gewünschte Verhalten einer solchen Integration. Das eigene Telefon soll ja überhaupt nicht klingeln sondern direkt wählen. Hier gab es in der Vergangenheit bei SNOM die Besonderheit, dass die das Wählen etwas anders gelöst haben, als allgemein üblich.
u.a. bei Yealink und vielen anderen Herstellern wird das Wählen über das SIP-Protokoll ausgelöst. Der Vorteil hierbei ist, dass Telefonanlage und Endgerät nicht im selben Netz sein müssen, was ja alleine wegen der zunehmenden Verbreitung von Cloud-Technologie immer seltener der Fall ist.
Bei SNOM hingegen funktioniert der Rufaufbau über ein HTTP-Request. Nun ist das Telefon ja nicht per HTTP aus dem Web erreichbar - zumindest sollte es das nicht sein - und damit kann die Pascom das SNOM nicht direkt per HTTP ansprechen sondern nur in Verbindung mit einem Pascom-Client, der dann im selben Netzsegment wie das Tischtelefon laufen muss und als Proxy für das Telefon fungiert.
Soweit ich mich entsinnen kann, sollte da mal etwas seitend SNOM in der Firmware geändert werden, um anstelle von HTTP auch über SIP einen Rufaufbau starten zu können. Pascom muss dann hierzu auch die bisherige Implementierung ändern. Ob das allerdings schon umgesetzt ist oder erst noch kommt, vermag nur @staff zu beantworten.
Zumindest ist das Verhalten “Nummer anklicken und Telefon geht in Freisprechmodus bzw. schaltet das am Telefon angeschlossene Headset sein” korrekt. Alles andere war eher eine Krücke. Allerdings sollte das dann immer zuverlässig funktionieren. Wenn dem nicht so ist, kann der Pascom Support sicher weiter helfen.
Seit wir Pascom nutzen haben wir die Cloud Anlage. Windows-Clients und Hardware-Telefone waren von Anfang an in getrennten Netzen. Es war immer so, dass ein initiierter Anruf per App wie ich bereits schrieb einen Anruf am Telefon auslöste (asterisk steht am Display) und dann erst die Gegenstelle anwählte.
Es ist schon eine Weile her, dann fing es an, dass einmal erst mein Telefon angewählt wurde und einmal direkt die Gegenstelle gewählt wurde. Das war dann einmal so einmal so.
Wenn das nun so ist wie du schreibst, dass es normal ist, dass direkt die Gegenstelle direkt angewählt wird, dann wäre das ja ok. Aber zuverlässig läuft es halt leider überhaupt nicht.
Also das mit dem HTTP Request vom der APP auf das Telefon kann ich nachvollziehen, die Zugriffe sehe ich im Log der Firewall. Das wusste ich nicht.
Ich dachte immer das Telefon reagiert nicht, aber ich habe festgestellt, dass der Anruf den ich mit der App auslöse nicht rausgeht. Es steht in der App “Verbinde…”, wartet man ab erscheint die Meldung “Anruf konnte nicht aufgebaut werden”.
Versucht man es darauf gleich nochmal, geht es. Mein Rechner ist ausgehend nicht gefiltert.
ich kann nur vermuten das die Firewall hier beim jeweils ersten Verbindungsaufbau via HTTPS zum Telefon anders reagiert, als in den folgenden und das zu dem beschriebenen Verhalten führt. Genau kann man das natürlich nur mit Client Debug Logs, pascom Server Logs und u.U. Firewall Logs sagen.
Wenn ich das aber richtig interpretiere, ist dir der “originate Dial” also das Verhalten, dass erst das Telefon angerufen wird lieber. Das ließe sich über zwei Wege “erzwingen”:
Am Telefon selbst ein anderes http Kennwort vergeben (dadurch kann sich der Client nicht mehr authentifzieren, um den Anruf abzusetzen)
ein generisches SIP Device anlegen und dem gleichen Benutzer zuweisen. Diese SIP Credentials dann am Telefon hinterlegen. (Wenn wir nicht von einem Snom Desktop Phone ausgehen, dann versuchen wir es auch nicht “fernzusteuern”).
vielen Dank für deine Antwort. Ich dachte halt erst, das Verhalten vom Telefon wäre ein Fehler. Das ist so auch ok wenn es zuverlässig klappt. Trotzdem sind die Möglickeiten es zu ändern eine interessante Info.
Ich habe den Debug Modus im Client aktiviert. Natürlich ist seit dem das Problem nicht aufgetreten, wie soll es auch anders sein. Wenn es auftritt, würde ich dir die Daten zukommen lassen.
Im Firewall-Log sehe ich nur HTTP Zugriffe vom Client auf das Telefon, kein httpS. Verbindungsprobleme ins Telefonnetz sehe ich eigentlich keine.
Mein Kollege hat mir heute gesagt, dass er diese Probleme auch hat. Er hat ein D385 (FW 10.1.127.10).
Hallo zusammen,
ich habe ein sehr ähnliches Phänomen bei einem Kunden. Kurzübersicht der Konstellation:
1x Softphone auf Terminal Server #1 (pascom v90)
1x Softphone auf Terminal Server #2 (pascom v99)… ja ich weiß beides nicht mehr up-to-date
1x Snom D385 (Firmware 10.1.119.10)
Von den Softphones werden Click-2-Dial Anrufe (z.B. aus DATEV o.ä.) heraus begonnen, die dann am Snom als “bevorzugtes Gerät” aufgebaut werden sollen. Folgendes Verhalten tritt nun auf dabei:
bei Wahl von Terminal Server #1 klingelt das Snom zum Rufaufbau, dieser folgt sobald man den Hörer abnimmt
bei Wahl von Terminal Server #2 wird der Anruf sofort aufgebaut ohne manuelles Zutun
Lässt sich das logisch erklären? Liegts an den unterschiedlichen Client-Versionen?
ich kann dir zwar leider nicht sagen ob es an dem Versionsunterschied liegt (vermute aber eher weniger), ich kann dir aber zumindest erklären, wann das Snom Telefon sofort wählt und wann es zunächst nur klingelt:
Um das Telefon fernzusteuern versuchen wir über den pascom Client den Webserver des Snom Telefons zu erreichen, wenn dies fehlschlägt, kommt es zum sogenannten “originate dial”, d.h. wir Rufen das Telefon an und verbinden bei Gesprächsannahme mit dem eigentlich gewünschten Ziel.
Ich vermute mal Terminal Server #1 kommt nicht (über den hinterlegten Proxy?) auf den Webserver des Telefons.
Snom unterstützt aber mittlerweile das Fernsteuern auch über SIP Notify Nachrichten, so wie wir das bei Yealink schon handhaben (wir können hier also die bereits vorhandene SIP Verbindung zwischen Telefon und PBX nutzen). Diese Methode integrieren wir gerade und sollte bald für die pascom.cloud verfügbar sein. Dann würde also das “Anruf sofort aufgebaut ohne manuelles Zutun” in beiden Fällen vorliegen.
Hi Steve,
danke für die Erläuterung. Der Terminal Server #1 ist fremd-gehostet, der #2 hingegen in eigener Infrastruktur/Netzwerk. Womöglich liegt da irgendwo der Grund…
