language agnostic - Comunicación de voz sobre TCP/IP

language-agnostic networking (14)

Cuando las personas hablan de la pila TCP / IP, a menudo significan "la pila completa de protocolos de Internet", que incluye UDP. Tal vez eso hace feliz a tu gerente ;-)

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.

Creo que la razón es que TCP necesita leer todos los datos aceptados varias veces hasta que obtenga el sonido final que puedo reproducir.

Ahora dos preguntas:

¿Estoy en las pistas correctas? ¿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.

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 una razón específica para usar TCP y luego implementar ese servicio particular, por ejemplo, confiabilidad básica, o un servicio de corrección de errores en UDP. También podría consultar RTP. ( Http://en.wikipedia.org/wiki/Real-time_Transport_Protocol )

Estoy bastante seguro de que la mayoría de las transmisiones de audio / video usan UDP ... es posible que pierdas algunos paquetes, pero nunca lo notarías.

Hay algunos motivos principales por los 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.

En cuanto a por qué está recibiendo ruido, ¿cómo está manejando los paquetes que llegan tarde debido a las retransmisiones?

La mayoría de las aplicaciones de voz se compilan utilizando el protocolo RTP, que es transmisión por 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. Discuta con su jefe sobre los requisitos de ancho de banda.

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 peor 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 que el códec se adapte a las 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.

Sin embargo, una de las principales ventajas de TCP es que atraviesa cortafuegos más fácilmente que UDP. Una vez que se establece una sesión TCP, 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).

No, usar TCP es una 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, dígale que prácticamente todos los sistemas VOIP que existen actualmente usan UDP y debe haber una razón: Skype, ventrilo, teamspeak, World of Warcraft, etc.

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.

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 mismo)

Supongo que su implementación tiene algunos errores relacionados con los tamaños del buffer.

TCP no debe introducir 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.

Por cierto, estoy de acuerdo en que UDP es mucho más apropiado que TCP en este caso.

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

En primer lugar, UDP es el método más popular y ampliamente utilizado 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 superar 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 ocurre debido a la congestión, por lo que la cantidad de pérdida de paquetes dependerá de cuán bien equipada esté la red. La pérdida de paquetes en VoIP usando UDP ocurrirá con mayor frecuencia en las longitudes de ráfaga. Una 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.

Compensación por pérdida de paquetes

Donde ocurra la pérdida de paquetes, las técnicas simples de compensación de pérdidas de paquetes se navegarán y la calidad del servicio no se verá seriamente afectada, el habla aún se puede entender incluso en los casos en que se pierde el 20-30% de los paquetes. Los métodos incluyen:

Repita el último paquete recibido con éxito.
Complete - Juegue silencio en el espacio.
Empalme - Efectivamente, se puede pensar en eliminar la brecha causada por la longitud de la ráfaga empujando el inicio y el final de la separación.
Interpolación: utilice el conocimiento del habla antes y después para interpolar paquetes perdidos dentro del espacio, por ejemplo, la media 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 se conoce como entrelazado y, por lo tanto, el aumento de la 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 usa 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 efectivo. Vea la figura a continuación:

texto alternativo http://img688.imageshack.us/img688/3962/capturevnk.png

Recientemente creé una pequeña aplicación de VoIP. a través de una LAN inalámbrica usando UDP. No estoy seguro de los requisitos exactos de su aplicación, pero generalmente las aplicaciones de VoIP (entre dos hosts) pueden implementarse de la siguiente manera:

texto alternativo http://img338.imageshack.us/img338/6566/captureec.png

En el diagrama, la aplicación define su propio diseño de 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 esta vista .

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 tus preguntas

Lo que obtengo es básicamente ruido. 20% es el sonido grabado y el resto es ruido extraño.

TCP no debe introducir ruido, debe introducir jitter y latencia. Los sockets 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, 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 clave generales se han mostrado aquí para tratar de ayudar tanto como sea posible para este problema específico, sin embargo, esto no debe considerarse exhaustivo. 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ñal.

Los puntos clave para recordar son:

Use UDP para VoIP.
Implementar la compensación de pérdida de paquetes
técnicas.
Un intercalador de bloques es un simple y
método efectivo para aumentar la QoS.

Espero que esto ayude.

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

Desarrollé una solución de voz por 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.

¿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.