Sprachkommunikation über TCP / IP

Nein, TCP ist eine schreckliche Idee. UDP wird in diesem Fall viel besser funktionieren und Pakete, die nicht mehr synchron sind, spielen keine Rolle!

Wenn Ihr Chef die technischen Details nicht verstehen kann, sagen Sie ihm, dass praktisch alle derzeit existierenden VOIP-Systeme UDP verwenden und es muss einen Grund geben: Skype, Ventrilo, Teamspeak, World of Warcraft usw.

Um diese Frage richtig zu beantworten, müssen einige der wichtigsten Konzepte von VoIP erläutert werden.

Erstens ist UDP die beliebteste und weit verbreitete Methode für VoIP. Denken Sie daran, dass ein IP-Netzwerk paketvermittelt und ideal für Nicht-Echtzeit-Datenkommunikation und nicht für Echtzeit-VoIP ausgelegt ist.

Um dieses Problem zu lösen, wird UDP verwendet. UDP ist ein unzuverlässiges und verbindungsloses Protokoll. Obwohl UDP Pakete verlieren wird die Sprache Audio noch verstanden werden, wird das Gehirn effektiv für die Fehler kompensieren. Deshalb können Sie immer noch mit jemandem auf einem Telefon mit einem Signal von 3 Balken sprechen.

Packet Loss und Burst Lengths

Ein Paketverlust tritt häufig aufgrund von Überlastung auf, so dass der Umfang des Paketverlusts davon abhängt, wie gut das Netzwerk eingerichtet ist. Packet Loss bei VoIP mit UDP tritt meist in Burst-Längen auf. Eine Burst-Länge ist die Anzahl der Pakete, die bei der Übertragung hintereinander verloren gehen, also eine Burst-Länge von 3 bedeutet 3 Pakete hintereinander gingen verloren.

Paketverlustkompensation

Wo Paketverlust auftritt werden einfache Paketverlustkompensationstechniken Surfice und die Dienstgüte wird nicht ernsthaft beeinflusst, Sprache kann immer noch verstanden werden, sogar in Fällen, in denen 20-30% der Pakete verloren gehen. Methoden umfassen:

1. Wiederholen Sie den letzten erfolgreich Paket erhalten.

2. Ausfüllen - Spielen Sie Stille in der Lücke.

3. Splicing - Effektiv kann das sein dachte an Entfernen die Lücke, die durch die Burstlänge verursacht wird durch Drücken von Anfang und Ende des Lücke zusammen.

4. Interpolation - Verwenden Sie Kenntnisse von Rede vor und nach interpolieren verlorene Pakete innerhalb der Lücke z.B. Mittelwert zwischen den erfolgreich empfangenen Paketen vor und nach der Burst-Länge.

Ein gutes Verfahren zum Verringern der Größe von Burst-Längen ist als Interleaving bekannt, und somit ist eine zunehmende QoS interleaving . Eine Blockverschachtelungsfunktion nimmt die Sprache und teilt sie in eine Menge von Paketen auf. Diese Pakete werden in einen Puffer mit der Form einer Matrix (z. B. 4 mal 4) geladen, eine Funktion wird verwendet, um den Puffer zu drehen oder zu transponieren, so dass die Pakete nicht in der richtigen Reihenfolge sind. Auf der Empfängerseite wird die Umkehrung dieser Funktion verwendet, um die Pakete neu zu ordnen. Diese Methode ist einfach und effektiv. Siehe die folgende Abbildung:

Alternativtext http://img688.imageshack.us/img688/3962/capturevnk.png

Ich habe vor kurzem eine kleine VoIP-App erstellt. über ein WLAN mit UDP. Ich bin mir der genauen Anforderungen Ihrer Anwendung nicht wirklich sicher, aber im Allgemeinen können VoIP-Anwendungen (zwischen zwei Hosts) wie folgt implementiert werden:

In dem Diagramm definiert die Anwendung ihr eigenes Paketdesign. Der Header könnte nur die Paketnummer (unter Verwendung von 1 Byte) und die Payload die Audiodaten (n Bytes, Größe der Payload) sein. Dies zu definieren ermöglicht bessere Paketkompensationstechniken und ermöglicht einen logischen Ablauf für die Programmierung.

TCP ist aus verschiedenen Gründen eine schlechte Wahl für VoIP. Ein kurzer Blick auf 'TCP VoIP' verrät, warum das erste Ergebnis hinter dieser Ansicht steht.

TCP ist ein zuverlässiges, verbindungsorientiertes Protokoll, das bedeutet, dass Pakete, die bei der Übertragung verloren gehen, irgendwann vom anderen Host erneut gesendet werden. Diese Neuübertragung ist für Echtzeitdienste unpraktisch und wird Jitter, Latenz und möglicherweise Paketverlust (in einigen Fällen) erhöhen.

Antworten auf Ihre Fragen

Was ich bekomme ist im Grunde nur Lärm. 20% davon ist der aufgenommene Sound und der Rest ist nur komisches Geräusch.

TCP sollte kein Rauschen erzeugen, es sollte Jitter und Latenz verursachen. Sockets neigen dazu, eine automatisch definierte Timeout-Zeit zu haben, definieren Sie die Time-Out-Zeit? Wenn nicht, was passiert, warum erhalten Sie rechtzeitig vor der Wiedergabe nicht das richtige Paket?

Bin ich auf dem richtigen Weg? Ist es sogar eine gute Idee, TCP / IP für diese Art von Anwendung zu verwenden (Voice-Konferenzen von Art)?

Nein, NICHT TCP / IP verwenden ist keine gute Idee. Es scheint, dass Ihr Manager fälschlicherweise angenommen hat, dass ein Paketverlust eine schreckliche Sache ist.

Zusammenfassung

Einige allgemeine Schlüsselkonzepte wurden hier gezeigt, um zu versuchen, so viel wie möglich für dieses spezifische Problem zu helfen, jedoch sollte dies nicht als erschöpfend betrachtet werden. Stellen Sie sicher, dass das VoIP-System auch einige grundlegende Prinzipien der Sprachcodierung / Signalverarbeitungstechniken verwendet.

Die wichtigsten zu beachtenden Punkte sind:

• UDP für VoIP verwenden.

• Implementieren der Paketverlustkompensation
  Techniken.

• Ein Block Interleaver ist ein einfaches und ein effektive Methode, um QoS zu erhöhen.

Ich hoffe, das hilft.

Wenn Leute über den TCP / IP-Stack sprechen, meinen sie oft "den ganzen Internet-Protokoll-Stack", der UDP enthält. Vielleicht macht das deinen Manager glücklich ;-)

TCP / IP würde funktionieren; es wird die Daten liefern. Es ist möglicherweise nicht ganz so effizient wie UDP, wenn Sie sich keine Gedanken über den Paketverlust machen, aber Sie sollten in der Lage sein, die Daten gut zu übertragen.

Es gibt keinen Grund, warum Sie über TCP Rauschen bekommen sollten und es sieht daher wie ein Fehler in Ihrem Code aus. Tatsächlich werden die meisten Streaming-Medien, die wir erhalten (denke YouTube), über TCP gemacht.

Das Problem mit TCP ist Jitter. Die Lieferung Ihres Datenstroms wird verzögert, bis alle Pakete empfangen und neu geordnet wurden. Jetzt ist die verspätete Lieferung für Multimedia so gut wie keine Lieferung. Dies ist normalerweise eine schlechtere Wahl als einfach den fehlenden Rahmen zu interpolieren. Wie oben erwähnt, wenn der Paketverlust minimal ist und Ihr Netzwerk schnell ist, sollte es keinen Unterschied machen.

RTP / RTCP over UDP wird normalerweise für die Zustellung des Medienstroms verwendet. RTP enthält Dinge wie Sequenznummern in der Paketkopfzeile, die es ermöglichen, später Pakete in ihre korrekte Position einzufügen, wo dies möglich ist. RTCP verfügt über eine Berichtsfunktion, die es dem Codec ermöglicht, sich an Situationen anzupassen, in denen der Paketverlust zunimmt. RTP / RTCP bietet daher einige, aber nicht alle TCP-Funktionen.

Bei Streaming-Medien über TCP kann dies leicht durch einen großen Jitter-Puffer gelöst werden. Dies erhöht die Latenz, aber für das einseitige Streaming ist dies kein Problem. Die Latenz ist jedoch ein Hauptproblem beim Zwei-Wege-Streaming.

Ein Hauptvorteil von TCP besteht jedoch darin, dass es Firewalls einfacher als UDP durchquert. Ist eine TCP-Sitzung eingerichtet, ist die Firewall sowohl zum Senden als auch zum Empfangen von Daten geöffnet. Dies ist für UDP komplizierter, insbesondere wenn man einen eingehenden Datenstrom erwartet. Es gibt Möglichkeiten, dies zu umgehen, aber sie können kompliziert sein und möglicherweise das Protokoll der Sitzungssteuerung (wie SIP oder RTSP) verstehen.

Es gibt einige Hauptgründe, warum Livestreaming-Daten UDP verwenden. Der größte davon ist der Empfang verspäteter Daten ist so gut wie überhaupt kein Empfang und die Verzögerung des Streams für die Weiterverbreitung ist sicherlich keine gute Idee. Für VoIP haben Sie eine Latenztoleranz von etwa 150ms. Jedes Sprachpaket, das länger als das verzögert ist, wird für Benutzer sichtbar.

Warum, warum Sie Rauschen bekommen, wie behandeln Sie spät ankommende Pakete aufgrund von Neuübertragungen?

Hängt von der Art des zugrunde liegenden Netzwerks ab, wenn Sie Ethernet mit einer Zuverlässigkeit von 99,9% haben, würde ich annehmen, dass TCP gut funktionieren würde. Wenn Sie es jedoch über 802.11 tun, dann wäre TCP eine nicht so gute Idee.

Sie können Ihren Chef aus einem bestimmten Grund bitten, TCP zu verwenden und dann diesen bestimmten Dienst, z. B. Grundzuverlässigkeit, oder einen Fehlerkorrekturdienst über UDP zu implementieren. Vielleicht möchten Sie auch in RTP ( Ссылка )

TCP sollte nicht Rauschen verursachen. Jitter und Lag, ja (besonders wenn Ihre Links verlustreich sind); aber überhaupt kein Lärm. Etwas ist mit deiner Programmierung fischig.

BTW, ich stimme zu, dass UDP in diesem Fall weit passender ist als TCP.

Die meisten Sprachanwendungen werden mit dem RTP-Protokoll erstellt, das über den UDP-Port streamt. Nun die meisten von ihnen mit Codec-Unterstützung, um sicherzustellen, dass die Medien vor dem Strom von einem Ende zum anderen komprimiert werden. Besprechen Sie mit Ihrem Chef die Bandbreitenanforderungen.

Wenn Sie Rauschen bekommen, überholen Sie wahrscheinlich den Teil Ihres Puffers, der erfolgreich mit Paketen gefüllt wurde, und spielen einen leeren / nicht initialisierten Puffer.

Wie viel langsamer ist TCP als UDP? Mit TCP erhalten Sie eine Übertragungsverzögerung, wenn Pakete nicht ordnungsgemäß ankommen oder beschädigt sind. Ich werde sagen, dass es Möglichkeiten gibt, TCP zu optimieren, so dass es weniger Verzögerung gibt. In Linux und Winsock gibt es eine TCP_NODELAY-Option zu verwenden. Auch ein kompakter Codec wird helfen, G.729 die Nutzlastgröße niedrig zu halten. Da die Übertragung auf empfangenen Paketen basiert (in Reihenfolge - TCP), sollte man sich auf die Optimierung der Paketgröße konzentrieren, um klein genug zu sein, um die erneute Übertragungsverzögerung zu reduzieren, aber groß genug, um einen Qualitätsstrom aufrechtzuerhalten. Ein gutes TCP-VoIP-Programm hätte die Fähigkeit, die Codierungsqualität und die Paketgröße im laufenden Betrieb zu variieren, wobei der Sender dem Empfänger der Änderung signalisieren müsste. Aber der einzige Vorteil von TCP in Echtzeit ist, dass es weniger wahrscheinlich von Firewalls blockiert wird.