UDMP pro - sporadisch kommen eingehende Voice nicht durch. Bitte um Hilfe!

Es gibt 14 Antworten in diesem Thema, welches 5.439 mal aufgerufen wurde. Der letzte Beitrag () ist von Arcus.

    Hallo liebe Gemeinde,

    ich benötige bitte dringend Unterstützung für mein VOIP Problem.

    Wir betreiben hinter einem Lancom 1906VA-4G (2xVDSL sowie 4G Backup) eine UDM-Pro (v1.8.3 / v6.0.41) mit 17 Switches 29 AP´s und 10 Unifi Richtfunkantennen um 5 Standorte zu vernetzen. An den jeweiligen Standorten gibt es jeweils IP Telefone von Unifi die mit einer Swyx Netphone (v11.5) reden. Eigentlich läuft alles prima, ABER:

    Sporadisch / vorrangig bei eingehenden Mobil Gesprächen, haben wir keinen eingehenden RTP Stream. Dieser bleibt in der Unifi Firewall hängen. Wenn wir den Gesprächsteilnehmer zurück rufen, funktioniert es dann.

    Zuvor haben wir das Ganze mit einer USG 4 pro betrieben mit gleichem Ergebnis. Da konnte ich die Firewall ausschalten und es funktionierte perfekt.

    Leider bin ich ziemlich am Ende mit meinem Wissen. Hat jemand dazu eine Idee? Firewall ausschalten habe ich nicht gefunden. Wäre auch schön, wenn dies an bleibt , da wir 5 verschiedene Netze intern betreiben.

    Vielen Dank für Eure Mühe

    Ein paar Anmerkungen und Fragen von mir:


    1. Conntrack Module unter. Routing & Firewall => Firewall => Einstellungen ausschalten

    2. Nutzt ihr Stun für die VoIP Calls? Eventuell stimmt was mit den ausgehändelten RTP Ports nicht. Noch besser als Stun wäre rport (falls es die TK Anlage kann).

    3. Wird der Call per UDP oder TCP (wenn ja, mit oder ohne TLS?) aufgebaut?
    4. Wenn UDP Unter Routing & Firewall => Einstellungen UDP Timeout höher setzen (180 ist ein guter Wert)

    Vielen Dank für die schnelle Antwort.

    1. Module habe nun alle ausgeschaltet. - Leider ohne Erfolg

    2. ja es wird Stun für die Calls benutzt. Und ich denke auch, dass es daran liegt. Mit deaktivierter Firewall mach es keine Probleme. Ob Swyx rport unterstützt muss ich herausfinden.

    3. Der Call wird mit TSL aufgebaut.

    4. Der UDP Timeout-Wert liegt bei 180.


    Ich habe im Anhang mal beide Varianten aus Wireshark als pdf beigefügt.


    DSL Lancom1906 (192.168.10.1) --- (192.168.10.10) WAN UDM-Pro (192.168.0.244) Lan - Standard Gateway------(192.168.0.60) Swyx Netphone Server ------ (192.168.0.53) angerufenes IP Telefon im Beispiel

    Hallo zum 2. Advent.


    ich habe nochmal tausend Sachen probiert und leider kein Ergebnis. :frowning_face:


    Sporadisch gibt die Firewall den RTP an ein falschen Port. Hat jemand davon einen Plan? Im Wireshark kann ich nicht erkennen, dafür habe ich zu wenig Ahnung vom Thema.


    Wenn jemand eine Idee hat, wäre ein Traum. Ich muss nun erstmal die UDM-pro wieder abklemmen und den Coudkey2 mit USG4-pro dranhängen, damit alle die Woche ordentlich arbeiten können.

    Wenn ich das richtig verstehe, dann läuft der LANCOM als DSL/4G Router? (also NICHT im Bridge Modus oder?)


    Hast Du mal nen einfachen Plan wie der Netzaufbau ist?

    ------

    vg

    Franky

    Ja, der Lancom läuft als Router. Da sind alle Rufnummern registriert.


    Der Netzaufbau ist eigentlich wie oben beschrieben. Zumindest vereinfacht dargestellt. Wie schon erwähnt, kommen dahinter noch unifi Richtfunkstrecken und Client's mit Telefonen. Das macht für mich etwas komplizierter. Sonst könnte man das ja einfach splitten und die unifi Firewall umgehen. Wenn sie im cloudkey ausstellen und das nat aus mache, funktioniert es ja. 🤪

    Mich wundert, dass das kommend funktioniert.


    Nach meinem Verständnis müsste die Terminierung des SIP Connects an der Swyx erfolgen und der LANCOM Router sollte den gesamten VoIP Strom direkt an die Swyx weiterleiten. Oder macht der LANCOM Session Border Controller Funktionen? ... in dem Fall terminiert der SIP Strom am Lancom und wird dann komplett neu für die jeweilige Session vom Lancom zur Swyx neu aufgebaut.


    WENN dem so ist, dann passt die Signalisierung des LANCOM zur Swyx nicht. Ich tippe einfach mal ins Blaue und vermute, dass Du ein UDP Problem hast und irgendeine Stufe dazwischen das nicht sauber durchsignalisiert.


    ... aber mal ganz ehrlich. Das ist gerade alles Stochern im Heuhaufen. Denn das kann man wirklich nur vor Ort an den Terminals analysieren. Dein Netz ist alles andere als "easy" ...

    Noch was:
    Wenn ich mir das Sip Session Protokoll ansehe, dann wäre jetzt mal noch eine Idee (um eine Fehlkonfig in der Swyx/Endgeräte Kombi auszuschließen), dass Du von außen einen AB anwählst und dann auch nochmal den SIP Session Aufbau mitschneidest.

    ------

    vg

    Franky

    Einmal editiert, zuletzt von Samhain ()

    So,

    für alle , die es interessiert.:

    Ich habe das Firewall Problem und somit die sporadisch nicht eingehenden RTP Streams NICHT lösen können. Die UDM-Pro war bockig.


    Somit habe ich nur für die Telefonie im Netzwerk einen "Umweg" über ein 2. Gateway gewählt. (einfacher TPlink) An dem kann man prima alles bzw. einzeln zu und abschalten. Nur so als Tipp an Unifi. ,-)

    • Offizieller Beitrag
    Zitat von Torsten

    So,

    für alle , die es interessiert.:

    Ich habe das Firewall Problem und somit die sporadisch nicht eingehenden RTP Streams NICHT lösen können. Die UDM-Pro war bockig.


    Somit habe ich nur für die Telefonie im Netzwerk einen "Umweg" über ein 2. Gateway gewählt. (einfacher TPlink) An dem kann man prima alles bzw. einzeln zu und abschalten. Nur so als Tipp an Unifi. ,-)

    Musste ich auch so machen. Oder fritzbox im hintergrund rein nehmen. UDM / USG blockiert die SIP Server. entweder ein anderen nehmen oder VPN arbeiten

    Liebe Gemeinde,

    iIch habe leider ein ähnliches Problem mit einer Fritzbox 7490 im Netz eines UDM Pro.

    In der Portweiterleitung haben ich den Port 5060 an die FB geleitet.

    Leider bekommen Anrufer sporadisch keine Verbindung. In diesem Fall wird der ankommende Ruf auch NICHT in der

    Telefonliste der FB angezeigt. Der Anrufer bekommt "abgwiesen".

    Leider stecke ich nicht ansatzweise so tief in der SIP MAterie wie meine Vor-Schreiber.

    Irgend eine Idee für einen UDM-Anfänger ?

    Grüße

    Arcus

    • Offizieller Beitrag

    Das Thema mit den "30 Sekunden" hast Du aber in der als IP-Client konfigurierten FRITZ!Box eingestellten, ja? Welcher Firmware-Stand?

    Vorschlag zur Eingrenzung des Fehlers:


    Vermutlich geht eine gehende Telefonverbindung problemlos.


    Wenn ja, dann:


    - Gehende Verbindung machen. Gespräch annehmen. Ca. 20 Sekunden stehen lassen. Dann auflegen

    - Sofort (innerhalb von 30 Sekunden) Rückruf des vorher angerufenen Apparates


    Wenn das so geht, dann liegt es am Timing der SIP Registrierung (diese dann in der FB auf die o.g. 30 Sekunden reduzieren).


    Portfreigaben in der FW sind normalerweise im genannten Szenario nicht notwendig. Sie dienen lediglich der Fehleranalyse.

    ------

    vg

    Franky

    Wie schon geschrieben, konnte ich das Thema nicht lösen. Trotz unzähliger Stunden und langer Nächte.

    Es liegt definitiv an der UDM. Selbes Problem hatte ich als Vorgänger mit der USG4 Pro. Da funktionierte es erst stabil, als ich per Skript die Firewall deaktiviert hatte, was nach meinem Wissen bei der UDM pro nicht mehr geht. -Ist ja auch nicht Sinn der Sache-

    Gelöst habe ich es , indem alle SIP Geräte (Telefone uns TK-Server) zwar im selben subnet sind, aber über ein 2. Gateway, parallel zur UDM, ins Netz gehen.

    Vielen Dank für Eure Hilfestelung !

    Die FW der FB 7490 ist die aktuellste 7.27, die der UDMP die 1.93 und der Controller der 6.1.71.

    Den 30 sec Refresh des Ports habe ich an der FB schon eingestellt.

    Leider konnte ich nirgendwo ermitteln, welche Ports die FB von Ihrer Seite öffnet, wenn ein Gespräch raus geht.

    Es musste mit den zu öffnenden Ports zusammenhängen, denn nachdem ein Gespräch raus ging kamen auch Alle von draussen rein..... für eine gewisse Zeit, bis die entsprechenden Ports wieder geschlossen wurden.

    BTW gibt es dafür einen Timer ?


    Jedenfalls habe ich bei 1&1 im Service angerufen und habe (wider Erwarten) sofort jemanden dran gehabt, der sich noch an die nötigen Ports erinnern konnte und der mir half, obwohl ich die FB nur als TK-Anlage hinter einer UDMP missbrauche.


    Er empfahl mir folgende UDP Ports an die FB weiter zu reichen:

    Bisher sieht es so aus, als funktioniert es.

    Auch wenn seit 2 Std. kein Gespräch geführt wurde, wird ein eingehender Ruf problemlos durchgereicht.

    Mal sehen, ob ich mich zu früh gefreut habe....... :winking_face:.


    Beste Grüße

    Arcus