Struktur einer Voice-Chat-Anwendung (Client/Server)?

Question

Ich brauche eine EXPERT-Meinung bitte, und tut mir leid, wenn meine Frage selbst eine verworrene Frage ist.

Ich las über Struktur von VOIP-Anwendungen (Client/Server). Und meistens wird UDP für Voice Streams empfohlen. Ich habe auch einige VoiceChat-Anwendungen wie Paltalk und Inspeak überprüft und ihre Sites erwähnen, dass sie UDP-Voice-Stream verwenden, die aus den folgenden Gründen nicht korrekt erscheinen.

Ich untersuchte den Verkehr/Ports von Paltalk und Inspeak verwendet. Sie haben UDP- und TCP-Ports geöffnet und mit einem Paket-Sniffer kann ich sehen, dass es nicht viel UDP-Kommunikation gibt, aber meistens ist es die TCP-Kommunikation.

Auch soweit ich weiß, in UDP Protocol Server kann keine Daten an einen Client hinter NAT (DSL Router) senden. Und "UDP Braodcast" ist keine Option für "Internet" -basierte Voice-Chat-Anwendungen. THAT WARUM YAHOO in ihrer Dokumentation erwähnt, dass Yahoo Messenger zu TCP wechseln, wenn UDP-Kommunikation nicht möglich ist.

Also meine Frage ist ....

1. Am Verständnis ich etwas falsch in meinem obigen Aussagen?

2. Wenn UDP nicht möglich ist, verwenden diese Chat-Anwendungen TCP Stream für Sprache?

3. Da ich erlebt habe, dass TCP-Voice-Streams Verzögerung erzeugen, Keine Sprachunterbrechung aber Verzögerung in der Stimme, also was sollte die beste Struktur für eine Voice-Chat-Server/Client-Kommunikation sein?

Bisher denke ich, dass, wenn der Kunde die Pakete an Clients verteilen Daten als UDP-Pakete an den Server und Server senden über TCP-Streams, ist dies eine richtige Lösung? Ich meine, ist das, was kommerzielle Voice-Chat-Anwendungen tun?

Vielen Dank Ihre Antwort wird mir und vielen anderen Programmierern helfen.

JF

Answer 1

UDP hat weniger Overhead (in Bezug auf die Gesamtpaketgröße), so dass Sie mehr Audiomaterial in den Kanal der Bandbreite quetschen.

UDP ist auch unzuverlässig - gesendete Pakete können niemals empfangen werden oder könnten außer Betrieb empfangen werden - was eigentlich für Sprachanwendungen in Ordnung ist, da Sie einen gewissen Verlust der Signalqualität tolerieren und weitermachen können. eine kleine Menge verlorener Pakete kann toleriert werden (im Gegensatz zum Herunterladen einer Datei, wobei jedes Byte zählt).

können Sie TCP verwenden? sicher, warum nicht ... es ist etwas mehr Overhead, aber das ist egal.

SIP ist ein Sprach-/Medienstandard, der UDP und TCP unterstützt. Die meisten Bereitstellungen verwenden UDP wegen des geringeren Overheads.

Das Skype-Protokoll bevorzugt UDP wo möglich und greift auf TCP zurück. In SIP-Situationen wird das NAT-Problem gelöst, indem ein NAT-Keep-Alive-Paket (beliebige Anfrage-/Antwortdaten) verwendet wird, um den Kanal offen und offen zu halten, und indem die Tatsache ausgenutzt wird, dass die meisten NATs Antworten auf dieselben akzeptieren Quellport, von dem aus die Verbindung geöffnet wurde ... dies ist nicht idiotensicher und erfordert oft einen Proxy-Server, der die Verbindung zwischen zwei NAT-Peers vermittelt, wird aber in vielen Bereitstellungen verwendet.

STUN, TURN und ICE sind zusätzliche Methoden, die bei NAT-Szenarios helfen, insbesondere in p2p-Situationen (serverless).

Informationen in Bezug auf NAT-Probleme und Medien:

http://www.voip-info.org/wiki/view/NAT+and+VOIP

http://en.wikipedia.org/wiki/UDP_hole_punching

http://www.h-online.com/security/features/How-Skype-Co-get-round-firewalls-747197.html

, wenn Sie einen Sprachdienst von einer Art der Umsetzung, ein System wie FreeSWITCH® die meisten der bietet Tools, die Sie benötigen, um Medien an verteilte Clients zu senden:

http://www.freeswitch.org/

Answer 2

Ich sehe die Frage 3 Jahre überfällig ist, aber ich sehe keine Antwort akzeptiert, also werde ich es

1- Ihre Aussagen sind korrekt

2- richtig, TCP einen Schuss nehmen oder UDP kann für den Audio-Stream verwendet werden.

3- Die Kombination von tcp und udp für den Audio-Stream ist nicht sinnvoll. Wenn UDP für die Übertragung zum Server arbeitet, funktioniert es für den Empfang, so arbeiten alle NAT-Firewalls, dh sie senden Datagramme, die vom internen Host empfangen werden, an Remote-Hosts, nachdem sie den IP-Header geändert haben Wenn sie eine Antwort erhalten, leiten sie sie zurück an den internen Host. Der Unterschied zwischen NAT-Firewalls besteht darin, wie lange der NAT-Tunnel am Leben bleiben wird, aber dies ist für den Audioteil des Anrufs nicht von Bedeutung, da während eines Anrufs ein konstanter Audiofluss in beide Richtungen stattfindet. Dies würde mehr für den Signalisierungsteil des Anrufs wichtig sein, der das SIP-Protokoll verwendet. Daher würde ich empfehlen, TCP für SIP zu verwenden, da die TCP-Sitzung ein Standard-Timeout von 900s hat, wodurch die Keep Alive-Nachrichten weniger häufig benötigt werden.

Jetzt verwenden einige Anwendungen, die Sie erwähnten, SIP nicht für Sitzungsinitiierung und haben daher proprietäre Arten der Signalisierung.

Andere Anwendungen nutzen das sogenannte "Lochen", um Client-zu-Client-Direktkommunikation (oder Peer-to-Peer) wie Skype zu ermöglichen. Der Vorteil liegt darin, dass der Server nicht in der Mitte des Voice-Streams bleibt. Dies kann die Latenz effektiv reduzieren und TCP zu einer potenziellen Wahl für den Audio-Stream machen.

Die Entwickler von Asterisk, der berühmten OpenSource-PBX, haben die SIP-Probleme erkannt, die viele offene Ports erfordern. Sie haben ihr eigenes Protokoll namens IAX entwickelt, um Signalisierung und Medien über einen Port zu übertragen. Ich würde Sie ermutigen, die Implementierung von IAX für Ihren Client/Server in Betracht zu ziehen, da es sicherstellt, dass, wenn ein Client in der Lage ist, eine Verbindung herzustellen (durch Signalisierung), er Anrufe tätigen kann.