VOIP Yealink Telefone - Gesprächspartner wird nicht gehört

Es gibt 18 Antworten in diesem Thema, welches 6.976 mal aufgerufen wurde. Der letzte Beitrag () ist von PauloPinto.

    Moin zusammen,


    bei meinem Buddy in der Firma hatte ich vor etlichen Monaten nicht nur das Netzwerk mit Unifi Geräten, sondern auch das Telefonieren "erneuert". Gewünscht war eine VOIP Lösung. Wir haben einen kleinen Anbieter aus Berlin ausgewählt und Arbeitsplätze mit Yealink Telefonen ausgestattet. Das Ganze läuft auch schon etliche Monate Störungsfrei.


    Nun habe ich heute die Rückmeldung bekommen, dass es heute vermehrt Anrufe gab, in dem der Gesprächspartner nicht zu hören war. Unabhängig ob von einem "Festnetz" oder Handy angerufen wurde, man hörte...nichts. Das Einzige was sich in den letzten 2 Wochen geändert hat, war der Softwarestand auf den Unifi Geräten (alle Updates eingespielt) und ich habe die alte Telefonanlage im Schrank zurückgesetzt und vom Netzt genommen. VOIP hat seinerzeit ein eigenes VLAN bekommen, da tummelt sich um die ~15 Yealink Telefone, nichts anderes.


    Gibt es bekannte "Dinge" die man bei einem VOIP Netz konfigurieren sollte/muss? Oder irgendwelche anderen Kniffe, Konfigurationen die man eingestellt haben sollte, damit VOIP sauber läuft?


    Internet und VOIP Anbieter sind sich keiner Schuld bewusst :smiling_face_with_sunglasses: . Leider ist kleine Zweigstelle im Osterurlaub, die haben quasi das Gleiche, nur mit ner UDR. Hatte dort ebenfalls nachgefragt obs Probleme gab. Wenn nicht, liegt es wohl an unserem HQ oder dem Internetanbieter (Glasfaser 300Mbit)


    Bin für jegliche Ideen Dankbar :face_blowing_a_kiss:


    PS: werde heute Abend mal die USG Neustarten

    Moin, wenn Sprache nicht übertragen wird sind in der Regel die RTP Ports schuld. Was für eine Telefonanlage wird genutzt? Welche Ports sind bisher freigegeben? Wird irgendwas ausgehend geblockt?

    Danke 1

    Hi, danke für Deinen Hinweis. Muss ich mal Google fragen, was genau das ist :smiling_face_with_smiling_eyes: .


    Es ist ja nicht bei jedem Gespräch, sondern bei einigen und immer das gleiche verhalten. Telefon klingelt, man geht ran, hört den anderen aber nicht. Firma legt wieder auf, Kunde ruft ne Minute später wieder an, alles ok.


    Die Anlage ist eine Cloud Anlage die beim Anbieter im RZ steht. Die Yealinks werden via MAC im Portal einem User zugewiesen und können sich dann Anmelden (Muss man aber aktiv freischalten). Die Telefone verbinden sich dann automatisch, sobald sie mit dem Internet verbunden sind.


    Ich habe in der Firewall unter LAN In die Regel, dass intern alles was aufgebaut wird auch raus darf. Separat IPs hatte ich nicht freigeschaltet, die von Extern rein dürfen. Geblockt habe ich auch manuell nichts eingestellt, was von innen nicht raus darf.


    Wobei, habe das Threat Management aktiv, fällt mir da ein. Aber das war von Beginn an aktiv.


    4 Mal editiert, zuletzt von PauloPinto ()

    Uhrsprünglich hätte ich gesagt.. typisch wenn der NAT Eintrag für den Rückweg schon aus der Tabelle raus ist.

    UDP Time erhöhen und dann sollte alles gut sein. Nicht hören können ist typisch dafür..

    (aber nicht immer die Uhrsache)


    Zitat von PauloPinto

    Es ist ja nicht bei jedem Gespräch, sondern bei einigen und immer das gleiche verhalten. Telefon klingelt, man geht ran, hört den anderen aber nicht. Firma legt wieder auf, Kunde ruft ne Minute später wieder an, alles ok.

    Na das klingt aber ein typisches Media Gateway Problem des Carrier. Der hat da X stück davon von, jedesmal wenn der call über

    Gateway 1-5 geht ist alles schick. Gateway 6 macht mucken....frag ob ob die neue Hardware haben :smiling_face: (werde die nicht sagen oder zugeben, wobei wenns nen „kleiner“ ist vielleicht schon).

    Moin, auch Dir danke für den Tipp! Was genau meint Du mit dem NAT Eintrag, der raus ist? Würde mich rein Fachlich interessieren. Ich lerne immer gern dazu und VOIP habe ich leider nur sehr wenig Erfahrungen sammeln können.


    Die Einstellungen in der USG hatte ich "default" gelassen und sehen aktuell so aus:


    Müsste der UDP Stream erhöht werden? Was sind da Eure Erfaurungswerte, auf wieviel man diese Einstellen soll?

    Schau dir an wie PNAT Funktioniert:


    SIMPELST:


    Dein Rechner 192.168.1.33 hängt an deinem Router mit der öffentlichen IP 1.2.3.4 will z.B die Webseite

    5.6.7.8 erreichen. Die Anfrage sieht ungefähr so aus:


    192.168.1.33 PORT 52929 (zufälliger port > 1024) an 5.6.7.8 PORT 80 (http halt)

    Dein Router macht daraus 1.2.3.4 PORT 52929 an 5.6.7.8 PORT 80 und merkt

    sich dabei das die Anfrage von 192.168.1.33 PORT 52929 gekommen ist.


    Die Webseite antwortet:

    5.6.7.8 PORT 80 schickt an 1.2.3.4 PORT 52929


    Da NAT hat sich das gemerkt und schickt das was es über PORT 52929.

    Das ist wie eine Portweiterleitung (wird gerne Portfreigabe genannt) dynamisch.


    Diese Einträge werden werden auch Connection Tracking, NAT Table oder

    forward entry genannt (jeder Hersteller hat da seien eigne Namen).


    Die Zeiten oben geben an wie lange so ein Eintrag (sollte er nicht explizit gelöscht

    werden wie bei TCP) bestehen bleibt.


    UDP und USP Stream zu erhöhen kann bei Problemen helfen wenn die

    re Registrierung bei SIP zu lange dauert. Dann klingelt aber auch das Telefon

    nicht mehr. (ich habe bei mit 300 Sekunden, komme da bei Telekom Privat gut mit klar,

    Fonjal und Sipgate sind da auch schneller mit reregister)


    Bei dir werden WAHRSCHEINLICH die Antwort UDP Pakete nicht

    an den PORT zurückgesendet an dem sie von dem Jeweiligen Telefon erwartet werden.


    ENTWEDER, bekommst du garnicht weil im SIP/SDP eh die falsche (private IP Drinne steht)

    oder das GATEWAY schickt nicht an den richtigen PORT zurück und deinRouter weis nicht

    was damit anzufangen.Könnte man schnell über ein DUM rausbekommen aber da sollte man

    schon wein wenig SIP Erfahrung haben.


    Erfahrung zeigt bei mit das Anbieter X aber was neugemacht hat, Update eingespielt,

    neue Hardware dazu oder was weis ich.. die Loadbalancer sorgen dann dafür das jeder X

    call nicht funktioniert....


    Moin Danke für Deine Erklärungen :thumbs_up: !


    Die USG ist der Router und hängt direkt am Glasfaser. Die sollte eigentlich ihr VOIP VLAN kennen. Zwischen Telefon und USG gibt es nur nen 48er Unifi Switch und nen 24er Unifi Switch an dem nur die VOIP Telefone hängen. Beide Switche sind mit aktiv SFP Kabel verbunden.


    Bin grad etwas Ratlos, was ich noch tun kann. Sollte ich einfach mal UDP und USP Stream um ....30? .. erhöhen?

    Welcher Anbieter wird denn genutzt? Eventuell hat der auch ein paar Anweisungen was die Firewall angeht.

    Danke 1

    Den Anbieter kennt vermutlich keiner , vionetworks aus Berlin. Dort scheint es eine Erweiterung des Systems zu geben. Gab jetzt eine E-Mail mit der Info neue IP Adressen auf der FW freizuschalten, sollte man explizite IPs eingetragen haben. Hatte gestern ein Ticket aufgegeben und da konnte man nur sehen, dass kein "Auflegen" an die Anlage gemeldet wurde und nach 51 Sekunden gab es ein zweites Gespräch von dieser Nummer. Da hat der Kunde dann wohl zurück gerufen. Aber ich möchte mich jetzt nicht drauf verlassen, dass es an dem Gegenüber liegt. Andere Kunden haben das Problem anscheinent nicht.


    Wäre es den Sinnvoll nach allen IPs und Ports zu fragen und eine Regel einzubauen, dass von extern diese IPs mit diesen Ports direkt durch ins VOIP Netzt darf?

    Zitat von PauloPinto

    Wäre es den Sinnvoll nach allen IPs und Ports zu fragen und eine Regel einzubauen, dass von extern diese IPs mit diesen Ports direkt durch ins VOIP Netzt darf?

    Das wäre zumindest eine Möglichkeit

    Danke 1

    Dann werde ich die FW von außen also doch aufmachen. Mail an den Support ist raus.


    Noch mal zu den timings, sollte ich den USB Stream trotzdem parallel um 30 hochstellen? Fällt EUch anhand der Screenshots noch weiteres auf, was man deaktivieren, aktivieren oder von der Zeit raufsetzten sollte?

    Zitat von PauloPinto

    ort scheint es eine Erweiterung des Systems zu geben. Gab jetzt eine E-Mail mit der Info neue IP Adressen auf der FW freizuschalten, sollte man explizite IPs eingetragen haben.

    Passt irgendwie zu meiner Aussage...

    Zitat von gierig

    frag ob ob die neue Hardware haben :smiling_face: (werde die nicht sagen oder zugeben, wobei wenns nen „kleiner“ ist vielleicht schon).


    Grade wenn vorher alles ging und du nicht irgendwelche FW regeln hast die da was sperren sollte alles auf deiner Seite Immer noch gut sein. Carrier muss sein kram in den Griff bekommen. Zu den NAT Timeouts hatte ich schon geschrieben, kannst de machen wird nichts bringen. Oder mach doch einfach... kaputt gehen kann da nichts.

    Und zur Firewall was willst du denn wie freigeben für ein VOICE Vlan was eh nicht schon frei ist wenn nicht gesperrt ?

    Das klingt zwar „gut“ macht aber irgendwie keinen sinn oder ich habe grade selber einen Denkfehler...

    Der Anbieter vermutet natürlich, dass das Problem auf meiner Seite liegt.


    Ich denke mal laut und schreibe einfach so runter......


    Die Regel wollte ich einrichten, damit die Carrier IPs explizit freigeschaltet sind, also von außen nach innen, inkl. der entspechenden Ports. Das habe ich aktuell nicht und bis dato auch nicht gebraucht. Lief seit vielen Monaten reibungslos.


    In deren Netzwerk Guide stehen Ports und IPs die freizugeben sind. Von Innen nach außen ist das auch so. Alles was von ihnnen heraus aufgebaut wird, darf nach druaßen. Da in diesem Guide keine Quellnetzte/IPs angegeben sind (Also IPs vom Carrier), habe ich keine - von außen betrachtet - Any Quelle zu VOIP Netz als Ziel Regel gebaut. Es soll ja nicht jeder über die angegebenen Ports direkt von außen auf mein VOIP VLAN zugreifen dürfen.


    Es steht unter anderem drin (quelle vionetworks):

    Zitat

    "Bei Verwendung von NAT ist ein UDP-NAT Timeout von mehr als 65 Sekunden unter allen Umständen erforderlich. Empfehlenswert wäre hier jedoch sogar ein höherer Wert zwischen 65 und 90 Sekunden. Sollte das lokale Netzwerk Spanning Tree verwenden so ist entsprechend an den Endgerät-Switchports dieSpanning Tree Option zu deaktivieren."


    UDP Stream habe ich auf 180 Sekunden, Haken dran. Spanning Tree habe ich gerade mal geschaut. GLobale Setting on = Spanning Tree On und auf RSTP. Bin jetzt aber gerade überfragt, was passiert, wenn ich die Remote deaktiviere?! Verbunden sind die beiden Switche via aktivem LWL und SFP oder SFP+ Modulen, bin ich mir grad unsicher was ich seinerzeit genommen habe. Erwarten würde ich, dass nix passiert - außer ich habe mistig verkabelt :winking_face_with_tongue:

    Einmal editiert, zuletzt von PauloPinto ()

    Zitat von PauloPinto

    Die Regel wollte ich einrichten, damit die Carrier IPs explizit freigeschaltet sind, also von außen nach innen, inkl. der entspechenden Ports.

    Genau das geht so nicht wie du die das Vorstellst. Deine Telefone sind hintern einem NAT. Das einzige währen Portweiterleitung auf

    ein bestimmtes Ziel. Damit Zerstörst du dir aber automatisch alle anderen Ziele / Telefone. Was du kontrollieren / verifizieren kannst

    ist ob die Telefon Lokal alle einen einen Quell Port besitzen.


    Zitat

    Sollte das lokale Netzwerk Spanning Tree verwenden so ist entsprechend an den Endgerät-Switchports dieSpanning Tree Option zu deaktivieren."

    AM Port wo das Telefon angeschlossen ist ist damit gemeint, nicht überall. Bei Cisco würde man sagen den Port auf „Portfast“ stellen.

    das macht man aber mit Allens „Access Ports“ weil die dann schneller einen Link Bekommen und es eigentlich nicht möglich sein sollte

    darüber einen LOOP zu bilden oder einen redundanten Uplink zu einem anderen Switch. Aber das ist „Switching“ und auch wenn ich das

    immer mal lese bei „VoIP“.


    Wenn du „Beweise“ haben willst dann mache ein Trace direkt auf dem Router und schneide ein Gespräch mit das einseitig ist.

    Da siehst du ganz schnell ob der RTP überhaupt zum Router ankommt oder auf den Richtigen Port landet.


    Kann mir wie gesagt sehr gut vorstellen das da nen neues Gateway / SBC ist das Probleme mit den NAT Verbindungen hat.

    und ggf den RTP zu der IP schicken will die im SDP Header steht (was ne interne bei dir sein wird) und nicht an die

    IP wo das Signaling herkommt (also die Externe).

    Port Forwarding wollte ich eben aus den von Dir genannten Gründen nicht nutzen. Da habe ich wohl zu einfach gedacht, mit ner Regel die Ports für die externen IPs quasi "freizugeben". Mir scheint, dass VOIP doch viel viel komplexer ist, als ich erst dachte.


    Ich sammle grad nen paar Anrufe die Fehlerhaft waren und lasse die durch den Support beim Anbieter prüfen. Vielleicht finden die ja was in den Logs, was weiterhilft. Sonst bleibt mir wirklich nur nen Trace vor Ort. Muss aber gestehen, dass ich das auch schon länger nicht mehr gemacht habe, da ich berufsbedingt in komplett anderen Gebieten unterwegs bin. Man ist ja heute oft mehr "Manager" als "Hands on".


    Aufgrund der Feiertage wird das jetzt eh kurz auf Eis liegen. Ich halte Euch - wenn gewünscht - auf dem Laufenden und nerve dann wieder mit Fragen :smiling_face_with_smiling_eyes:  :partying_face:.


    Nochmals vielen Dank für Eure Uunterstützung!!! :smiling_face_with_hearts:

    Moin zusammen,


    muss den Thread noch mal aufwärmen :).


    Wie sieht das eigentlich mit den Optionene H.323 + SIP aus? Ich habe noch nicht ganz heruasgefunden, was passiert, wenn man diese Optionene Ein bzw. ausschaltet. Wenn man eine Fritte nutzt, sollte man beides besser ausschalten, wenn man so im Forum liest - in diesem Fall sind es aber VOIP Telefone, die sich aus Ihrem VLAN direkt mit der TK Anlage des Anbieters verbinden.


    Stellt man in diesem Fall beides aus oder ein? Und warum sollte man das so machen?

    Zitat von PauloPinto

    Stellt man in diesem Fall beides aus oder ein? Und warum sollte man das so machen?

    Das kommt drauf an wie deine Firewall und deine Verbindungen aussehen

    Bleiben wir bei SIP (H232 macht quasi das gleiche für H232 Verbindungen)


    Generell in kürze und schon garnicht vollständig:


    Wenn du einen Anruf tätig oder bekommst wird über SIP ausgehandelt.
    Neben dem Wer, woher an Wen (+49 12345 ruft +49 5678 an) gehören auch die Informationen

    wo die eigentliche Sprache (der RTP Stream) herkommt und wo sie hin gesendet werden muss. (SDP Header)

    (im Groben welcher Codec, zu welcher IP Port).


    A sagt z.B Sprache sendest Du an IP 1.2.3.4 Port 1234

    B sagt z.B Sprache sendest Du an IP 5.6.7.8 Port 5678


    A sendet nun seine Sprache VON Port 1234 and die Ziel IP 5678

    B sendet nun seine Sprache VON Port 5678 and die Ziel IP 1234


    Das SIP Conntrack Modul schaut sich das nun an und weis nun

    das zur dem SIP noch die IP und Ports dazugehören die für den RTP

    Stream verantwortlich sind.


    Im Paket Filter kann nun über „Releatet“ genau dieser Traffic erlaubt werden.

    Und hier beginnt das Problem warum das ding eigentlich immer aus ist.


    Im der Normalen 08/15 Firewall gibt es eh schon „Erlaube RELATED,ESTABLISHED„

    damit dinge auch wieder reindürfen die in Zusammenhang mit ausgehenden stehen.

    Das reicht für normales SIP aus. Interessant wird es erst wenn du sagst du SPERST alles

    was reinkommt und erlaubt nur SIP Traffic, oder machst auch ausgehend alles dicht und erlaubst nur

    SIP Traffic dann kann das Modul helfen die RTP Ports Dynamisch zu öffnen ohne einen ganzen Bereich einfach offen

    zu haben. Das kannst du aber garnicht so genau steuern über das Unifi System wie es eigentlich nötig sein müste

    um das Ding richtig zu verwenden. Den Kram den das Modul von alleine macht ist meinst eher Kontraproduktiv

    oder zu stellst kein Unterschied fest...

    Einmal editiert, zuletzt von gierig ()

    Danke 2