Hallo,
wir versuchen gerade ein Snom Telefon mit einer Cloud Telefonanlage zu verbinden.
Dies haben wir nach der Anleitung (https://www.pascom.net/doc/de/endpoints/snom/) in einer Cloud Instanz eingerichtet.
Allerdings übernimmt das Telefon die Einstellungen nicht (Provisierung fehlgeschlagen). Auch ein Aufruf der generierten Provisierungs-URL im Browser gibt nur einen HTTP 404 Fehler aus.
Woran kann dies liegen? Das benutzte Modell ist ein Snom 360 bzw 370.
Gruß Hendrik Unkenholz
Hallo @ncnkg,
das der Aufruf via Browser scheitert ist normal, da auch der User-Agent geprüft wird und der reguläre Browser Aufruf nicht vorgibt ein Telefon zu sein.
Sollte es nicht die pascom.cloud sein könnte es am Server-Zertifikat liegen, aber auch die Uhrzeit des Telefons spielt eine Rolle (wenn die Uhrzeit via NTP nicht bezogen werden kann sind die Zertifikate 1970 leider noch nicht gültig).
Grüße,
Steve
@Steve
habe scheinbar das selbe Problem mit meinen Snom 370
Zudem ist auch das Telefonieren ein bzw. Ausgehend über einen Peoplefone Trunk nicht mehr möglich (Siehe mein Thread Peoplefone SIP Trunk & Pascom Cloud - No Authentication)
läuft auch auf einer Cloud Instanz…
mein Snom hat lt. Log die korrekte Zeit also dürfte das Zertifikat als Fehler ausscheiden?
Hallo @Steve,
die Zeitzone und die aktuelle Zeit stimmen soweit auch. Also Adresse habe ich die URL kopiert (https://pascom.cloud:8884/p/XXXXX).
Gibt es eine Möglichkeit im Log zu sehen warum dies fehlschlägt? Im Snom habe ich so nichts gefunden und im Pascom ist der Log komplett leer bei dieser Provisierung.
Gruß Hendrik Unkenholz
Hier der Log aus dem Telefon:
3/1/2019 08:55:52 [NOTICE] PHN: Config setup: return code 500; requeueing >https://pascom.cloud:8884/p/XXXXXXXX<; attempt: 29, state: 29, duration: 64/70
3/1/2019 08:55:54 [NOTICE] PHN: Fetching URL: https://pascom.cloud:8884/p/XXXXXXXX
3/1/2019 08:55:54 [ERROR ] PHN: TPL: Socket Error: 40/21/connected, read -> Operation now in progress (150)
3/1/2019 08:55:54 [NOTICE] PHN: webclient::on_tcp_close conn_id:30Bitte prüf mal die Firmware und auch die URL auf Vollständigkeit:
https://www.pascom.net/doc/de/endpoints/snom/#empfohlene-firmware
Hallo,
die URL ist vollständig kopiert und auch die Firmware entspricht der empfohlenen. Ein HTTP 500 Error deutet ja auch auf einen serverseitigen Fehler hin oder nicht?
Gruß Hendrik
Hallo, habe so ziemlich das selbe Problem
Hier der Auszug vom Syslog des Telefons…
Auch Return Code 500…
Gruß Christoph
Hallo @ncnkg,
konntest du das Problem lösen? Bzw. hat sonst jemand eine Idee an was es liegen könnte ?
Wäre über Antwort dankbar,
Grüße Christoph
Ich habe ein ähnliches Problem und der Pascom Support hat mir verraten, wie ich die Provisioning URL von einem normalen Betriesystem (Linux …) aus testen kann:
https://wiki.mhcsoftware.de/pascom
Bei mir ist es im übrigen so, dass das Provisioning fehlschlägt, da das M700 nicht schnell genug ins Netz sprechen kann und die von SNOM gewählten Timeouts zu kurz sind. Das führt dazu, dass zu dem Zeitpunkt zu dem das Provisioning per HTTPS stattfinden soll die Zeit noch auf 1970 sitzt und das Zertifikat nicht geprüft werden kann. Da aber bei mir das Ganze wohl auf Probleme mit dem Switch zuzurückzuführen ist tausche ich den am Samstag. Falls es hier noch von Interesse ist ob das geholfen hat, berichte ich wieder.
Der nette Supporter von Pascom hat mir auch erklärt, dass solange das Provisioning nicht ein mal erfolgreich war sich die URL immer wieder ändert. Es lohnt sich also die URL mal zu kontrollieren.
Hallo,
bei uns auch…
Snom370 mit …25.5 FW lässt sich in der Cloud 18.03 nicht prov.
In der 18.01 hat das noch sauber funktioniert - sogar mit einem uralt FW-Stand.
cu
Christoph
Nach dem ich den Access-Switch getauscht habe und die Up-Link-Probleme (LACP, Spanning Tree) behoben habe klappt jetzt das Provisionieren der M700. Die Timeouts im Syslog sind alle weg.
Hallo,
kann mir das mit dem Switch irgendwie nicht als Ursache vorstellen. Habe hier nur einen Router und Switch, beides wurde nicht geändert. Vor 18.03 hat es tadellos funktioniert jetzt nicht mehr.
Ist denn der Mechanismus die Provisioning URL immer wieder zu ändern falls es fehlschlägt neu ?
Wenn ich mir die Logs anschauen hat das Telefon wirklich beim 1. Versuch noch keinen NTP Server für die Zeit erreicht, danach kommt das “Prov ETA xx sec” am Display und da sieht man sowohl im Log und auch am Telefon dass die Zeit nun erhalten wurde. Aber zu dem Zeitpunkt hat sich die URL schon geändert…
Habe im Snom eine Verzögerung gefunden, aber die verzögert den ganzen Phone.app Start und nicht die Provision selbst …
Noch jemand eine Idee ?
Grüße
Christoph
Hallo @c.k
bei meinem 370er tupfergleiches verhalten.
Ich habe mich heute Morgen nochmals mehrere Stunden an der prov. versucht…
Egal was ich tue, alles schlägt fehl. *grmbl…
Der oder die Tricker, die die URL neu generieren, würde mich auch mal interessieren!
Ein Tricker ist der Aufruf der Provisionierungs-URL selbst. Jedes mal ist sie anders, wenn Du drauf klickst.
Egal ob du das kurz hintereinander tust, oder längere Zeitabstände dazwischen sind.
Als ich Deinen Beitrag gelesen hab, kam mir noch folgende Idee…
Ich hoffe, dass 5 Min ausreichend sind und hoffe nicht, dass es einen Tricker gibt, der nach 2 Min. die URL wieder neu generiert…
solong…
cu
Christoph
Als ich das Problem noch hatte habe ich, um das HTTPS/NTP-Problem zu umgehen kurz einen HA-Proxy aufgesetzt der auf Port 8080 im HTTP-Modus lieft und auf 443 umgesetzt hat. Dann habe ich die Provisioning URL auf den HA-Proxy Port 8080 zeigen lassen. Die HA-Proxy-Config sah so aus:
frontend provisioning
mode http
bind 0.0.0.0:8080
use_backend server1
backend server1
mode http
server srv1 pascom.cloud:8884 ssl verify none
Um DNS Probleme zu umgehen habe ich dann die Provisioning-URL so anfangen lassen:
http://192.168.1.100:8080/......
Das hat den schönen Nebeneffekt, dass man im HP-Proxy-Log auch sofort sehen kann ob die URL angefragt wurde. Testen lässt sich das dann auch wieder hiermit: https://wiki.mhcsoftware.de/pascom - halt mit angepasster URL.
Am Rande: Bei mir ändert sich die URL auch nach erfolgreichem Provisioning weiter … ich werde den Support fragen warum.
Eine Ergänzung zum Thema Provisioning URL: Die URL ändert sich dauernd. Eine die einmal funktioniert hat bleibt aber weiter gültig.
Hallo,
also ich konnte es sowohl mit einem Snom 320 als auch 370 nur mit einer lokalen Pascom Version lösen in der ich die verschlüsselte Provisionierung deaktiviert habe.
Ursache ist vermutlich das die TLS Version des Cloud Servers nicht unterstützt wird:
Reboote mal und schaue was im Syslog steht. Bei mir war es so, dass das NTP nicht funktioniert hat und deshalb die Zertifikatsprüfung fehlgeschlagen ist da das Telefon auf 1970 stand. Nach 3-5 Minuten hatte das Telefon dann die korrekte Zeit und hätte provisionieren können. Beim M700 gibt es aber keine Funktion dafür im WebUI. Deshalb ja mal Workaround mit dem HA-Proxy, der auch in der Cloud für die Telefone HTTP an Stelle von HTTPS erlaubt.
Hallo,
Hier jetzt mal der Syslog von meinem Telefon ab dem Anfordern des Reboots, über die ganzen Versuche den Provisioning Server zu erreichen hinweg bis zur Rückkehr zum Standart Provisioning Server…
Meiner Meinung nach hat das Telefon schon beim ersten Kontakt eine aktuelle Zeit (aus dem Syslog ersichtlich)
Habe das mit dem Proxy auch probiert, sehe jetzt in der Pascom Modell und Firmware, aber die komplette Provisionierung lief trotzdem nicht durch…
Grüße Christoph
Dann wäre der nächste Weg den Snom-Support zu fragen:
Am besten gleich in englisch, sonst fängst du zwei mal an.