redline

Das Problem welches ich dabei habe ist, dass wir Umgebungen mit mehreren Standorten und unterschiedlichen Netzwerken haben. Ich müsste dort also alle IP-Netze eintragen, bzw. immer wieder das Netz, wo gerade neue Telefone geliefert wurden und dann den Broadcast starten (ist der eigentlich netzwerklastig?). Wenn wir die Telefone vorher bei uns im Labor hätten, könnten wir diese fix manuell vorbereiten, zuschicken und alles passt. Grundsätzlich: GÄBE es denn einen Weg die manuell zu konfigurieren? Außerdem: Ich komme nach der automatischen Konfiguration zwar noch auf das Webinterface, kann dort aber nix mehr ändern.. Ist das gewollt?

OK... Bin wieder weiter... Nachdem ich mal das Firmware Verzeichnis des FTP Servers aktualisiert habe, haben beide Geräte sich direkt die neue Firmware gezogen und installiert. Nach zwei Neustarts werde ich jetzt direkt nach PIN gefragt. Nach Eingabe erhalte ich nun die Info "Notbetrieb"... Das habe ich bereits mehrfach gelesen...... EDIT: OK - NTP. Irgendwie war das mit der alten Generation alles einfacher... Ich komme aber weiter! Herzlichen Dank!

Also mein jetziges Testsystem ist eine NetPhone Anlage in der Version 12.11.16731 Unsere Kunden setzen aber auch SwyxWare ein. Die SwyxPhone Serversuche habe ich erhlicher Weise noch nie genutzt. 🙂 Der Scan läuft jetzt. Zwischenzeitlich ist das L64 einmal neugestartet (ob im Zusammenhang - kA) und das L62 ist weiterhin unbeeindruckt... Muss ich jetzt eine Stunde warten, bis der Scan vorbei ist und kann dann was genau? Ist das die eigentlich offizielle Variante? Da finde ich meine manuelle Konfiguration eleganter.

Update: ich habe mich gerade erschrocken, weil das Telefon bei einem eingehenden Anruf geklingelt hat. Also eine Verbindung habe ich jetzt scheinbar. Zuletzt habe ich bei meinem Swyx-Account die SIP Anmeldung aktiviert, wie ich es sonst nur für Drittanbieter tun würde... Auf dem Display lese ich auch noch "Limited service (NT)" So ganz stimmt das noch nicht....

Hi, ich habe hier ein L62 und L64 zu Testzwecken. Seit Jahren setzen wir erfolgreich L615 und L640 Telefone ein, aber da diese nun eol sind, müssen wir umstellen. Ich schaffe es aber einfach nicht diese am Server zu registrieren... Leider sind weder in den Anleitungen und KB Artikel von Swyx, noch auf den Seiten von unify konkrete Informationen zu finden. Bei den L615/L640 war es lediglich nötig im Webinterface unter System - Gateway die Server IP und Subscriber Number/Passwort anzugeben. Diesen Punkt gibt es jetzt nicht mehr stattdessen sehe ich Registration. Aber egal was ich versuche, die Telefone verbinden sich einfach nicht. Ich erhalte unterschiedliche Fehlermeldungen von RN2 bis RA2 je nachdem welche Kombinationen ich probiere. Ganz konkret gefragt: Was sind die Mindesteinstellungen, die ich machen muss um eine Verbindung zu bekommen? Falls relevant: FW ist V1R3.8.0 Danke! EDIT: Sorry, sehe gerade ich bin versehentlich im englischen Abteil gelandet. Vielleicht könnte jemand verschieben?

Hab zwar vorher gegooglet und nichts gefunden, ein Blick in die Anleitung hat mir meine Frage aber quasi beantwortet: Das sollte aber angepasst werden um Verwirrung zu vermeiden. Auch die Info mit dem Neustart wäre relativ wichtig. 🙂

Hi, ich würde gerne die hier genannten Registry-Keys für die Zuweisung der Schnittstellen für SIP-Registrierung beim Provider und lokalem Interface nutzen. Allerdings glaube ich, es hat sich hier ein Fehler eingeschlichen. Die Typen werden als REG_DWORD bezeichnet, bei diesem Typ ist die Eingabe einer IP-Adresse aber nicht möglich. Jetzt frage ich mich, war eigentlich eine Zeichenfolge gemeint, oder soll der Wert keine IP-Adresse, sondern eher interne Schnittstellenbezeichnung oder ähnliches sein. Weiß jemand Rat? Danke und viele Grüße

Stimmt, so könnte man es machen, erfordert natürlich je nach Benutzeranzahl (im konkreten Fall >250) sehr viel Aufwand.... Ich bespreche das! Sollten weitere Ideen eintreffen oder Swyx aktiv mitlesen und ein Feature-Request suchen: 😉 Herzlichen Dank srom!

Das hört sich prinzipiell interessant an, aber im HowTo von Tom steht: "Open Call Routing Manager of the user you want a Night Switch enabled call routing script for" Ich will es ja nicht für einen User, sondern für den gesamten Standort. Letztendlich muss ich die Variable ja auslesen und das geht soweit ich das verstehe nur pro User (sprich Rufnummer) und nicht pro Standort (Rufnummern-Block).

Ok, hatte gehofft es gibt bereits eine Lösung für mein Szenario, ich kenne sie bloß nicht. 🙂 Ich möchte die Umleitung nicht automatisiert scharf schalten, wir benötigen immer den Auftrag des Kunden, daher fällt der Task weg. Auch möchte ich bestenfalls vermeiden sämtliche konfigurierten Umleitungen der Anwender zu überschreiben. Gut, das ist ein Luxusproblem, aber viele sind daran gewöhnt einfach die letzte Umleitung zu aktivieren. srom, kannst du deine Idee nochmal weiter ausführen? Habe es noch nicht ganz nachvollzogen. Perfekt wäre es, wenn es die Bedingung "Anruf an Standort X" geben würde. So könnte ich den betroffenen Standort angeben und direkt die Umleitung aktivieren.

Der Titel klingt etwas merkwürdig, aber ich finde gerade keine bessere Beschreibung. Ich möchte erreichen, auf Zuruf eine vorgfertigte Ansage scharf schalten zu können. Diese Ansage soll für alle Nebenstellen greifen, die einem bestimmten Standort zugewiesen sind. Anschließend soll das Gespräch beendet bzw. auf Mailbox weitergeleitet werden. Die genauen Einzelheiten stehen noch nicht fest, sind auch nicht teil des Problems -> typisches CallRouting halt. Aber wie erreiche ich das? Spontan habe ich an eine PreProcessingRule gedacht, allerdings habe ich bisher nicht damit gearbeitet und weiß nicht, ob dies der richtige Weg ist. Nochmal mein Ziel anders formuliert: -Wir bekommen die Info, dass ein externer Standort offline ist -Auf dem zentralen Swyx-System soll nun eine vorgefertigte Regel aktiviert werden* -Der Anrufer erhält die Meldung, dass es derzeit technische Probleme gibt etc. pp. -Kommt der Standort wieder online, wird diese Regel deaktiviert *wie das genau aktiviert wird, weiß ich nicht, bzw. ist irrelevant - kann auch technisch kompliziert durch uns erfolgen. Problem: Es gibt zwar zentrale Rufnummern für diese Standorte, allerdings werden teilweise auch Durchwahlen rausgegeben. Für alle diese Fälle manuelle Regeln zu aktivieren, wäre zu viel Aufwand, daher soll die Ansage ertönen, egal welcher Benutzer innerhalb des Standortes kontaktiert wird. Vielleicht hat jemand eine Idee? Vielen Dank!

Komisch, zumindest war das Problem bekannt, man musste nicht suchen und wusste direkt die Ursache. Dann scheint es vielleicht nur bei einer bestimmten Konstellation aufzutreten.

srom, danke für die Antwort! 😉 Würdest du mir noch verraten, wie du deine Einstellungen dann gesetzt hast? Sowohl im SIP-Gateway (Lancom <--> Swyx) sofern du so eine Konstellation im Einsatz hast, als auch die entsprechende Einstellung im SBC selbst (Lancom T.38 Transkodierung). Nochmals Danke!

Das Routing schließe ich jetzt mal aus, wenn sich der Großteil hören kann. Es betrifft auch nur den einen bestimmten User? Egal wen dieser vom anderen Standort anruft, man hört sich nicht? Gibt es am Arbeitsplatz vom dem betroffenen User irgendeine Besonderheit? Ein VLAN, ein anderer Switch, andere Anbindung.... irgendwie sowas? Welcher Telefonclient wird überhaupt verwendet? Da du von Neuinstalltion sprichst nehme ich an die Telefonie läuft nur über SwyxIT und Headset? Headset bzw. die Einstellungen überprüft?

Ich weiß, das wird eine Unterhaltung mit mir selbst, aber anhand der steigenden Aufrufe weiß ich, dass es zumindest stille Mitleser gibt. Je länger man in dieses Thema recherchiert, desto häufiger findet man Widersprüche. Die Telekom selbst behauptet in ihren Dokumenten, dass sie T.38 sehr wohl unterstützen bzw. einfach durchleiten sofern sich beide Teilnehmer darauf geeignet haben. Quelle: Telekom Tipps und Tricks zum Faxversand Wenn die heutige Rückinfo eines Kunden stimmt, gibt es sogar zwischen zwei Swyxservern (beide über Telekom SIP Trunk mit Lancom) bei Verwendung des FAX Clients Probleme. Angeblich werden mehrseitige Dokumente erst nach dem dritten Versuch vollständig übertragen. Ich weiß nicht, ob es am Lancom, der Telekom oder meiner Swyx-Konfiguration liegt. 😞

Um diesen Vorgang abzuschließen und eine Lösung für andere Betroffene zu haben. Es handelt sich in der Tat um einen Bug! Um die Funktionscodes wieder funktionsfähig zu bekommen, müssen innerhalb der IpPbx Datenbank unter Programmierbarkeit - Gespeicherte Prozeduren folgende Tabellen geändert werden: dbo.swpbx_SetDefaultForwardingEnabled dbo.swpbx_SetDefaultForwardingNumber dbo.swpbx_SetVoiceMailFile dbo.swpbx_SetVoiceMailRecLen Es wurde jeweils über Rechtsklick -> "Skript für gespeicherte Prozeduren als" - ALTER in - Neue Abfrage der Wert SET QUOTED_IDENTIFIER von OFF auf ON gestellt Anschließend waren die Funktionscodes wieder möglich. Thema somit erledigt. 🙂

Ich habe hier nochmal ein sehr spannendes Dokument, welches meinen Wunsch nach einem best-practise eigentlich perfekt wieder gibt: EMPFEHLUNG FÜR DEN FAX-BETRIEB IN VOIP-NETZEN Aber zum einen ist das jetzt nicht auf mein Szenario spezialisiert und zum anderen ist das Dokument von 2017 und widerspricht in einigen Punkten die Empfehlung der Telekom. Ich brauche daher mehr Meinungen. Das Dokument empfiehlt mehrfach das T.38 Protokoll. Auch Swyx schreibt in seinem Dokument zu Anbindung des Lancom "Die FAX-Übertragung via T.38 sollte zunächst aktiviert bleiben. Falls hier eine Deaktivierung erforderlich sein sollte, weil ein Provider kein T.38 unterstützt, ist dies in den jeweiligen Kapiteln zu den einzelnen Providern erwähnt." Nun ist es so, dass die Telekom da scheinbar ein Strich durch die Rechnung macht, wenn man sich dieses Dokument anschaut Telekom All-IP Hier schreibt Swyx "Der VoiceData Anschluss unterstützt nicht das T.38 Protokoll, welches im IP Umfeld für die FAX Übertragung empfohlen wird. Die alternative FAX Übertragung mit G711 wird ab der SwyxWare2015R3 unterstützt.Um den Versuch zu unterbinden, auf T.38 umzuschalten, muss im bei den Codec-Eigenschaften T.38 als unterstützer Codec entfernt werden. Hinweis: Bei einer FAX Übertragung über G.711 ist die Qualität und Stabilität der Übertra-gung sehr stark von der Ende-zu-Ende Netzwerkverbindung abhängig. Da gegenüber dem T.38 Protokoll die Kontroll-und Redundanzinformationen fehlen, kann insbesondere die Übertragung von großen Dokumenten scheitern." Heißt das, die Telekom macht mir den Traum vom fehlerfreien faxen zu Nichte? Welche Trunk Konfiguration ist eher zu empfehlen Ich nehme an der Haken bei "Umschalten auf T.38 durch den Sender verhindern" sollte bestenfalls aktiviert werden? Auch die T38 Transkodierung im Lancom sollte (aufgrund des Telekom Anschlusses) auf "Niemals" gestellt werden? Danke und beste Grüße

Hallo, seit Umstellung auf All-IP nimmt die Fehlerquote beim FAX-Versand rasant zu. Ich weiß, niemand mag FAX, aber es ist leider nach wie vor ein wichtiges Thema. Ich kenne den Artikel Maßnahmen zur Verbesserung der Erfolgsquote beim Faxversand mit SwyxFax über SIP-Provider und habe bereits die QoS Einstellungen auf dem Swyx-Server hinterlegt und via Wireshark überprüft. Gehen wir außerdem davon aus, dass das Netzwerk schnell genug ist und es hier zu keinen weiteren Jitter-Problemen oder Ähnlich kommt. Wie sieht die weitere Optimierung aus? Den FAX-Kanal habe ich bereits auf eine Baudrate von 9600 reduziert. Im SIP-Gateway Trunk sind nur G.722 und G.711a (bzw. Zwischenfrage, ein anderer Standort hat kein G.722 sondern nur G711a und µ -besser?) aktiviert und "T.38 aus erster Aushandlung entfernen" ist aktiviert Sind diese Einstellungen bisher empfehlenswert und wie sollte in meinem Szenario jetzt bestenfalls der Lancom konfiguriert werden? Relevant ist der Punkt unter Voice Call Manager -> Erweitert -> T.38 Transkodierung Swyx und Lancom sollten sich ja eigentlich einig sein, aber die Gegenseite hat ja auch ein Wörtchen mitzureden. Im Handbuch für die Anbindung des Lancom als SBC ist eine alte FW zu sehen und es ist lediglich der Haken bei "FAX-Übertragung erkennen und nach Möglichkeit T.38 verwenden" zu setzen. Dieser Wortlaut klingt natürlich nach einer Universallösung. Heutzutage habe ich aber nur die Auswahl zwischen "Niemals", "immer" und "Nur bei ISDN+Analog". Vielleicht hat hier jemand eine Konfiguration die (fast) immer erfolgreich ist? Danke und viele Grüße

Hallo srom, vielen Dank für deine Antwort und dein Angebot! Wir konnten das Problem jetzt lösen. Scheinbar hatte der Test-Routeneintrag irgendeinen Fehler o.Ä. Wir haben jetzt eine Universal-Route gesetzt, indem wir komplett 192.168.0.0/16 an unser Gateway weiterleiten. Dies hat das Problem behoben und bestätigt somit final, dass RTP zwischen Lancom und Endgerät stattfindet. Es ist erschreckend, wie eine so banale Ursache einen Ausfall von fast einer Woche verursacht hat und niemand Offizielles uns die entscheidenden Hinweis geben konnte. Die Struktur war eigentlich klar. Nochmals vielen Dank und beste Grüße!

Hallo Zusammen, ich war mir vorerst unsicher, ob dieses Unterforum das richtige ist, dann sah ich die ähnlichen Themen und denke ich reihe mich ebenfalls mit ein. Letzten Freitag wurde ein PMX Anschluss auf einen SIP Trunk umgestellt. Da der Serverstandort mehrere WAN Anbindungen hat und die Telefonie unter allen Umständen eine eigene Leitung erhalten soll, wurde sich dazu entschlossen den Lancom Router die SIP Einwahl durchführen zu lassen (SBC) und einfach auf dem Swyx ein SIP-Gateway bereitzustellen. Selbes Szenario wurde vor einigen Wochen bereits bei einem anderen (kleineren) Standort durchgeführt. Leider ging hier nun einiges schief und der Kunde hat seit Freitag das Problem, dass nur einseitig Sprache übertragen wird (teilweise sogar gar keine Kommunikation möglich ist). Da wir ein SLA von 4h auf Anschluss als auch Lancom haben, wurde die Telekom direkt aktiv und hat versucht den Fehler zu beheben. Bis heute erfolglos. Parallel habe ich natürlich ebenfalls recherchiert und herausgefunden, dass dieses Szenario gar nicht so untypisch ist: https://service.swyx.net/hc/de/community/posts/360004237700-Telekom-SIP-Trunk-Lancom-SBC-Einseitige-Audio-Übertragung-bzw-Abbrüche-nach-35-Sekunden Es gibt noch weitere ungelöste Threads sowohl im Lancom-Forum als auch anderen Seiten. Mir ist sofort aufgefallen, dass der Unterschied zwischen dem Standort, bei welchem die Umstellung geklappt hat und dem jetzigen. die angebundenen Standorte via VPN sind. Beim jetzigen sind dutzende Einrichtungen per IPSec angebunden und greifen auf den Server in der Zentrale zu. Die Zentrale selbst kann normal telefonieren. Mit diesen Informationen habe ich den Lancom Support gefüttert, welcher jedoch trotzdem keine Lösung wusste und das Thema an die Netphone Abteilung weitergegeben hat. Hier habe ich nun eine Info erhalten die ich gerne von euch verifizieren lassen würde. Es wurde gesagt, dass der Swyx-Server in Zeiten von SIP nur noch den Verbindungsaufbau übernimmt und dann direkt vermittelt - also quasi exakt wie bei der internen Telefonie, Endgerät und Endgerät werden verbunden und anschließend läuft die Kommunikation nur noch über das Netzwerk. Ist diese Aussage korrekt? Ich kann mir kaum vorstellen, dass das Endgerät nach dem Verbindungsaufbau direkt mit dem Lancom (bzw. sogar darüber hinweg?) kommuniziert?! Nichtsdestotrotz haben wir einen Versuch gestartet und die lokalen Netze der VPN-Standorte auf dem Lancom bekannt gemacht, bzw. an ein entsprechendes, internes Gateway weitergeleitet. Auch anschließend war die Telefonie nicht korrekt möglich. Nun behauptet man jedoch das Firewalls und Co die Pakete blocken würden (es ist kein entsprechender Filter aktiv). Ich muss daher klären, ob wirklich die VPN-Netze bekannt gemacht werden müssen (der Swyxserver kennt diese alle selbstverständlich). Habt ihr andere Ideen, woran es liegen könnte? Mir kommen spontan noch Codecs in den Sinn, aber es ist ausschließlich G.711a und G.711µ für den Trunk aktiviert und laut Lancom wird da auch nichts verstellt. Ich hoffe auf eure Unterstützung, Danke!

Ok, es scheint ein generelles Problem zu sein. Habe nun die Bestätigung aus einer anderen -am selben Server angeschlossenen- Einrichtung. Der Bestätigungston erfolgt nach Eingabe der letzten Raute, die sofortige Umleitung wird aber nicht aktiv. Ich brauche irgendeinen Ansatzpunkt. Welche Systeme sind zuständig für die Funktionscodes? Vielleicht hat sich ein Dienst aufgehängt oder sowas, wobei der ganze Server auch schon neugestartet wurde. Vielleicht weiß jemand noch was? Danke!

Zwischenzeitlich hat der Kunde bestätigt, dass es nicht am Gerät selbst liegt. Auch andere Telefone vor Ort haben dieses Problem. Aber weitere Rückmeldungen von Einrichtungen auf dem selben Server habe ich noch nicht erhalten. Das ist doch total verrückt. Ich hoffe das ist ein Anwenderfehler, dann muss ich mir das aber tatsächlich vor Ort anschauen.

Hallo Zusammen, habe hier gerade einen kuriosen Fall. Letzte Woche wurde das aktuellste Update für die 11er Version eingespielt und Anfang der Woche kam die Rückmeldung das die sofortige Umleitung -welche per Namenstaste konfiguriert wurde- nicht mehr funktioniert. Auch das manuelle wählen von ##20DURCHWAHL# scheint nicht zu funktionieren, die Umleitung wird nicht aktiv. Ich habe derzeit leider keine Möglichkeit das ganze intensiver zu testen. Einen Bug in der Version schließe ich einfach mal aus, das Update ist ja nicht brandneu und das wäre bereits unzähligen Nutzern aufgefallen. Aber vielleicht habt ihr eine Idee, wie es zu diesem Problemen kommen konnte bzw. wie ich es behebe? Danke für alle Anregungen. Viele Grüße