Cisco 8851 Provisionieren

ciscoX

Trial User
Basic Certified
Mitglied seit
11. Mai 2023
Beiträge
226
Guten Abend zusammen,

ich möchte gerne mein Cisco-CP8851-3PCC (Multiplattform Firmware 12-0-1) mit der 3CX On-Premise Anlage provisionieren.

Leider nimmt das Webinterface die SIP Daten meiner 3CX-Nebenstelle nicht an. Über die Fritzbox funktioniert es, wenn ich dort die SIP Daten der 3CX-Nebenstelle hinterlege und im Cisco wiederum die VOIP Daten der Fritzbox.

Ich möchte gerne das Cisco mit 3CX provisionieren. Ich habe mit Hilfe dieser Anleitung https://www.3cx.com/docs/custom-ip-phone-templates/ folgende Codezeilen ohne Erfolg versucht:



<model ua="CP8851">Cisco 8851</model>

<model ua="Cisco-CP8851-3PCC">Cisco 8851</model>

<model ua="CP-8851">Cisco 8851</model>





Bei anderen Usern funktioniert vermeintlich eine direkte SIP-Anbindung zur 3CX-Anlage On-Premise natürlich.

Nun ist die Frage, was mache ich falsch? Die richtige MAC Adresse habe ich unter Telefon -> Hinzufügen hinterlegt. In der 3CX Anlage wird kein Provisioning-Link ausgegeben (siehe Anhang).

Der Grund weshalb ich es nicht bei der Fritzbox-Anbindung belassen kann: Vom Cisco an CFD weitergeleitete Anrufe werden nicht zum Cisco zurückvermittelt. Resultat: Das Cisco klingelt nicht und die CFD-Ansage wiederholt sich in einer Endlosschleife. Es wird ein zweiter Anruf gestartet, anstatt blind an das Cisco zurückzuvermitteln. Im Cisco ist Blind X-Transfer aktiviert. Über Geräte mit installierter 3CX Apps funktioniert das Ganze wunderbar.

Vielen Dank bereits im Voraus für eure Hilfe und wünsche einen schönen Abend.

Viele Grüße.
 

Anhänge

  • Bildschirmfoto 2023-05-25 um 20.13.42.png
    Bildschirmfoto 2023-05-25 um 20.13.42.png
    19 KB · Aufrufe: 7
Hallo,
Leider nimmt das Webinterface die SIP Daten meiner 3CX-Nebenstelle nicht an.
Das Cisco IP Telefon sollte sich sinnvollerweise im gleichen Netzwerk wie die 3CX befinden. Dann würde ich das IP Telefon erst einmal direkt an eine eingerichtete Nebenstelle der 3CX anbinden. Neben der Angabe der IP und des SIP Port (5060 wenn nicht geändert) der 3CX als Registrar / Proxy im IP Telefon sind das:
  1. die Nebenstellennummer der Nebenstelle der 3CX
  2. die Auth.-ID von der Nebenstelle der 3CX
  3. das Passwort zur Authentifizierung von der Nebenstelle der 3CX
Es werden für die SIP Anmeldung eines VOIP Telefones an eine 3CX Nebenstelle also drei Daten pro Nebenstelle benötigt (nicht wie vmtl. nur zwei wie bei der Fritte). In dem Web Interface des Cisco ist das vmtl. User ID, Auth ID und Password.

Eine Provisionierung des Telefones mittels einer Vorlage durch die 3CX wie von dir beschrieben würde ich erst danach angehen - wenn überhaupt.
 
Eine Frage: Kennst du dich wirklich mit Cisco Telefonen und deren Firmwares aus oder ist das reine Vermutung?

Ich hatte gestern einen 3CX-Experten der selbst alle Varianten über Remote versucht hat. Auch wie du sagst. Funktioniert nicht!

Nochmal zu verdeutlichen: Es ist nötig das Telefon zu provisionieren. Grund steht schon oben.

Das Cisco wird sich nicht im selben Netzwerk befinden, da 3CX auf einer VPS in der Cloud läuft.
 
Eine Frage: Kennst du dich wirklich mit Cisco Telefonen und deren Firmwares aus oder ist das reine Vermutung?
Das sind schon zwei Fragen ;) Aber ich verstehe sehr gut warum du fragst. Das ist bei Cisco Telefonen mehr als berechtigt.

zu Teil 1) Ausreichend genug um zu wissen, dass es mit der Firmware 3PCC deines CP-8851 überhaupt möglich sein könnte. Soweit ich weiss, kann man generell nur Multiplattform Firmware an andere VOIP Server außerhalb des Cisco Universums anbinden, mit manueller Einrichtung per Webinterface oder automatisiert ausrollen / provisionieren wie du es möchtest. Beides ist möglich. Bei anderer Firmware ist ersteres entweder schlicht nicht vorgesehen oder scheitert an verschiedenen Details (s.u.). Letzteres kann bei einem MPP dennoch am Vertrauen scheitern.

zu 2) Ehrliche Antwort: auch hier nur selektives Wissen, und das ist gut so. Dein konkret angefragtes Telefonmodell kenne ich nicht. Die Serie und die Firmware Ausführung schon.

Nochmal zu verdeutlichen: Es ist nötig das Telefon zu provisionieren. Grund steht schon oben.
Mit provisionieren in diesem Kontext willst du immer verstanden wissen: automatisch + ausrollen + zentrale Verwaltung. Der Grund, warum das nötig sein sollte steht nicht oben. Ich habe noch einmal nachgelesen. Ich habe es nicht gefunden. Da steht nur, dass du das möchtest. Das ist vmtl. mein Fehler, ich habe es nicht verstanden. Fang doch erst einmal einfach an, wenn es schon solche Schwierigkeiten generell bei der Anbindung gibt. Komplexer kann man es später vmtl. immer noch machen.

Das Cisco wird sich nicht im selben Netzwerk befinden, da 3CX auf einer VPS in der Cloud läuft.
Das hast du so nicht geschrieben und ändert die Sachlage wesentlich. Erst schreibst du, dass du das Telefon mit einer 3CX on-premise (automatisch) provisionieren möchtest. Jetzt schreibst du, dass die 3CX in einer Cloud laufen wird. Beschreibe das bitte genauer. Kläre uns auf.

Ein Telefon direkt an eine extern betriebene 3CX anzubinden - so wie du es jetzt schreibst - bedeutet in diesem Fall STUN und nicht nur eine einfache Anbindung und Registrierung über den SIP Port (so wie ich es beschreibe). Friends do not let friends do STUN. Es ist nicht damit getan, in einer 3CX die Option 'Externe Telefone per STUN blockieren (unsicher)' zu deaktivieren. 3CX schreibt das auch bei den alten Modellen dazu.

Wenn die 3CX anderswo läuft, dann einen 3CX SBC in das gleiche Netzwerk wie das Telefon stellen und das Telefon wenigstens manuell gegen den SBC einrichten. Kein NAT, kein STUN. Nur wenn das irgendwann einmal funktioniert - was auch nicht sein muss, 3CX schreibt das bei den alten Telefonen explizit dazu - würde ich an eine automatische Provisionierung denken, s.o.. Eine direkte Anbindung an eine lokale 3CX war bei uns möglich und sollte es immer noch sein. Das hast du schon selber herausgefunden, dass andere das auch geschafft haben. Eventuell geht das eben auch über einen 3CX SBC.

Ich hatte beim Lesen der Frage gestern schon überlegt, ob ich überhaupt meinen Senf dazu gebe. Ich habe dazu noch eine Zeit lang wegen deinem Modell und insbes. der FW recherchiert, siehe auch hier https://www.cisco.com/c/en/us/produ.../ip-phone-8800-multiplatform-firmware-ds.html . Die Suchergebnisse und meine Erfahrung deckten sich gut genug um zu antworten. Einen Versuch ist es wert.

Wir hatten gegen 2018/19 mal einen kleinen IT Kunden der umstellen wollte (Ableger einer großen Firma, wollte sich lösen, musste daher mit der Telefonie eigenständig werden, wollte nicht alles neu haben). Wir hätten den wegen der IT haben wollen (weil es das ist was wir machen) und weil es ein interessanter Kunde ist. Die Telefonie war Teil der Bedingung zum Wechsel. Wir haben uns im blinden Glauben an die Umsetzung von VOIP Standards bei Herstellern zwei seiner Telefone für ein PoC geborgt, auch weil 3CX damals einige Cisco IP Telefone generell noch auf der Liste der unterstützten Telefone hatte. Das war sehr naiv wie wir sehr schnell feststellen durften. Cisco hat eine eigene Quadratur von VOIP. Es hat nicht bzw. nicht gut genug geklappt. Das Projekt ist letzendlich wirklich an der Umsetzung der Telefonie gescheitert. Das eine Telefon wollte nur mit Cisco Provisionierung von Cisco Anlagen funktionieren. Das hatte die falsche Firmware drauf und andere Fw war - obwohl es sie immerhin gibt - wegen Cert Dongelung nicht flashbar. Auch eine Provisionierung (XML per TFTP, wurde immerhin geladen) hat uns nicht weiter gebracht. Das andere Telefon hatte eine MPP Firmware und liess sich wenigstens manuell anmelden und nutzen. Daher antworte ich überhaupt hier. Das war vmtl. das CP-8861-3P.... und ähnlich genug deinem angefragten (wg. Firmware) so wie ich gestern noch recherchiert habe (s.o.). Dein angefragtes Modell ist auch Teil der 8800 Serie, die Firmware eine MPP. Wir haben die Telefone nicht mehr und es gibt keine Kunden Doku mehr von dem Projekt. Aber ich habe noch eine Unmenge an Downloads verschiedener Telefone, Links die tlw. noch funktionieren und Doku für viele von deren Telefonen. Gescheitert ist es damals daran, dass sich die gewohnte Cisco Tastenbelegung und Teile der Menüführung schlecht adäquat umsetzen liess, das Display zu wenig der dem Kunden gewohnten Informationen anzeigte (das war vmtl. das K.O. Kriterium) und die tlw. notwendige Bedienung mit 3CX Steuercodes für den Kunden untragbar war (es liessen sich nicht alle 3CX Funktionscodes auf die vorh. Tasten stellen). Generell sollte eine Provisionierung möglich gewesen sein. Sie wäre notwendig geworden, um die Menüführung maßgeblich zu ändern. Wir haben das dann nicht weiter verfolgt. Da die Umsetzung mit Bordmitteln schon nicht so gut gelang, hat der Kunde entschieden, das nicht nutzen zu wollen. Er wurde auch nicht unser IT Kunde. Der hat sich soweit ich weiss eine Openscape Business X aufschwatzen lassen. Ich habe da genug private Zeit verpulvert und mich nur mit dem Telefonieproblem beschäftigt. Von uns wollte er keinen neuen Telefone. Ich weiss nicht, wie die anderen das mit der Openscape geschafft haben ihm neue Telefone auszuliefern, allein schon preislich. Vermutlich hat er sich von dem HFA Feature der Anzeige des fremden Rufens (was eine 3CX nicht kann, wird immer wieder nachgefragt) und den flachen Geräten beeindrucken lassen. Egal, Geschichte, man kann nicht alles haben und machen. Wenn es keine Bastelei sein soll, dann bei heilwegs standardisierter und unterstützter Hardware bleiben oder wenigstens in Betracht ziehen mittelfristig nach und nach zu tauschen.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: bitn2
Erst einmal ein großes Danke für Deine Zeit.
Ich verstehe wie mühsam das Cisco ist, denn ich hänge seit 3 Wochen am gleichen Punkt und werde echt narrisch.

Der Grund weshalb ich das Cisco provisionieren möchte ist, dass wie du schon sagst: Die Tastenbelegung oder Funktionscodes von 3CX will das Cisco schlicht weg nicht verstehen. Dazu kommt, wenn ein aktives Gespräch (Warteschleife einer Hotline) an CFD weitergeleitet wird und der Mitarbeiter den Text To Speech Trigger auslöst (wurde mal in einem anderen Thread heiß diskutiert) nicht wieder auf dem Cisco ankommt.

Meine vorherige Lösung war eine IVR wo der Mitarbeiter die 1 drücken musste. Auch da gab es anfangs Probleme, denn wenn die IVR auf die Warteschleife weiterleitete, blieb das Cisco aus und klingelte nicht. Es musste also eine direkte Weiterleitung zum Cisco stattfinden.

Wenn ich angerufen werde wird zuerst die Warteschleife wiedergegeben in dieser auch das Cisco ein Agent als Nebenstelle ist. Das funktioniert dann. Es macht also was es will.

Bei der 7900 Serie habe ich meine ich gelesen, dass Blind Transfer nicht möglich ist. Wohl liegt hier das Problem. Mein Cisco baut wenn ich ein Gespräch an das CFD weiterleite ein 2. Gespräch auf, anstatt im gleichen Gespräch zu bleiben, zu warten bis der Mitarbeiter den Trigger auslöst und wieder ans Cisco zurückvermittelt.

Wohin das Cisco dann vermitteln will muss ich nochmal prüfen, habe diese Ansicht wie der Experte gestern gefunden hat noch nicht gesehen.

SBC war ebenfalls einer meiner Überlegungen, dann bin ich aber wieder bei dem Punkt PC muss laufen, damit das Cisco überhaupt funktioniert, habe kein Windows PC und müsste SBC in einer VM laufen lassen oder Linux VM. Da werde ich aber wohl wieder beim Portproblem festhängen, weil auf meiner FRITZ!Box bereits VOIP mit dem Port 5060 läuft und das hat die FRITZ!Box nicht gerne, bedeutet jedenfalls dass ich das 3CX System nicht zum laufen bekommen habe, da waren Portweiterleitung und Portanpassung zwecklos.
Ich habe den 3CX-Firewall Check nicht bestanden.

Ein anderes Telefon kommt für mich eben nicht in Frage, da für mich Cisco einfach am professionellsten ist, optisch sowohl auch vom System her und will noch einige Jahre Spaß damit haben. Ich denke das sieht bei SNOM, Yealink und was es alles gibt anders aus. Will da aber nichts falsches sagen, hatte diese Telefone noch nie in der Hand. Das ist purer optischer Eindruck. Welcher Herstelle druckt denn bitte „HD“ auf den Telefonhörer… *Facepalm* Ich denke es gibt Gründe, warum Großunternehmen zum Hersteller Cisco greifen.

Na ja bei deinem Kunden war wohl das Problem, dass es keine Multiplattform auf dem einen Telefon war und dann kannst du quasi nichts einstellen. So ging es mir zum Anfang. Ich habe eine Firmware per TFTP hochgeladen, aber das war dann keine Multiplattform. Lief trotzdem über die FRITZ!Box, aber Telefonbuch etc. war dann nicht möglich. Daher habe ich über Umwege eine Lizenz Enterprise2MPP erstanden und bin immerhin soweit gekommen Hintergründe, Telefonbuch, Deutsche Sprache etc. möglich sind.

Da haben wir uns missverstanden. Der VPS Server liegt in der Cloud und 3CX ist dort als On-Premise aufgespielt. Damit meinte ich nicht 3CX Cloud.
 
Da haben wir uns missverstanden. Der VPS Server liegt in der Cloud und 3CX ist dort als On-Premise aufgespielt. Damit meinte ich nicht 3CX Cloud.
Egal: die 3CX ist in einem anderen Netzwerk (noch dazu weit weit weg) als das IP Telefon. Das ist der entscheidende Punkt und Unterschied bei der direkten Provisionierung (die dann nicht funktionieren wird). STUN ist keine Option. Das Telefon wird so oder so nur direkt an einer 3CX provisioniert werden können. Da sich Telefon und 3CX in so verschiedenen Netzen befinden, wird das nur per gut eingerichtetem VPN oder per SBC - evtl. eben auch einem 3CX SBC - möglich sein. Dabei ist völlig egal ob das Telefon selber manuell eingerichtet wird oder automatisch durch irgend etwas provisioniert wird. Aber letzteres sollte man eben auch erst dann machen wenn ersteres auch nur ansatzweise funktioniert - was bei dir eben schon nicht so ist.

Der bisherige Einsatz der Fritte kommt in der Art ganz grob der Funktion einem SBC nahe - rein von der Logik. Da hat immerhin ein Teil funktioniert. Das Problem dabei ist: die Fritte ist eben kein reiner SBC. Der fehlt ein Teil dessen Funktionen und hat dafür andere - die einer Telefonanlage (und das auch noch schlecht).

Ein anderes Telefon kommt für mich eben nicht in Frage
Wenn du so an dem Telefon hängst, dann ist das Bastelei und wird es immer bleiben. Es ist nicht gesagt, dass je alle wesentlichen Telefonfunktionen dauerhaft funktionieren werden. Auch die, welche zeitweilig funktionieren, werden das nicht dauerhaft tun. So etwas kann man nicht professionell verwenden, ausser man hat 3k solcher Telefone und setzt das mit entspr. Kentnissen und Aufwand selber um an Statt alles neu mit vom Hersteller unterstützten Geräten auszustatten.

Mach doch einfach mal das was ich geraten habe: verwende einen lokalen Anmeldeserver für das Telefon (eben nicht die Fritte sondern einen 3CX SBC, alternativ einen anderen SBC oder auch eben mal eine Asterisk, dann darfste dich aber auch selber um Transportverschlüsselung u.a. kümmern) und binde diesen an die extern gehostete 3CX an. Verbanne zudem die Fritte aus jeglicher Kommunikation zwischen SBC und Telefon.

Das Port 5060 Problem der Fritte kann man einfach umgehen: Fritte entfernen, komplett. Oder ein Telefon Subnetz aufbauen, in das die Fritte keinen Anschluss hat - was wiederum dem Entfernen der Fritte nahe kommt. Die wird immer dazwischen funken, auch dem SBC bei der internen Kommunikation und nicht nur mit den Ports 5060.

Der 3CX SBC kommuniziert standardmäßig intern über die normalen SIP Ports 5060 (oder verschlüsselt 5061), extern per Tunnel Port 5090 und den HTTPS Port mit der 3CX. Den Tunnel Port der 3CX und des 3CX SBC kann man umstellen. Den SIP Port der 3CX kann man umstellen. Die intern für SIP genutzten Ports eines SBC kann man sicher auch umstellen (z.B. LocalSipPort=5062 in der Datei /etc/3cxsbc.conf.local auf dem SBC aktivieren und neu starten), das ist aber evtl. nicht dauerhaft erfolgreich, nie probiert. Genau da stört die Fritte. Ebenso bei Multicast in diesem Netz u.a. und das kann man nicht um- oder abstellen.

... weil auf meiner FRITZ!Box bereits VOIP mit dem Port 5060 läuft und das hat die FRITZ!Box nicht gerne, bedeutet jedenfalls dass ich das 3CX System nicht zum laufen bekommen habe, da waren Portweiterleitung und Portanpassung zwecklos.
Ich habe den 3CX-Firewall Check nicht bestanden.
Bei einer On-Premise 3CX hinter einer Fritte kann man das umgehen, indem die 3CX andere SIP Ports verwendet. Das wird bei der Ersteinrichtung der 3CX mit dem Assistent oder beim Restore eines Backup nach Reset der 3CX mit diesem eingestellt.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: bitn2
Hallo,

entschuldige bitte für die späte Rückmeldung.

Meine 3CX läuft nun self hostet.

SBC funktioniert auch, allerdings lässt sich das Telefon immer noch nicht provisionieren.

Soweit nicht schlimm, da ich durch die Multiplattform Fire direkten Zugriff auf das Webinterface des Cisco 8851 habe und soweit alles einstellen kann.

Allerdings hätte ich gerne die BLF Funktion meiner weiteren Nebenstellen. Das würde dich ebenfalls über das Webinterface realisieren lassen, allerdings kenne ich die Paratmeter nicht und weiß auch nicht, ob 3CX und mein Cisco Modell (unsupported) miteinander kommunizieren können.

Ich habe schon einiges probiert, die XML Datei vom SPA805G zu verwenden. Irgendwo habe ich gelesen, dass dich bei Asterik mein Model mit der .XML Datei des SPA805-G provisionieren lässt und habe anschließend die Provisionierung-URL wie von 3CX bereitgestellt im Cisco eingegeben.

Aufeinmal steht da aber überall „1006“ auf allen Line-Keys meines Cisco, allerdings verbindet es sich nicht mit den SIP Details.

Auf der Cisco Webseite steht soweit von mir richtig verstanden, dass die erste Extension für alle anderen Lines verantwortlich ist. Da steht die FQDN mit dem Port 5060 als Proxy.

Normalerweise trage ich als Proxy die IP meiner FRITZ!Box ein. Wenn es über den SBC läuft natürlich die FQDN und zusätzlich als Outbound Proxy die lokale IP meines SBC.

Viele Grüße
 

Statistik des Forums

Themen
44.442
Beiträge
232.821
Mitglieder
78.340
Neuestes Mitglied
DirkS5970