Jump to content

SwyxPhones L420e an SwyxWare 2015 R30.5.0


Telcom_Admin

Recommended Posts

Hallo Zusammen

 

Habe da ein kleines Problem...

 

Wir haben eine hosted Swyx Lösung, mit den älteren L420e Phones. Diese kann ich zwar registrieren, sehe auch das diese sich anmelden, jedoch kommt kein Mediastream zustande.

Ich habe auf den SwyxPhones die Firmware V5.6.1.0 drauf, die Verschlüsselung, Server seitig deaktiviert. Leider bekomme ich immer noch kein Mediastream hin.


Ich habe alternativ, mal in den CTI Modus geschaltet und von einen anderen SwyxIt Client intern auf diesen User angrufen. Da zeigt mir SwyxIt nacher an, das es ein inkompatibles Endegerät ist...

 

Hat jemand von Euch schon dieses Problem?

 

Danke und Grüsse

Remo

Link to comment
Share on other sites


  • 1 month later...

Hallo Zusammen

Gibt es eine Lösung zu dem Problem?

 

Ich habe den gleichen Aufbau mit den gleichen Endgeräten. Der MediaStream wird sporadisch nur einseitig aufgebaut, solange die SIEMENS SWYX Telefone verwendet werden. Ein reines Gespräch zwischen zwei SwyxIt Teilnehmern, die ein an den Computer angeschlossenes Headset verwenden, hat keinerlei Probleme.

 

Hilfe!

 

Lieben Dank

Michael

 

Link to comment
Share on other sites


  • Most Valued User
On 16.12.2016 at 2:48 PM, m4squer4de said:

Ich habe den gleichen Aufbau

 

wie willst Du wissen, dass Du den gleichen Aufbau hast wie "Telcom_Admin", wenn er außer "hosted Swyx Lösung" gar nicht schreibt, was er für einen Aufbau hat? :-)

 

Für eine Lösung müsste man schon ein paar mehr Details wissen. Ich würde mal mit der Frage anfangen, wie Deine gehostete Swyx-Lösung mit Eurem lokalen Netzwerk verbunden ist (VPN-Typ? Wie viele IP-Adressen hat der Swyx-Server? ...)

Link to comment
Share on other sites


Sorry. Da hab ich mich ein wenig missverständlich ausgedrückt.

 

Tatsache ist, wir setzten neben der aktuellen SwyxIt Version die Hardwaretelefone SIEMENS optiPoint 420 Standard mit der Firmware V5 R6.1.0 in Deutsch ein. Diese werden in der SwyxWare Administration als L520s in den Eigenschaften des Benutzers angezeigt. Außerdem setzen wir ein lokal eingerichtetes SwyxWare 10.40.2513 auf einem MS Windows 2008R2 SP1 (aktueller Patchstand) ein, der auf einem ESX 5.0 Cluster virtualisiert ist.

 

Bei uns kommt es vermehrt (schon fast häufig) zu einem einseitigen Aufbau des Mediastreams, was nur in Verbindung mit o.g. Hardare Telefonen entsteht. Des weiteren Verlieren diese Hardware Telefone hin und wieder die Verbindung oder werden automatisch abgemeldet - was durch die erneute Eingabe des PINs ersichtlich wird.

 

Die Probleme entstehen bei externen als auch bei internen Gesprächen, was mich jedes Mediengateway nach extern ausschließen lässt. Aus den LOG Dateien konnte ich bisher nichts hilfreiches erkennen - bin aber da auch unsicher, wonach ich suchen sollte. Ein WireShark Capture war ebenso hilfreich - bisher.

 

Folgende Maßnahmen habe ich bisher ergriffen, was teilweise vermutlich nicht notwendig gewesen wäre:

- Automatisches Anmelden der Endgeräte deaktviert, da die MAC Adressen ungepflegt zu den Benutzern war.

- DNS auf Sauberkeit überprüft, was im Nachhinein unnötig war, da die Endgeräte nicht im DNS registriert sind.

- TLS global deaktiviert

 

Da ich bisher nur Lync Umgebungen betreut habe und ein Newbie in Sachen Swyx bin, stellen sich mir nun folgenden Fragen, zu denen ich Euch gerne um Eure Unterstützung bitte:

 

- Benötigen die Telefone einen DNS Eintrag?

- Ist es korrekt, dass die Telefone als L520s in SwyxWare geführt/erkannt werden?

- Welche Maßnahmen kann ich noch ergreifen, um das Probelm zu erkennen und zu beheben?

- Nach welchen Meldungen(?) sollte ich in welchen Logfiles(?) ausschau halten?

 

Fakt ist, dass dieses Problem bereits schonmal letztes Jahr bestand und sich von alleine wieder gelöst hat. Ich bin erst seit diesem Jahr im Unternehmen und werde nach meiner Expertise gefragt - doch leider stehe ich ein wenig doof da. Ich brauche Eure Hilfe - Bitte helft mir.

 

Ich freue mich über jeden konstruktiven Gedanken, sowie Austausch, der mir beim Lösen meines / unseren 100 Personen Unternehmens hilft.

 

Lieben Dank

Michael

Link to comment
Share on other sites


  • Most Valued User
1 hour ago, m4squer4de said:

Bei uns kommt es vermehrt (schon fast häufig) zu einem einseitigen Aufbau des Mediastreams,

 

womit Dein Problem ja auf den ersten Blick gar nichts mit dem ursprünglichen dieses Threads zu tun hat, denn da hatte ich das so verstanden, als ginge GENERELL kein Mediastreaming.

 

Nun denn:

 

1 hour ago, m4squer4de said:

was nur in Verbindung mit o.g. Hardare Telefonen entsteht

 

mit welchen Endgeräten tritt es denn NICHT auf? Sprich: Nutzen die anderen Nutzer andere Endgerätetypen (SwyxIt! als Softphone, SIP-Endgeräte, ...), oder habt Ihr auch funktionierende Tischtelefone neuerer Modellreihen (L6xx-/OpenStage xx HFA) im Einsatz? Da die Tisch-Systemtelefone von einem eigenständigen Dienst auf der Swyx gesteuert werden, wäre das zum Einkreisen schon mal hilfreich zu wissen, ob es wirklich an den alten Modellen liegt, oder ob Eure Swyx generell Probleme mit Tischtelefonen hat.

 

1 hour ago, m4squer4de said:

- Benötigen die Telefone einen DNS Eintrag?

 

nein.

1 hour ago, m4squer4de said:

Ist es korrekt, dass die Telefone als L520s in SwyxWare geführt/erkannt werden?

 

ja. Swyx hat bei de L4xx/L5xx-Systemtelefonen völlig eigene Produktbezeichnungen verwendet, die gar nichts mit den Siemens-Bezeichnungen zu tun hatten. Ich hab mir irgendwann mal eine Tabelle zusammengestellt, weil das für viele Kunden verwirrend ist: https://www.dt-internet.de/hilfe/detailansicht/uebersicht-der-systemtelefon-modelle-der-hostedpbx/ 

 

1 hour ago, m4squer4de said:

- Welche Maßnahmen kann ich noch ergreifen, um das Probelm zu erkennen und zu beheben?

 

Einkreise, ob das wirklich nur bestimmte Modelle betrifft (s.o., habt Ihr auch L6xx-Geräte im Einsatz?) oder vielleicht generell Systemtelefon-Support.

Ein Gerät mal auf Werkseinstellungen zurücksetzen und die IP gezielt in der SwyxPhone-Suche suchen und neu konfigurieren lassen.

Je nach dem, wie komplex Euer Netz aufgebaut ist, ggf. mal testweise ein Telefon "einfacher" an die Swyx anbinden (mit möglichst wenig Firewalls, Routern, Switchen, sonstwas dazwischen), um einzukreisen, ob das vielleicht stört.

 

1 hour ago, m4squer4de said:

Ich bin erst seit diesem Jahr im Unternehmen und werde nach meiner Expertise gefragt - doch leider stehe ich ein wenig doof da. Ich brauche Eure Hilfe - Bitte helft mir.

 

was spricht dagegen, Euren SwyxPartner zu fragen? 

Link to comment
Share on other sites


Hi zusammen :)

 

Sorry für meine verspätete Antwort :(

War gerade ein wenig sehr hektisch mit Studiumsabschluss, Support, usw...

 

Das Problem lag an den Firewall Rules beim Hoster. Da die Telefone noch zusätzliche Ports verwendet hatten, welche die L6xx Reihe nicht mehr braucht oder zumindest zusammen gefasst hat. :)

 

@m4squer4de vielleicht hilft Dir dies weiter... :)

 

Liebe Grüsse

aus der Sschweiz :)

Link to comment
Share on other sites


Vielen Dank(!) für Deine Unterstützung.

 

In der Tat betrifft es neben dem erwähntem Telefonmodell L520s auch noch das Modell L540 ist. Damit sind alle Hardwarephones betroffen. Alle weiteren Teilnehmer verwenden SwyxIt und haben keine Probleme beim Aufbau der Mediastreams.

 

Ich habe die Werkseinstellungen des Telefons wiederhergestellt und warte nun dass dieses im Scan der Swyx-Phone-Suche erkannt wird. Im Anschluss werde ich es konfigurieren. Jedoch werden sicherlich einige Gespräche nötig sein, um zu erkennen, ob ich das Problem im Anschluss immer noch habe, da diese nur spordisch an vielen Telefonen auftreten.

 

Eine Sache die jedoch für mich noch unangefasst ist, ist die Tatsache, dass die Telefone sich hin und wieder einfach von der Anlage abgemeldet haben bzw. wieder zur Eingabe der PIN auffrodern. Wohin könnte dies zusammenhängen und wie kann ich das ggf. analysieren?

 

Danke

Michael

 

 

Link to comment
Share on other sites


Vielen Dank(!) Telcom_Admin

Euer Setup unterscheidet sich von unserem Setup.

 

Während ihr eine SaaS Lösung verwendet, betreiben wir unsere Anlage zusammen mit allen Teilnehmern in einer Broadcastdomain mit deaktiviertem Domänen Firewall Profil, indem alle kommunizieren.

Link to comment
Share on other sites


  • Most Valued User
53 minutes ago, m4squer4de said:

Eine Sache die jedoch für mich noch unangefasst ist, ist die Tatsache, dass die Telefone sich hin und wieder einfach von der Anlage abgemeldet haben bzw. wieder zur Eingabe der PIN auffrodern

 

das klingt für mich danach, als ob es irgendwo auf der Strecke zwischen Telefon <-> SwyxPhoneManager (=der Dienst auf der Swyx, der diese Telefone ansteuert) <-> SwyxServer hakt. Ein Weg, das einzukreisen, wäre, testweise mal ein Telefon "möglichst nah an den SwyxServer" anstöpseln.

 

Wo genau, dazu müsste man ansonsten den Netzwerkaufbau kennen. Und wenn ich "man" schreibe, dann verweise ich nochmal auf einen SwyxPartner Deines Vertrauens als mögliche Option...

Link to comment
Share on other sites


Wie kommuniziert der SwyxPhoneManager mit den Hardphones? Es sind genau zwei Switche dazwischen - diese werden wir nun über die Feiertage neu starten ... Fehler weißen beide nicht auf.

 

Unser Swyx Partner ist bereits mit Swyx in Kontakt. Diese haben bisher nur verlangt die Telefone zu reseten, was wir eh schon gemacht hatten. Aus den Logs würden sie nichts lesen können, was auf diese Fehler hinweißt. Ich bin echt ein wenig enttäuscht, sollte doch zumindest die Auswirkungen erkennbar sein.

Link to comment
Share on other sites


Hallo,

 

ich misch mich mal eben ein.

 

Ich habe ähnliche Phänomene bei einem Kunden aber noch etwas komplexer als Deiner aber auch nur das Phänomen der einseiten Kommunikation.

Bei uns ist es so, dass es sich um einen Heim APL handelt der über VPN direkt angebunden ist.

Komisch ist bei uns, dass er mit fast allen sauber sprechen kann auf der Hauptseite aber nicht mit dem Chef (vielleicht gewollt, man weiß es nicht) und einer Mitarbeiterin.

 

Ich tendiere immer erst auf Firewall... 1. Server Firewall prüfen 2. H/W Firewall prüfen.

An den Telefonen kann man ja nicht viel falsch machen.

Aber das mit dem Port habe ich von einem Telekom Netphone Techniker bereits gehört, und zwar verwenden diese tollen Siemens/Unify Geräte von einer bestimmten Modellreiche nicht RTP als Audiostrom sonder ein anderes Protokoll (Irgendwas mit H... beginnend), vielleicht hilf das weiter, dass euch einfach noch Ports fehlen an die Ihr nicht gedacht habt, weil diese kein Mensch mehr braucht außer diese tollen IP-Telefone.

 

Naja meine Erfahrung ist, egal welcher Hersteller ob Swyx oder Mitel oder wer auch immer... Dieses Problem mit der einseitigen Kommunikation wird uns noch lange begleiten und das eine oder Andere graue Haar wachsen lassen. :-/

 

 

Viele Grüße und viel Erfolg

Frank

 

P.S.: Schreib bitte was es bei dir war, wir zähren von solchen Dingen beim nächsten Fehler.

P.P.S.: Du hast geschrieben dass auf Domänen Ebene die Firewall der Server aus ist... mal so btw wen seine geistreiche Idee war denn das? :D Fakt ist das macht man nicht. Aber gut... worauf ich hinaus will ist, dass die Windowsfirewall nicht gleich aus ist, auch wenn Sie das zu scheinen glaubt... Also Tipp meinerseits --> GPO dafür abändern bzw. eine eigene OU für TK-Server im AD erstellen und den Swyx Server da rein legen, anschließend es so hindeickseln, dass der Swyx Server diese Firewall Off Policy nicht abbekommt (ich hoffe ihr arbeitet mit dedizierten GPO Objekten) und einen GPUpdate /force auf beiden Seiten machen (Und vorher die MMC der GPO Konsole schließen, sonst ist nicht mit speichern).

So und dann gehst du bitte in die Windowsfirewall und machst es richtig und nimmst dort dein internes Domänen Netz raus, so dass der SwyxServer in beide Richtungen für das Subnetz im Zugriff steht. Du kannst auch gerne es Portbasiert machen aber würde ich hier vorerst einmal mit der Brechstange reinhauen um zu sehen ob es Dein Problem löst.

Ich denke dass wird es. ;-)

 

Pfüürti und viel Erfolg!

Link to comment
Share on other sites


  • Most Valued User
6 minutes ago, fkg said:

und zwar verwenden diese tollen Siemens/Unify Geräte von einer bestimmten Modellreiche nicht RTP als Audiostrom sonder ein anderes Protokoll (Irgendwas mit H... beginnend), (..) weil diese kein Mensch mehr braucht außer diese tollen IP-Telefone.

 

 

*hust* wenn man vor'm Konfigurieren der Firewall mal nachdenkt, was man alles braucht:

http://www.swyxdownload.com/download/kb4635_SwyxWare_Ports_2015_de.pdf

dann braucht man danach nicht despektierlich über Geräte reden, die mehr brauchen als das, was man man Gefühl freigegeben hat...

Link to comment
Share on other sites


  • Most Valued User

Ich hatte vor kurzem erst wieder....nein wir blockieren nichts und nein es ist nichts konfiguriert.

Aber leider hat die Deep Packt Inspection mir ab und an dennoch ein Paket weggeschnappt.

 

Hier bringt Traceing und Wireshark Licht ins Dunkle. 

Solange der Fehler reproduziert werden kann ist er doch in akzeptabler Zeit auffindbar.

Link to comment
Share on other sites


22 hours ago, jodost said:

 

*hust* wenn man vor'm Konfigurieren der Firewall mal nachdenkt, was man alles braucht:

http://www.swyxdownload.com/download/kb4635_SwyxWare_Ports_2015_de.pdf

dann braucht man danach nicht despektierlich über Geräte reden, die mehr brauchen als das, was man man Gefühl freigegeben hat...

 

Danke für den Link.

In der Regel hast du Recht, aber wenn du eine bestehende Landschaft übernimmst, die auch noch von der Telekom aufgesetzt ist... schaut die Welt anders aus, als wenn man etwas selbst von A-Z unter Kontrolle hat.

Aber ich glaube es war: CallControl H.323/H.225 TCP , TLS 1300, 1720, 1721

und das hat nichts direkt mit der Sprache zu tun.

 

@srom Klar das ist dann letztendlich der Weg zum Ziel. Das zeigt wieder mal, dass es für die Telefonie doch Sinn macht ein eigenes Subnetz auf zu ziehen mit eigenen Firewall Policys, dann kann man wenigstens wunderbar auf der Firewall tracen.

 
 

 
Link to comment
Share on other sites


@fkg @srom Danke(!) Frank für Deine Überlegungen.

 

Da wir aktuell eben KEINE Firewalls in dieser eben genutzten Broadcast Domain einsetzten, möchte ich diese Grundsatzdiskussion beiseite legen. Da es "hin und wieder" und NUR mit den SIEMENS Telefonen zu einseitigen Verbindungsaufbauten des MediaStreams kommt, lassen mich an lokale Probleme auf den Swyx Server tippen.

 

- Kommunizieren die SwyxPhone Clients über andere Ports als die SwyxIi Clients?

- Lässt sich die Auslastung auf dem SwyxPhoneManager Dienst messen?

 

Laut dem Swyx Partner und angeblich Swyx direkt wäre auf dem PhoneManager kein Problem festzustellen. Ich zweifle so langsam an so mancher Kompetenz und würde mir so gerne eigene in diesem Produkt aneignen.

 

@jodost Danke für das Dokument. Ich werde mir ansehen, ob ggf. ein anderer Dienst einen der notwendigen Ports verwendet.

 

Ich wünsche euch allen Frohe Weihnachtsfeiertage und danke Euch für Eure Unterstützung.

 

Link to comment
Share on other sites


  • Most Valued User
1 hour ago, m4squer4de said:

- Kommunizieren die SwyxPhone Clients über andere Ports als die SwyxIi Clients?

- Lässt sich die Auslastung auf dem SwyxPhoneManager Dienst messen?

 

ja, SwyxPhone-Telefone haben salopp gesagt technisch gar nichts mit den SwyxIt!-Clients zu tun. 

 

Ist ein komplett eigener Dienst, den Du theoretisch auch abgesetzt auf einem anderen Server laufen lassen könntest.

 

1 hour ago, m4squer4de said:

Ich zweifle so langsam an so mancher Kompetenz und würde mir so gerne eigene in diesem Produkt aneignen

 

eigenes KnowHow für die eigene IT schadet nie. Direkt mit so einem so speziellen Problem anzufangen ist aber vielleicht eine Hausnummer zu groß.Zumal der Informationsfluss recht schwierig ist (mein Gefühl lautet weiterhin Netzwerk [einschl. Routing, VLAN, QoS, Firewall] und nicht "Software-Problem" auf dem SwyxServer, aber um das wirklich einkreisen zu können, müsste man den Aufbau erstmal kennen)

Link to comment
Share on other sites


6 hours ago, jodost said:

 

...mein Gefühl lautet weiterhin Netzwerk [einschl. Routing, VLAN, QoS, Firewall] und nicht "Software-Problem" auf dem SwyxServer, aber um das wirklich einkreisen zu können, müsste man den Aufbau erstmal kennen)

 

Ganz ohne VLAN, QoS, Firewall, geschweige eines Routings kommunizieren die Telefone und SwyxIt Clients mit ihrem Swyx Server. Alles in einem Netz / einer Broadcast Domain. Die beiden HPE PoE Switche wurden ebenfalls neu gestartet und auch die Verkabelung wäre undenkbar. Es könnte noch eine VMware ESX vSwitch Thematik oder eben der virtualisierte Swyx Server sein.

 

Jetzt werde ich erst einmal meinen Kopf versuchen über die Feiertage "rein" zu bekommen und meine Kollegen weiter denken zu lassen.

 

Ich bin jedoch für JEDE Idee oder Denkanstoß zu haben. ;-) Danke.

 

Link to comment
Share on other sites


  • Most Valued User

Du kannst probehalber nur den reinen SwyxPhoneMgr auf einem anderen Server installieren, im registryKey IpPbxServer die IP vom SWYX Server eintragen (damit die sich verbinden), fertig -> wenn es damit stabil Läuft weißt du dass du den Fehler auf dem eigentlichen Server suchen musst

Link to comment
Share on other sites


  • 3 weeks later...

Hallo Zusammen

 

Nach eingigen Recherchen in Kontakt mit dem Swyx Partner und Swyx hat sich anscheined ergeben , dass die eingesetzten Modelle L520s und L540 den MediaStream fehlerhaft aushandeln. Nun eingesetzte Systeme OpenStage 40 (L640) weißen keinerlei Probleme bisher auf (seit 2 Tagen). Ich warte nun auf eine offizielle Stellungnahme und eine entsprechende Anpassung der Kompatibilitätsliste, da ich vermute das die Entwickler keinen Aufwand mehr aufnehmen, ggf. damit verbundene Probleme zu beheben.

 

Sobald ich was genaues und offiziell bestätigtes erfahren habe, lasse ich es Euch wissen.

 

LG
Michael

Link to comment
Share on other sites


Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and have taken note of our Privacy Policy.
We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.