Comunicación de voz sobre TCP/IP

Question

Actualmente estoy desarrollando aplicaciones usando DirectSound para la comunicación en una intranet. He tenido una solución de trabajo usando UDP pero luego mi jefe me dijo que quería usar TCP/IP por alguna razón. Intenté implementarlo casi de la misma forma que UDP, pero con muy poco éxito. Lo que obtengo es básicamente ruido. 20% es el sonido grabado y el resto es ruido extraño.

Mi suposición de que la razón es que el TCP necesita leer todos los datos aceptados varias veces hasta que se pone el sonido final que puedo jugar.

Ahora dos preguntas:

• estoy en el camino correcto? ¿Es incluso una buena idea usar TCP/IP para este tipo de aplicación (tipo de conferencia de voz)?
• Lo estoy haciendo en C#, pero no creo que esto sea específico del idioma.

Answer 1

No, usando TCP es idea terrible. ¡UDP en este caso funcionará mucho mejor y los paquetes de sincronización eliminados no importarán!

Si su jefe no puede entender los detalles técnicos, él o ella decir que prácticamente todos los sistemas de VoIP existentes en la actualidad el uso de UDP y tiene que haber una razón: Skype, Ventrilo, TeamSpeak, World of Warcraft de, etc

Answer 2

TCP/IP funcionaría; entregará los datos. Puede que no sea tan eficiente como UDP si no te preocupas por la pérdida de paquetes, pero deberías poder transmitir los datos muy bien.

Answer 3

TCP/IP sobre enrutadores y redes modernos es muy rápido. Es más que capaz de manejar comunicaciones de voz sobre IP. (Lo he hecho yo)

Mi conjetura es que su aplicación tiene algunos errores en ella relacionados para amortiguar los tamaños.

Answer 4

Hay algunas razones principales por las que los datos de transmisión en vivo usan UDP. El más grande de los cuales es recibir datos tardíos es tan bueno como no recibirlo en absoluto, y retrasar el flujo de retransmisión ciertamente no es una buena idea. Para VoIP, tiene una tolerancia a la latencia de alrededor de 150 ms. Cualquier paquete de voz que se demore más que eso se vuelve notable para los usuarios.

cuanto a por qué usted está recibiendo el ruido, ¿cómo estás manejando finales de los paquetes que llegan debido a retransmite?

Answer 5

Cuando las personas están hablando de la pila TCP/IP que a menudo significan "toda la pila de protocolo de Internet", que incluye UDP. Tal vez eso hace feliz a tu gerente ;-)

Answer 6

Depende del tipo de red subyacente, si tienes Ethernet con una confiabilidad del 99.9%, mi suposición es que TCP funcionaría bien. Sin embargo, si lo haces en 802.11, entonces TCP sería una idea no tan buena.

Puede preguntarle a su jefe por un motivo específico para usar TCP y luego implementar ese servicio en particular, por ejemplo, confiabilidad básica, o un servicio de corrección de errores en UDP. También te mirar en RTP. (http://en.wikipedia.org/wiki/Real-time_Transport_Protocol)

Answer 7

TCP debe no genere ningún ruido. Jitter y retraso, sí (especialmente si sus enlaces son con pérdida); pero no hay ruido en absoluto. Algo es sospechoso con tu programación.

BTW, coincido en que UDP es mucho más apropiado que TCP en este caso.

Answer 8

La mayoría de las aplicaciones de voz se compilan utilizando el protocolo RTP que se transmite a través del puerto UDP. Bueno, la mayoría de ellos con soporte de códec para garantizar que los medios se comprimen antes de transmitir de un extremo a otro. Hable con su jefe sobre los requisitos de ancho de banda.

Answer 9

Estoy bastante seguro de que la mayoría de la transmisión de audio/video usa UDP ... es posible que pierda algunos paquetes, pero nunca se daría cuenta.

Answer 10

No hay ninguna razón por la cual debería recibir ruido por TCP y, por lo tanto, parece un error en su código. De hecho, la mayoría de los medios de transmisión que recibimos (piense en YouTube) se hacen a través de TCP.

El problema con TCP es jitter. La entrega de su flujo de datos se retrasará hasta que todos los paquetes hayan sido recibidos y reordenados. Ahora, dado que la entrega tardía para multimedia es tan buena como la falta de entrega. Esta es normalmente una opción más pobre que la simple interpolación del marco faltante. Como se mencionó anteriormente, si la pérdida de paquetes es mínima y su red es rápida, no debería hacer ninguna diferencia.

RTP/RTCP sobre UDP se utiliza normalmente para la entrega de la secuencia de medios. RTP incluye cosas como los números de secuencia en el encabezado del paquete que permiten la inserción de los paquetes retrasados ​​en su posición correcta, siempre que sea posible. RTCP tiene una función de informe que permite al códec adaptarse a situaciones donde la pérdida de paquetes comienza a ser mayor. Por lo tanto, RTP/RTCP proporciona algunas, pero no todas, la funcionalidad TCP.

Para la transmisión de medios a través de TCP, esto se puede resolver fácilmente teniendo un gran buffer de fluctuación de fase. Esto agrega latencia, pero para la transmisión en un solo sentido, esto no es un problema. La latencia, sin embargo, es un problema importante en la transmisión bidireccional conversacional.

Una ventaja principal de TCP, sin embargo, es que atraviesa cortafuegos más fácilmente que UDP. Una sesión TCP está establecida, el firewall está abierto tanto para enviar como para recibir datos. Esto es más complicado para UDP especialmente cuando uno está esperando una corriente de datos entrante. Hay formas de evitar esto, pero pueden ser complicadas y pueden implicar la comprensión del protocolo de control de sesión (como SIP o RTSP).

Answer 11

Para responder correctamente a esta pregunta, creo que algunos de los conceptos clave de VoIP deben explicarse.

En primer lugar, la UDP es ampliamente utilizado método más popular y para VoIP. Recuerde que una red IP es conmutada por paquetes e ideal para la comunicación de datos en tiempo no real y no está diseñada para VoIP en tiempo real.

Para solucionar este problema, se usa UDP. UDP es un protocolo no confiable y sin conexión. Aunque UDP perderá paquetes, el audio del habla aún se puede entender, el cerebro compensará de manera efectiva los errores. Es por eso que todavía puede hablar con alguien por teléfono con 3 barras de señal.

pérdida de paquetes y longitudes de ráfaga

La pérdida de paquetes a menudo se produce debido a la congestión, por lo que la cantidad de pérdida de paquetes dependerá de lo bien equipada la red es. La pérdida de paquetes en VoIP usando UDP ocurrirá con mayor frecuencia en longitudes de ráfaga. A longitud de ráfaga es el número de paquetes perdidos en sucesión en la transmisión, por lo que una longitud de ráfaga de 3 significa 3 paquetes en una fila se perdieron.

remuneración de la pérdida de paquetes

¿Dónde se produce la pérdida de paquetes simples técnicas de compensación de pérdida de paquetes se Surfice y la calidad del servicio no se verá seriamente efectuado, el habla puede todavía ser entendido incluso en los casos en que el 20-30% de los paquetes Esta perdido. Los métodos incluyen:

1. Repetir el último éxito paquete recibido.

2. Rellene - Juega el silencio en la brecha.

3. Empalme - Efectivamente, esto puede ser idea de tomar la eliminación la brecha causada por la longitud de la ráfaga empujando el inicio y el final de la brecha juntos.

4. Interpolación - Usar el conocimiento de discurso antes y después para Interpolar paquetes perdidos dentro de la brecha por ejemplo significa entre los paquetes recibidos con éxito antes y después de la duración de la ráfaga.

Un buen método para reducir el tamaño de las longitudes de ráfaga es conocido como el intercalado y por lo tanto el aumento de QoS es entrelazado. Una función de intercalación de bloques toma el discurso y lo divide en un conjunto de paquetes. Estos paquetes se cargan en un búfer con la forma de una matriz (por ejemplo, 4 por 4), se utiliza una función para rotar o transponer el búfer para que los paquetes no estén en orden. En el lado del receptor, el inverso de esta función se usa para reordenar los paquetes. Este método es simple y eficaz, ver la figura siguiente:

alt text http://img688.imageshack.us/img688/3962/capturevnk.png

recientemente he creado una pequeña aplicación VoIP. a través de una LAN inalámbrica usando UDP. No estoy realmente seguro de los requisitos exactos de su aplicación, pero en general las aplicaciones de VoIP (entre dos hosts) se implementa como sigue:

alt text http://img338.imageshack.us/img338/6566/captureec.png

En el diagrama de la aplicación define su propio diseño del paquete. El encabezado podría ser simplemente el número de paquete (usando 1 byte) y la carga útil de los datos de audio (n bytes, tamaño de la carga útil). Definir esto permite mejores técnicas de compensación de paquetes y permite un flujo lógico para la programación.

TCP es una mala elección para VoIP por varias razones. Un rápido google de 'TCP VoIP' revela por qué el primer resultado respalda este view.

TCP es un protocolo confiable, orientado a la conexión, esto significa que los paquetes que se pierden en la transmisión en algún momento serán reenviados desde el otro host. Esta retransmisión no es práctica para los servicios en tiempo real y aumentará la trepidación, la latencia y posiblemente aumentará la pérdida de paquetes (en algunos casos).

respuestas a sus preguntas

Lo que consigue es, básicamente, sólo ruido. 20% es el sonido grabado y el resto es ruido extraño.

TCP no debe introducir ruido, debe introducir jitter y latencia. Los conectores tienden a tener un tiempo de espera definido automáticamente, ¿define el tiempo de espera? Si no es así, ¿por qué no recibes el paquete correcto a tiempo antes de la reproducción?

¿Estoy en las pistas correctas? ¿Es incluso una buena idea usar TCP/IP para este tipo de aplicación (tipo de conferencia de voz)?

No haga NO use TCP/IP no es una buena idea. Parece que su gerente ha asumido incorrectamente que cualquier pérdida de paquetes es algo terrible.

Resumen

Algunos conceptos generales se han mostrado aquí para tratar de ayudar lo más posible para este problema específico, sin embargo, esto no debe considerarse exhaustiva. Asegúrese de que el sistema VoIP también utiliza algunos principios subyacentes de las técnicas de codificación de voz/procesamiento de señales.

Los puntos clave a tener en cuenta son:

• Uso UDP para VoIP.

• Implementar la compensación de pérdida de paquetes
  técnicas.

• Un intercalador de bloques es un método simple y
  eficaz para aumentar la QoS.

Espero que esto ayude.

Answer 12

Si recibe ruido, probablemente esté sobrepasando la parte de su búfer que se ha llenado satisfactoriamente con paquetes y jugando el búfer vacío/no inicializado.

Answer 13

He desarrollado una solución de voz oper ip para una comunicación dúplex con wave-api para el control remoto de un tranceiver de radio aficionado. ¡Funciona muy bien con UDP y también con TCI/IP! Uso un buffer de 512 bytes cada 64 ms, datos de onda Mono de 8kHz. ¡Tengo trabajo en el último mes entre USA y Europa Verry sobre TCP/IP! Ahora mi pregunta: la aplicación de onda no funciona correctamente con Win7, por lo tanto, creo que DirectSound es la mejor manera. Justo en el momento en que tengo Trubble con la implementación bajo Managed DirectX9, mi aplicación es VB.Net 2008. Busco enlaces a la documentación para una salida de transmisión con DirectSound - ManagedDirectX9 para VB.Net.

Answer 14

¿Cuánto más lento es TCP que UDP? Con TCP obtendrá un retraso de retransmisión si algún paquete llega fuera de servicio o dañado. Diré que hay formas de optimizar el TCP para que haya menos demoras. Tanto en Linux como en Winsock hay una opción TCP_NODELAY para usar. También un códec compacto ayudará como G.729 a mantener el tamaño de la carga útil. Dado que la transmisión se basa en los paquetes que se reciben (en orden - TCP) uno debe enfocarse en optimizar el tamaño del paquete para que sea lo suficientemente pequeño como para reducir la demora de retransmisión pero lo suficientemente grande como para mantener un flujo de calidad. Un buen programa de VoIP TCP tendría la capacidad de variar la calidad de codificación y el tamaño del paquete sobre la marcha, donde el emisor tendría que enviar una señal al receptor del cambio. Pero realmente la única ventaja de usar TCP para tiempo real es que es menos probable que sea bloqueado por firewalls.