Communication Voix sur TCP / IP

https://stackoverflow.com/questions/1946731

20-09-2019
|

Question

Je demande actuellement le développement en utilisant DirectSound pour la communication sur un intranet. J'ai eu la solution de travail en utilisant UDP mais mon patron m'a dit qu'il veut utiliser pour une raison quelconque TCP / IP. J'ai essayé de le mettre en œuvre dans à peu près la même manière que UDP, mais avec très peu de succès. Ce que je reçois est fondamentalement juste le bruit. 20% de celui-ci est le son enregistré et le reste est juste un bruit bizarre.

Je pense pour la raison est que TCP doit lire toutes les données acceptées à plusieurs reprises jusqu'à ce qu'il obtienne le son final je peux jouer.

Maintenant deux questions:

Suis-je sur la bonne voie? Est-il même une bonne idée d'utiliser TCP / IP pour ce type d'application (conférence vocale de toutes sortes)?
Je le fais en C #, mais je ne pense pas que ce soit un langage spécifique.

La solution

Non, en utilisant TCP est une idée terrible . UDP dans ce cas se produira beaucoup mieux et laissé tomber / de paquets de synchronisation ne sera pas question!

Si votre patron ne peut pas comprendre les détails techniques, dites-lui que pratiquement tous les systèmes de VOIP UDP utilisent actuellement existants et il doit y avoir une raison: Skype, Ventrilo, Teamspeak, World of Warcraft de, etc

Autres conseils

Pour répondre correctement à cette question, je pense que certains des concepts clés de VoIP doivent être expliqués.

Tout d'abord, UDP est le le plus populaire méthode et largement utilisé pour la VoIP. Rappelez-vous qu'un réseau IP est à commutation de paquets et idéal pour la communication de données en temps non réel et non conçu pour la VoIP en temps réel.

Pour remédier à ce problème UDP est utilisé. UDP est un protocole non fiable et sans connexion. Bien que UDP va perdre des paquets audio de la parole peut encore être comprise, le cerveau compense efficacement les erreurs. C'est pourquoi vous pouvez toujours parler à quelqu'un sur un téléphone avec 3 barres de signaux.

perte de paquets et d'éclatement Longueurs

La perte de paquets se produit souvent en raison de la congestion, de sorte que le montant de la perte de paquets dépendra de la façon dont le réseau est équipé. La perte de paquets en VoIP en utilisant UDP se produit le plus souvent dans des longueurs d'éclatement . longueur éclater est le nombre de paquets perdus successivement dans la transmission, donc une longueur de rafale de 3 moyens 3 paquets de suite ont été perdus.

Compensation de perte de paquets

En cas de perte de paquets se produit des techniques simples de compensation de perte de paquets se surfice et la qualité de service ne sera pas sérieusement effectué, la parole peut être compris encore, même dans les cas où 20-30% des paquets sont perdus. Ces méthodes comprennent:

Répétez le dernier succès paquet reçu.
Remplissez -. Jouez le silence dans l'espace
Splicing - Effectivement, cela peut être pensé à prendre la suppression l'écart causé par la longueur de rafale en poussant le début et la fin de la gap ensemble.
Interpolation - Utiliser des la parole avant et après la interpoler paquets perdus dans le par exemple écart dire entre les paquets avec succès recus avant et après la longueur de salve.

Une bonne méthode de réduction de la taille des longueurs de salve est connu comme entrelacement et donc d'augmenter la qualité de service est entrelacement . Une fonction d'entrelacement de blocs prend la parole et il se divise en une série de paquets. Ces paquets sont chargés dans une mémoire tampon la forme d'une matrice (par exemple 4 par 4), une fonction permet une rotation ou transposition de la mémoire tampon de sorte que les paquets ne sont pas dans l'ordre. Du côté de recepteur l'inverse de cette fonction est utilisée pour réordonner les paquets. Cette méthode est simple et efficace, voir la figure ci-dessous:

texte alt http://img688.imageshack.us/img688/3962/capturevnk. PNG

J'ai récemment créé une petite application VoIP. sur un réseau local sans fil en utilisant UDP. Je ne suis pas vraiment sûr des besoins exacts de votre application, mais généralement les applications VoIP (entre deux hôtes) peuvent mis en œuvre comme suit:

texte alt http://img338.imageshack.us/img338/6566/captureec. PNG

Dans le diagramme de l'application définit son propre conception de paquets. L'en-tête pourrait être simplement le numéro de paquet (en utilisant 1 octet) et la charge utile des données audio (n octets, la taille de la charge utile). Définir ce qui permet de meilleures techniques de compensation de paquets et permet un flux logique pour la programmation.

TCP est un mauvais choix pour la VoIP pour plusieurs raisons. Un rapide Google de « TCP VoIP » révèle pourquoi le premier résultat pour appuyer cette vue .

TCP est un protocole fiable, orrientated connexion, cela signifie que les paquets qui sont perdus dans la transmission seront à un moment donné être renvoyés de l'autre hôte. Cette retransmission est peu pratique pour les services en temps réel et augmentera la gigue, la latence et peut-être augmenter la perte de paquets (dans certains cas).

Les réponses à vos questions

Qu'est-ce que je reçois est fondamentalement juste le bruit. 20% de celui-ci est le son enregistré et le reste est just bruit bizarre.

TCP ne doit pas introduire du bruit, il faut introduire la gigue et la latence. Prises ont tendance à avoir un temps de temps out défini automatiquement, définissez-vous le temps de temporisation? Sinon ce qui se passe pourquoi vous ne recevez pas le paquet correct dans le temps avant la lecture?

Suis-je sur la bonne voie? Est-il même une bonne idée d'utiliser TCP / IP pour ce type d'application (conférence vocale de toutes sortes)?

Non do PAS utiliser TCP / IP, il est pas une bonne idée. Il semble que votre gestionnaire a supposé à tort que toute perte de paquets est une chose terrible.

Résumé

Quelques concepts clés généraux ont été montrés ici pour essayer d'aider autant que possible à ce problème spécifique, mais cela ne devrait pas être considérée comme exhaustive. Assurez-vous que le système VoIP utilise également certains principes sous-jacents des techniques de codage / de traitement du signal de parole.

Les principaux points à retenir sont:

Utilisez UDP pour la VoIP.
Mettre en oeuvre une compensation de perte de paquets
techniques.
Un entrelaceur de bloc est un simple et
méthode efficace pour augmenter la qualité de service.

J'espère que cette aide.

Quand les gens parlent de la pile TCP / IP, ils signifient souvent « l'ensemble de la pile de protocole Internet » qui inclut UDP. Peut-être qui rend votre gestionnaire heureux; -)

TCP / IP fonctionnerait; il fournira les données. Il pourrait ne pas être aussi efficace que UDP si vous ne pas se soucier de la perte de paquets, mais vous devriez être en mesure de transmettre les données très bien.

TCP / IP sur les routeurs modernes et des réseaux est très rapide. Il est plus que capable de gérer la voix sur IP communication. (Je l'ai fait moi-même)

Je pense que votre implémentation a quelques bugs dans ce tampon lié à la taille.

Il n'y a aucune raison pour laquelle vous devriez obtenir le bruit sur TCP et il semble donc comme un bug dans votre code. En fait la plupart des médias en streaming que nous recevons (pensez YouTube) sont effectués sur TCP.

Le problème avec TCP est la gigue. La livraison de votre flux de données sera retardée jusqu'à ce que tous les paquets ont été reçus et réorganisés. Maintenant, depuis la livraison tardive pour le multimédia est aussi bon que pas de livraison du tout. Ceci est normalement un choix plus pauvre que interpoler simplement le cadre manquant. Comme mentionné ci-dessus, en cas de perte de paquets est minime et votre réseau rapide, il ne devrait pas faire de différence.

RTP / RTCP sur UDP est normalement utilisé pour la délivrance de flux multimédia. RTP inclut des choses comme les numéros de séquence dans l'en-tête de paquet qui permettent l'insertion de paquets dans leur retard position correcte, lorsque cela est possible. RTCP a une fonction de reporting qui permet au codec de s'adapter à situaltions où la perte de paquets commence à devenir plus élevé. RTP / RTCP fournit donc un peu, mais pas toutes les fonctionnalités TCP.

Pour la diffusion des médias sur TCP, cela peut être facilement résolu en ayant une grande mémoire tampon de gigue. Cela ajoute de la latence mais à sens unique de streaming ce n'est pas un problème. Latence, est cependant un problème majeur en streaming dans les deux sens conversationnel.

Un avantage principal TCP, cependant, est qu'il traverse plus facilement les pare-feu que UDP. Une session TCP est établie le pare-feu est ouvert à la fois à envoyer et recevoir des données. Ceci est plus compliqué pour UDP surtout quand on attend un flux entrant de données. Il y a des moyens de contourner cela, mais ils peuvent être complexes et peuvent impliquer comprendre le protocole de contrôle de session (comme SIP ou RTSP).

J'ai développé une solution Oper vocale IP pour une comunication duplex avec onde api pour le contrôle à distance d'un émetteur-récepteur radio amateur. Il fonctionne bien avec verry UDP et aussi avec TCI / IP! J'utilise 512 octets du tampon chaque 64 ms, 8kHz Mono données d'onde. J'ai du travail au cours du dernier mois entre les Etats-Unis et europa verry bien sur TCP / IP! Ma question: La vague-api ne fonctionnent pas correctement avec Win7, je pense donc DirectSound son de la meilleure façon. Juste à tim J'ai l'esprit trubble la mise en œuvre sous DirectX9 Managed, ma demande est VB.Net 2008. Je recherche des liens vers la documentation pour une sortie en continu avec DirectSound - ManagedDirectX9 pour VB.Net.

Il y a quelques raisons principales pour lesquelles les données en streaming en direct utilise UDP. Le plus grand qui reçoit des données en retard est aussi bonne que ne recevant pas du tout, et retarder le flux de retransmission est certainement pas une bonne idée. Pour VoIP, vous avez une tolérance de latence de quelque part autour de 150ms. Tout paquet de voix qui est retardé plus longtemps que cela devient perceptible pour les utilisateurs.

Quant à savoir pourquoi vous obtenez le bruit, comment gérez-vous la fin de paquets arrivant en raison de réémet?

Cela dépend du type de réseau sous-jacent, si vous avez Ethernet avec une fiabilité de 99,9%, je suppose TCP serait très bien. Toutefois, si vous le faites dire sur 802,11 alors TCP serait pas si bonne idée.

Vous pouvez demander à votre patron pour une raison particulière d'utiliser TCP et puis mettre en œuvre ce service particulier, par exemple la fiabilité de base, ou un service de correction d'erreur sur UDP. Vous pouvez également vous regarder dans RTP. ( http://en.wikipedia.org/wiki/ réel time_Transport_Protocol)

TCP devrait pas introduire un bruit. Jitter et lag, oui (surtout si vos liens sont lossy); mais pas de bruit du tout. Quelque chose est louche avec votre programmation.

BTW, je suis d'accord que UDP est beaucoup plus approprié que TCP dans ce cas.

La plupart des applications de voix sont construites en utilisant le protocole RTP qui est flux sur le port UDP. Eh bien la plupart d'entre eux avec le soutien codec pour assurer les médias sont compressés avant flux d'un bout à l'autre. Discutez avec votre patron au sujet des besoins en bande passante.

Je suis assez sûr audio le plus en streaming / vidéo utilise UDP ... vous risquez de perdre quelques paquets, mais vous ne remarquerez jamais.

Si vous obtenez le bruit, vous êtes probablement la partie dépassement de votre tampon qui a rempli avec succès avec des paquets, et en jouant un tampon vide / non initialisée.

Combien est plus lent que TCP UDP? Avec TCP vous obtenez un délai de retransmission si des paquets arrivent hors d'usage ou corrompu. Je dirais qu'il ya des façons d'optimiser TCP donc il y a moins de retard. Dans les deux Linux et Winsock il y a une option TCP_NODELAY à utiliser. Aussi un codec compact vous aidera comme G.729 à maintenir la taille de la charge utile vers le bas. Étant donné que la transmission est basée sur les paquets en cours de réception (dans l'ordre - TCP) on devrait se concentrer sur l'optimisation de la taille du paquet pour être assez petit pour réduire les délais de retransmission, mais assez grand pour maintenir un flux de qualité. Un bon programme TCP voip aurait la possibilité de faire varier la qualité d'encodage et la taille des paquets à la volée où l'expéditeur devrait signaler au récepteur du changement. Mais vraiment le seul advntage d'utiliser TCP pour en temps réel est qu'il est moins susceptible d'être bloqué par les pare-feu.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow