Jump to content

SBauhaus

Member
  • Content Count

    16
  • Joined

  • Last visited

Community Reputation

0 Neutral

About SBauhaus

  • Rank
    Member
  1. Hallo rgm, welches Providerprofil nutzt du denn? Gibt es eines, welches zu deinem gebuchten SIP-Produkt passt? Ich würde in solchen Fällen einfach mal die Verschlüsselung deaktivieren (wenn vom Provider unterstützt) und Wireshark auf dem Swyx-Server mitlaufen lassen. Anschließend den SIP-Anzeigefilter von Wireshark aktivieren und du siehst meistens schon ziemlich genau, was vom "gegnerischen" Server gemeldet wird. Sebastian
  2. Hallo Arthur, das Forum steht (soweit ich weiß) in keiner Verbindung zum Unternehmen Enreach/Swyx. Das sieht man auch am Slogan ganz oben auf der Seite. Ich würde mich in deinem Fall an deinen zuständigen Systembetreuer/Händler wenden, der euren Swyx-Server installiert hat. Dieser kann bei Probleme wiederum Tickets direkt bei Swyx aufmachen. Inhaltlich kann ich hier aktuell nicht viel beitragen, da ich die App nur unter iOS nutze. Die meisten Probleme (Gesprächsabbruch, einseitiger Ton, etc.) ließen sich bei uns durch eine korrekte Einrichtung des Servers beheben. Ich gebe dir aber Recht, dass die App in Sachen Bedienbarkeit unbedingt weiter verbessert gehört. LG Sebastian
  3. Update: Die Probleme treten nicht mehr auf, seitdem wir nur noch einen Trunk im System haben (der Test-Trunk wurde entfernt). Ggf. hat das mit der Media Bridge zu tun, die wird ja soweit ich weiß deaktiviert, wenn nur ein Trunk im System vorhanden ist. Ich werde das nicht weiter verfolgen
  4. Habe es soeben gelöst - manchmal sollte man die technische Spezifikation auch lesen, die der SIP-Anbieter mitschickt In meinem Fall (und vermutlich bei jedem Anbieter) wird der Faxverkehr nicht mehr per T38 sondern im normalen Sprachcodec G711 übertragen. Ich habe in meinen Audiocodes-Gateways daher noch das Verfahren von "T38 Relay" auf "G711 Transport" umstellen müssen. Falls es noch jemand braucht: - Im Audiocodes Webinterface einloggen - Bereich "Configuration" -> "VoIP" -> "SIP Definitions" -> Generel Parameters - Wert "Fax Signaling Method" von "T.38 Relay" auf "G.711 Transport" ändern --> Submit - Bereich "Configuration" -> "VoIP" -> "Coders and Profiles" -> "IP Profile Settings" - Wert "Fax Signaling Method" von "T.38 Relay" auf "G.711 Transport" ändern --> Submit - "Burn" zum dauerhaften Speichern der Einstellungen
  5. Hallo zusammen, wir haben heute mehr oder weniger erfolgreich von einem ISDN-Anschluss (angebunden per SIP-Gateway an Swyx) auf einen SIP-Anschluss gewechselt. Es tummeln sich (leider) noch einige Faxgeräte bei uns im Unternehmen, diese sind per Audiocodes MP 112 Meda Gateways angebunden. Wenn wir nun z.B. ein Fax empfangen, sehe ich per Wireshark ein INVITE, dann ein ACK, danach kommt aber irgendwann die SIP-Nachricht "488 Not Acceptable Here". Nun bin ich bei SIP nicht allzusehr bewandert, bei FAX-Technik hört es bei mir leider ganz auf. Hat jemand eine Idee, an welcher Stelle ich meine Fehlersuche beginnen sollte? MfG Sebastian
  6. Letztendlich habe ich es nun so gelöst. Diesen Weg hatte ich ganz zu Beginn getestet, aber verworfen, weil dann noch nicht einmal ein Login möglich war. Hier war der Auslöser jedoch eine falsche Einstellung bzgl. NAT Reflection. Nachdem ich diese von PureNAT auf NAT + Proxy umgestellt habe, läuft es intern auch mit dem beidseitigem Media-Streaming. Ich frage mich zwar noch immer, warum gerade die interne Anbindung so ein Krampf ist, werde mich jetzt aber nicht weiter damit befassen. Vielen Dank für die Hilfe! LG Sebastian
  7. So, ich habe nun auf Swyx 13.05 aktualisiert, leider ohne Erfolg. Ich habe noch einmal ganz genau per Wireshark verfolgt: Am Swyx-Server kommt sowohl ein- als auch ausgehender Ton an - leider werden die beiden Interfaces jedoch nicht miteinander verbunden. Getestet wurde immer per Echo-Service (+49 89 721010 99701) Heißt: Wenn ich die Pakete an der LAN-Schnittstelle mitschneide (an der Swyx Mobile im internen Modus ankommt), höre ich meine Stimme, jedoch nichts vom Echo-Dienst. Wenn ich Pakete an der DMZ-Schnittstelle mitschneide (also die NIC, die mit dem SIP-Provider verbunden ist), höre ich den Ton vom Echo-Server (NUR die Initialansage, kein echo meiner Stimme), allerdings nicht meinen ausgehenden Media-Stream. Heißt für mich: Firewalltechnisch ist alles gut (der Swyx-Server "hört" ja beide Seiten), das Mediastreaming klappt jedoch nicht über mehrere NICs hinweg. Dann bleibt für mich nur das Umbiegen des internen Traffics, sodass ich auch im lokalen WLAN an der DMZ-Schnittstelle ankomme, oder hat noch jemand einen anderen Ansatz für mich? LG Sebastian
  8. Hallo, ich schon wieder Mein vom SIP-Provider zugewiesener Test-Trunk funktioniert an sich wunderbar, ich habe nur ein "Problem" festgestellt: Bei ausgehenden Anrufen habe ich zwei Freizeichen, die leicht voneinander versetzt ertönen. Nimmt der Gesprächspartner das Gespräch an, verstummen beide Freizeichen ordnungsgemäß. Hat jemand eine Idee, an welcher Stelle ich ansetzen kann? Vielen Dank vorab! Sebastian
  9. Habe das gerade bei meinen Test-Trunks ausprobiert, funktioniert wunderbar! Dann kann ja nichts mehr schief gehen, vielen Dank! LG Sebastian
  10. Hallo zusammen, wir setzen aktuell einen ISDN-Anschluss mit einem 100er-Rufnummernblock (00-99) ein, den wir per SIP-Gateway in Swyx eingebunden haben. Nun wechseln wir von ISDN auf SIP und der Provider legt den Rufnummernblock zum Stichtag um. Mein Problem: Der Rufnummernblock ist aktuell einem SIP-Gateway-Trunk zugeordnet. Wie bekomme ich den Block von diesem SIP-Gateway zum SIP-Trunk? Ich habe das mal an einem fiktiven Trunk getestet: Wird ein Block entfernt, wird per Meldung angekündigt, dass dann alle externen Zuordnungen von den Benutzern entfernt wird - und so ist es dann auch. Wie migriere ich einen Rufnummernblock, ohne jede externe Rufnummer erneut zuzuordnen? Danke! Sebastian
  11. Ich habe es mal getestet. Wenn ich LocalIpAddress weglasse, funktioniert tatsächlich nicht mehr viel - insbesondere SwyxIt! kann sich nicht mehr verbinden. Das Weglassen von SipLocalInterface hat (zumindest in meinem Szenario) keine negativen Auswirkungen - allerlings leider auch keine positiven. Sobald ich mich mit SwyxMobile intern verbinde, habe ich kein MediaStreaming mehr. Kommt mir langsam komisch vor, daher werde ich am Wochenende nun erst einmal auf die neuste 12er-Version aktualisieren. Ich werde dann hier nochmal reinschreiben, was sich getan hat.
  12. Hallo jodost, dass es grundsätzlich funktioniert, erleichtert mich schon einmal Wurden in den von dir genannten Szenarien dann auch die RegKeys SipLocalInterface und LocalIpAddress verwendet, oder kann ich die auch weglassen? Ich würde eigentlich schon gern den internen Modus nutzen, da ich so den Weg durch die äußere Firewallschicht sparen kann. Ich habe dem Swyx-Server nun testweise eine NIC direkt im WLAN-Netz gegeben, somit ist nun zwischen iPhone und Swyx Server überhaupt keine Firewall (und kein NAT) mehr. Trotzdem habe ich mit SwyxMobile keinen Ton, Wireshark zeigt auf dem Interface auch überhaupt keinen RTP-Traffic an. So kam ich ursprungs auch auf die Vermutung, dass ich mit SipLocalInterface den gesamten SIP-Traffic an ein Interface binde und mir so selbst in Knie schieße...
  13. Hallo zusammen, wir wollen Swyx Mobile gern flächendeckend einsetzen und scheitern gerade "nur noch" an der internen Anbindung. Von außen klappt der Zugriff inkl. beidseitigem Media-Streaming ohne Probleme, aus dem internen Netz (WLAN) kann ich mich zwar verbinden, habe aber nur einseitiges Media-Streaming: Ausgehend wird der Ton übertragen, eingehend nicht. Das Problem: Der Server hat zwei Netzwerkkarten (eine für den Internetzugriff und eine für die LAN-Seite). Da wir einen SIP-Provider einsetzen, habe ich den RegKey SipLocalInterface gesetzt, sodass dieser auf die NIC mit Internet-Zugriff gebunden wird. Wenn ich Wireshark richtig interpretiere, wird nach dem Aufbau des Gespräches der Mediastream an die "falsche" NIC ausgegeben. Meine Frage: Ist es prinzipiell möglich, mit dem SIP-Provider auf der einen NIC, internen SIP-Traffic aber auf der anderen NIC durchzuführen? Alternativ: Wie wäre hier der richtige Weg? Swyx-Mobile einmal durch die Firewalls heraus und wieder rein führen, damit dieser über die "Internet"-NIC läuft? Edit: Aktuell ist SwyxWare 12.31 im Einsatz. LG Sebastian
  14. Über WLAN tritt das Problem nicht auf, nur in Mobilfunknetzen. Aber wenn die Android-App reibungslos läuft, müssen die RemoteConnector-Einstellungen ja eigentlich richtig sein, oder? Ich werde das Problem nun erst einmal vertagen, da wir in einigen Wochen eine Glasfaserleitung bekommen, danach wird das Routing ohnehin noch einmal verändert und das doppelte NAT, was aktuell diesbezüglich die Sache auch nicht gerade vereinfacht, wird aufgelöst. Ich werde mich dann hier noch einmal zurückmelden, ob sich dadurch etwas verändert hat. Grundsätzlich wird die iOS-App ja funktionieren, sonst würden sich mehr Kunden beschweren
  15. Wir haben mittlerweile herausgefunden, dass das Problem tatsächlich nur mit der iOS-App besteht, die Android-App funktioniert in beide Richtungen. Da die Test-Smartphones SIM-Karten unterschiedlicher Anbieter und Netze nutzen, habe ich hier noch einen Zusammenhang gesucht und die Netze mal getauscht. Das Problem bleibt: iOS nur eingehend (und interne Telefonate), Android funktioniert komplett. Ich würde hier daher erst einmal vermuten, dass es nicht an der Swyxware-Installation selbst liegt. Beim Durchsuchen der Logs ist mir aufgefallen, dass die Swyx Mobile Apps einen User-Agent-String mitschicken, in dem auch die lokale (?) IP des Endgerätes mitgeschickt wird. Bei Android sieht der so aus: User-Agent: Swyx Mobile/3.1.2 (Language=Deutsch) (OS=Android 7.1.2) (IP=0.0.0.0) (MAC=02:00:00:00:00:00) Bei iOS so: User-Agent: Swyx Mobile/3.1.2 (Language=de-DE) (OS=iOS 14.4.2) (IP=10.219.2.165) (CtiMaster=No) Auffällig ist hier, dass unter iOS die lokale IP des LTE-Modems ausgelesen wird. Im Mobilfunknetz hat man ja bekanntermaßen keine echte öffentliche IP sondern befindet sich hinter einem NAT, diese IP ist für Swyx also eigentlich wertlos. Ich frage mich, ob das der Grund ist, warum unter Android hier einfach keine IP (bzw. 0.0.0.0) mitgegeben wird. In den Traces zum ConnectSrv finde ich die folgende Zeile, wenn der Fehler auftritt: 16 07:53:54.131 00253c Info SIPProxy 006DBCC8 00000059 CSipProxy::ProcessAnswerFromLan () -dNOIVIWl5bIUy5jWHHQDaf1X0zsyfnx: No matching media found Meine Vermutung ist jetzt, dass er Quelle und Ziel zusammenführen möchte, dabei auf die über den User-Agent mitgegebene IP stößt und feststellt, dass die anfragende IP ja eine ganz andere ist (nämlich die öffentliche aus dem LTE-Netz). Bei Android sieht er eine Wildcard und es ist für ihn ok. Kann aber auch vollkommener Unsinn sein, ich finde leider keine Dokumentation über die genauen Mechanismen zur Mobile App 🙂 Es ist schade, dass ich als Endkunde nicht direkt mit Swyx kommunizieren kann. Emails an mobile-for-ios@swyx.com bleiben leider unbeantwortet. Mein offizieller Weg für Swyx-Tickets ist leider sehr viel stille Post: Ich <--> Swyx-Partner <--> Distributor <--> Swyx
×
×
  • 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.