Nach Umstellung auf Hosted, Telefone per SBC nicht mehr Provisionierbar

[SupArts]

Hallo,

ich wollte heute unsere Anlage auf Hosted 3CX umstellen, habe alles nach den Vorgaben gemacht und hat auch soweit funktioniert.

Intern wurde ein neuer SBC aufgesetzt, dieser läuft auf einem Raspberry-PI 5, hat eine feste IP und ist in der 3CX angelegt und auch erreichbar (grün).

Unsere angelegten Telefone hat es nach der Umstellung komplett aus der Liste geworfen, sind nicht mehr vorhanden.

Es handelt sich alles um Yealink T46G mit aktueller Firmware 28.83.0.136 was laut 3CX eigentlich unterstützt werden sollte.

Habe nun ein Telefon komplett resettet, beim User gelöscht und neu angelegt mit Verweisung auf den SBC, wird aber nicht Provisioniert.

Habe dann im Telefon die Bereitstellungs URL eingetragen, auch da keine Provisionierung...

Im Ereignisprotokoll sehe ich nur dies: "RPS request for Yealink (MAC:00xxxxx4477F) IP Phone of Pxxxxx, Gxxxxx delivered successfully"

Was kann ich tun ?? Die Anlage muss am Montag wieder laufen..

vg

 

[Claas Beyersdorf]

Also wenn das Telefon mit eingetragenem Provisionierungs Link nicht funktioniert gibt es mehrere Möglichkeiten:

- Das Telefon kann den FQDN nicht auflösen
- Das Telefon kann keinen NTP erreichen (weil der DHCP keinen verteilt, oder die Firewall es blockt, ...)
- Oder das Zertifikat der Anlage kann vom Telefon nicht validiert werden. (weil die Firewall TLS HTTPS Inspektion macht, die Zeit nicht passt, oder halt weil die G Serien Telefone EOL sind und der Trust Store schon länger nicht mehr geupdated wurde.

Ich würde erstmal versuchen die Config per Browser von der 3CX zu laden.

PROVURL/MACADDRESS.cfg wenn man die Konfig dann runter geladen hat kann man die auch über die WebUI des Telefons hochladen.

Das wären jetzt so erstmal meine Ideen. Sonst spricht man eine solche Migration normalerweise mit seinem betreuenden Partner ab.

Wir hätten den SBC z.B. im Vorfeld angelegt und die Telefone schon vor dem Umzug mal eine Woche über den SBC laufen lassen

vg

 

[StefanPf]

Only Accept Trusted Certificates" im Telefon deaktivieren. Die dürften den Let’s Encrypt CAs aufgrund fehlender Updates nicht vertrauen und können sonst ihre Einstellungen nicht abholen.

 

[fxbastler]

Hallo @SupArts ,
perfekte und schnelle Antworten an einem Samstag Nachmittag von
@Claas Beyersdorf und @StefanPf (Respekt!), weil:

1. das absehbare Problem / die Umstellung vorher mit dem 3CX Partner klären
2. die Migration / Umstellung der Telefone per SBC vorab durchführen
3. das (bekannte) Zertifikatproblem der Telefone vorab klären

Das wäre vmtl. vermeidbar gewesen, hilft dir nun nicht weiter. Bisher wurden die Telefone wohl im LAN per HTTP und IP provisioniert, siehe die Provisionierungslinks in der 3CX bei den Telefonen.

Man kann wie schon beschrieben in den Telefonen die Sicherheit bzgl. LetsEncrypt CA Trust per Provisionierungsvorlage der Telefone heruntersetzen (hilft dir aktuell - weil nachträglich - vmtl. auch nicht weiter) oder manuell in jedem Telefon unter Sicherheit / Vertrauenswürdige Zertifikate die Option Nur Vertrauenswürdige Zertifikate akzeptieren deaktivieren.

Alternativ kann man von https://letsencrypt.org/certificates das aktuelle ISRG Root YR Zertifikat als .pem herunterladen und in jedem Telefon manuell (oder per Skript) einspielen. Dann sollte die Provisionierung der Telefone (richtige Zeit u.a. vorausgesetzt) wie zuvor für die nächsten Jahre per HTTPS funktionieren.
Erklärung siehe hier: https://letsencrypt.org/2025/11/24/gen-y-hierarchy .

RPS des Telefon würden auch wir wie o.b. umgehen (k.A. on das überhaupt noch funktionieren kann), indem wir den akt. 3CX Provisionierungslink so eines kpl. zurückgesetzten Telefones manuell im Telefon eintragen nachdem das grdl. Zertifikatproblem behoben wurde.

Wenn das alles immer noch nicht funktioniert: Protokollierungsstufe des Aktivitätsprotokoll der 3CX auf ausführlich stellen, Telefon neu starten (ggf. zurücksetzen), Aktivitätsprotokoll bzgl. Downloads kontrollieren.
Bei einer 3CX hosted by 3CX sind div. Protokolle (Wireshark u.a.) wohl leider nicht möglich (man möge mich korrigieren wenn ich da falsch liege, wir haben keine solche, kann ich nicht nachvollziehen).

Halte uns bitte morgen auf dem Laufenden ob das reicht und funktioniert hat oder nicht / wo weitere Probleme auftreten. Die 3CX Community ist stets bemüht ...

 

[SupArts]

Hallo allerseits,

vielen Dank nochmal für die schnelle Antwort von @Claas Beyersdorf , was mich letztendlich in die Nähe des Problems gebracht hat.

Das Problem lag an einem unglücklichen Zusammenspiel vom DHCP und DNS Server, der letztlich auf die "alte" Anlage gezeigt hat.

Hab nun die Migration komplett durchführen können.

Vielen Dank nochmal an alle.

vg

 

[SupArts]

Hallo nochmal,

an was kann es liegen das Datum / Uhrzeit nicht mehr stimmen?

Egal ob ich in den Telefonen "Globale Zeitzone oder GMT +1 Germany" einstelle.

Wo kann ich suchen.

vg

 

[bitn2]

Hallo nochmal,

an was kann es liegen das Datum / Uhrzeit nicht mehr stimmen?

Egal ob ich in den Telefonen "Globale Zeitzone oder GMT +1 Germany" einstelle.

Wo kann ich suchen.

vg

Dann erreichen die Telefone keinen Zeitserver. Firewall?

 

[avraammich_3CX]

Wo kann ich suchen.

die Zeit, die das Endgerät empfängt, wird nicht direkt von 3CX bereitgestellt, sondern vom NTP-Server (pool.ntp.org).
Stelle außerdem sicher dass Firmware auf dem Telefon die richtige ist:

Phone Firmware

Download the latest distributed IP phone firmware by 3CX in case your device needs manual updating. Phones must run at least the minimum required firmware

www.3cx.com

 

[SupArts]

Dann erreichen die Telefone keinen Zeitserver. Firewall?

Holt sich jedes Telefon die Uhrzeit selbständig vom NTP ? Dachte das geht auch über die 3CX

 

[StefanPf]

Jedes Telefon mittels NTP.Die zu verwendenden Server werden durch den 3CX Parameter "TIME_NTP_SERVER" vorgegeben.
(Falls man das z.B. auf einen internen NTP Server umleiten möchte)