Ja kann ich auch machen. Nur liegt meiner Meinung nach der Fehler nicht am Snom, wenn es einen 500er Rerturn Code bekommt…
Kann es sein dass Telefone bzw. vielmehr die MAC Adressen an der Pascom gesperrt werden?
Ich habe die Telefone im Zuge des Testen ja mehrmals aus der Pascom heraus gelöscht und dann wieder hinzugefügt…
Sonst noch Ideen ?
Grüße
Christoph
Hallo,
…die Pascom-Cloud v18.03 spricht TLS v1.2 - Die 3xx Snom mit letzter FW nur TLS v1.0
Ich bekomme jetzt ein neues fancy 46er Yealink. 
…Nachtrag: Übersicht im Snom-Wiki
cu
Christoph
Dann muss aber der von mir beschriebene Umweg über den HA-Proxy funktionieren …
Die sind eh besser 
Ich habe eine nicht ganz saubere Lösung gefunden. Die vielleicht noch jemand erweitern kann (via iptables).
Das ganze funktioniert auch wieder mit dem haproxy wie bei mahescho nur das die bind Zeile im frontend mit einem ssl Cert versehen wird und auf dem selben Port wie die pascom-cloud hört. Deweiteren wird im Snom der Provisionlink genau so gesetzt wie von Pascom vorgesehen also https://pascom.cloud:8884/p/…
bind 0.0.0.0:8884 ssl crt /etc/haproxy/ssl/test.pem
Das Cert habe ich sicherheitshalber nur mit rsa:1024 erstellt
— openssl req -nodes -x509 -newkey rsa:1024 -keyout test.key -out test.crt -days 3650
— cat test.key test.crt > test.pem
Jetzt muss ein dns Server aufgesetzt werden der z.B. via Bind9 anstatt der IP vom Pascom Server (pascom.cloud) die IP des Servers ausgibt auf dem der haproxy läuft.
Im nächsten Schritt diesen DNS Server bei dem Snom Telefon eintragen. Dazu erst einmal DHCP deaktivieren wenn aktiv.
Beim Reboot könnt ihr jetzt in der Log vom haproxy sehen, das die Provisionierung in mehreren schritten abläuft (Daher hat die Variante von mahescho auch nicht mit dem 320 oder 360 funktionert. Da sofort nach dem ersten funktionierenden Aufruf via http IP:8080/p/… gleich weiter mit https pascom.cloud:8884/p/ gearbeitet wird, bis die Provisionierung beendet ist). Ist diese durchgelaufen könnt ihr aber noch nicht Telefonieren, da das der falsche DNS Eintrag verhindert. Daher den DNS Server Eintrag im Snom wieder entfernen. Bei uns ist das sozusagen DHCP wieder zu aktivieren. Beim Reboot kann das Snom zwar jetzt nicht mehr provisionieren, hat aber die richtigen Einstellungen wenn alle Versuche gescheitert sind und Funktioniert.
Getestet mit einem Snom320 mit FW: 8.7.5.35
Besser wäre es sicherlich und schöner wenn entweder der Server der haproxy spielt auch als Gateway für SIP und rtp arbeiten könnte oder der normale Gateway alles was nach Port 8884 geht zum haproxy umleitet außer die Anfragen vom haproxy selbst und somit der Falsche DNS-Eintrag weggelassen werden kann z.B. via iptables. Vielleicht hat irgendwer da eine Idee. Damit die Provisonierung immer Funktioniert.
Hallo @mana,
schöner workaround für eine Netzwerk-Infrastruktur, in der alles bereits vorhanden ist - keine Frage! 
Wieviel techn. Aufwand muss ich betreiben, um ein Telefon zu provisionieren!?
Ein Großteil meiner Kollegen arbeitet vom Homeoffice aus mit Homeoffice Netzwerk. Es ist schlichtweg unmöglich bei jedem das Netzwerk entsprechend aufzubohren!
...wenn ein Pferd tot ist, steig ab
@mahescho
Unsere M700 haben sich alle sauber beim ersten Mal provisioniert.
Allerdings habe ich zwei Phänomene, die das Telefonieren unmöglich machen
In beiden Fällen sind die Gespräche komplett weg. Das mag an der FW-Version liegen. Würdest Du mir bitte sagen, welche FW-Versionen Du auf dem M700 und den Mobilteilen hast? In der Doku ist dazu nix zu finden!?
Nachtrag: hätte ich mal zuerst das Snom-Wiki gelesen… 
cu
Christoph
wird das Snom 360 in der aktuellen Cloud 18.04 noch unterstützt ?
G Nada
Also wir setzten in der Cloud nur die 355B25 ein die funktioniert eigentlich stabil
Gruß Markus
wir kriegen unsere 360 leider nicht mehr provisioniert …
Hallo @nada
ich konnte dein Problem in der pascom.cloud mit einem Snom 360 (Firmware 8.4.35) nicht nachvollziehen. Hast du ein Snom probehalber mal zurückgesetzt? Taucht das Zertifikat bei den Server Zertifikaten im Snom auf?
Besten Gruß
Sebastian
Hallo Markus,
Danke für Deine Antwort!
Genau mit dieser FW hatte ich den Ärger mit dem Reboot.
Nach dem Update auf 410B4 funktioniert alles wieder zuverlässig.
cu
Christoph
Hallo zusammen,
wir haben hier ein ähnliches Problem mit Endgeräten des Herstellers Grandstream (GXP1625 - neuste Fw).
Die Zeit passt auf allen Endgeräten, da NTP.
Ich sehe, wie das Telefon n-mal versucht die Provisioning-URL aufzurufen - was jedoch immer mit “http.bad” scheitert. Nun ist “http.bad” kein gültiger http-Fehlercode - aber die Watchguard davor schreibt es nunmal so in die Logs. Ich vermute es bedeutet nach (https://de.wikipedia.org/wiki/HTTP-Statuscode) Code 400.
Die Grandstream-Firmware (firmware.grandstream.com) sowie die NTP-Anfragen werden jedoch einwandfrei beantwortet - weshalb ich Probleme in unserem Netz ausschließe.
Wir nutzen derzeit noch die pascom cloud demo und hatten geplant mit ca.300Geräten dorthin zu migrieren. Vielleicht hat noch jemand eine Idee (ohne haproxy)?
Viele Grüße
Tim
Hallo @Tim1
lässt sich die Konfiguration im Telefonnetz über curl abrufen?
Beispiel:
curl -i -X GET -H "User-Agent:Grandstream Model HW GXP1625 SW 1.0.4.138 DevId 000b82811234" 'https://pascom.cloud:8884/p/z4C3ac34GKc56AGFM-hw8YME6N12FhwdvlM0y4I_7qt4l565OvVk53v6ygfp3EQH+/cfg000b82811234.xml'
Wie sieht die Provisioning URL denn im GUI des Telefons aus? Wichtig ist, dass “Config Upgrade via” auf HTTPS steht und die Provisioning URL ohne HTTPS eingefügt wird, z. B. “pascom.cloud:8884/p/z4C3ac34GKc56AGFM-hw8YME6N12FhwdvlM0y4I_7qt4l565OvVk53v6ygfp3EQH+”
Besten Gruß
Sebastian
Hallo Sebastian,
mit deinem curl-Befehl habe ich ein http 204 no-content vom apache bekommen.
Es funktioniert aber nun auch: Das Problem war, dass ich in der GUI des Grandstream, der Provisioning-URL dass “https” noch vorangestellt hatte. Oben in der Checkbox hatte ich natürlich auch https selektiert. Dadurch hat das Telefon vermutlich https://https://pascom.cloud:8884/p/asd…asd angefragt hat, was logischerweise scheiterte.
Also, besten Dank für diesen kleinen (aber entscheidenden) Hinweis! 