Estructura de una aplicación de chat de voz (cliente/servidor)?

Question

Necesito una opinión de EXPERTO por favor, y lo siento si mi pregunta en sí es una pregunta confusa.

Estaba leyendo acerca de la estructura de las aplicaciones de VOIP (Cliente/Servidor). Y principalmente UDP se recomienda para transmisiones de voz. También verifiqué algunas aplicaciones de chat, como paltalk e inspeak, y sus sitios mencionan que usan la transmisión de voz udp que no parece correcta por los motivos que se exponen a continuación.

Examiné el tráfico/puertos utilizados por paltalk y inspeak. Tienen puertos UDP y TCP abiertos y usan un analizador de paquetes. Puedo ver que no hay mucha comunicación UDP pero sobre todo es la comunicación TCP en marcha.

También, por lo que sé, en el servidor de protocolo UDP no puede enviar datos a un cliente detrás de NAT (enrutador DSL). Y "UDP Braodcast" no es una opción para las aplicaciones de chat de voz basadas en "Internet". ESO ES POR QUÉ YAHOO HA MENCIONADO en su documentación que yahoo messenger cambia a tcp si la comunicación udp no es posible.

Así que mi pregunta es ....

1. Am i entender algo mal en mis declaraciones anteriores?

2. Si UDP no es posible, ¿esas aplicaciones de chat usan TCP Stream para voz?

3. Dado que he experimentado que las transmisiones de voz TCP crean demoras, Sin interrupción de voz pero Retraso en la voz, ¿cuál debería ser la mejor estructura para una comunicación de servidor/cliente de chat de voz?

hasta ahora creo que, si el cliente envía los datos en forma de paquetes UDP al servidor y servidor de distribuir los paquetes a los clientes a través de TCP arroyos, se trata de una solución adecuada? Quiero decir, ¿es esto lo que hacen las aplicaciones de voz comercial?

Gracias su respuesta nos ayudará a mí y a muchos otros programadores.

JF

Answer 1

UDP tiene menos gastos generales (en términos de tamaño total del paquete), por lo que se puede exprimir más audio en el ancho de banda del canal.

El UDP tampoco es confiable: los paquetes enviados pueden no recibirse o recibirse fuera de servicio, lo que está bien para aplicaciones de voz, ya que puede tolerar una pérdida de calidad de la señal y continuar. se puede tolerar una pequeña cantidad de paquetes perdidos (a diferencia de la descarga de un archivo, donde cada byte cuenta).

puede usar TCP? seguro, por qué no ... es un poco más sobrecarga, pero eso puede no importar.

SIP es un estándar de voz/medios que admite UDP y TCP. la mayoría de las implementaciones usan UDP debido a la menor sobrecarga.

El protocolo de Skype prefiere UDP siempre que sea posible, y vuelve a TCP.

en situaciones SIP, el problema de NAT se resuelve utilizando un paquete nat keep-alive (cualquier solicitud/respuesta de datos) para mantener el canal abierto, y explotando el hecho de que la mayoría de NAT aceptará respuestas en el mismo puerto de origen desde el que se abrió la conexión ... esto no es infalible, y a menudo requiere un servidor proxy que media la conexión entre 2 pares natos, pero se usa en muchas implementaciones.

STUN, TURN e ICE son métodos adicionales que ayudan con escenarios NAT, y especialmente en situaciones p2p (sin servidor).

información sobre temas de NAT y medios de comunicación:

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

si va a implementar un servicio de voz de algún tipo, un sistema como FreeSwitch proporciona la mayor parte del herramientas que necesita para entregar medios a clientes distribuidos:

http://www.freeswitch.org/

Answer 2

veo la cuestión es de 3 años de retraso, pero no veo ninguna respuesta aceptada, por lo que voy a tomar un tiro en él

1- sus declaraciones son correctas

2- correcta, TCP o UDP se puede utilizar para transmisión de audio.

3- La combinación de tcp y udp para la transmisión de audio no es útil. Si UDP funciona para la transmisión al servidor, funcionará para la recepción, así es como funcionan todos los cortafuegos NAT, es decir, envían el datagrama recibido del host interno al host remoto después de que cambian el encabezado ip para que el paquete parezca proceder de ellos, y cuando reciben respuesta, la reenvían al host interno. La diferencia entre los firewalls NAT es por cuánto tiempo el túnel NAT permanecerá activo, pero esto no tiene importancia para la parte de audio de la llamada, ya que hay un flujo constante de audio en ambos sentidos durante una llamada. Esto sería más importante para la parte de señalización de la llamada, que utiliza el protocolo SIP. Por lo tanto, recomendaría usar TCP para SIP, ya que la sesión TCP tiene un tiempo de espera predeterminado de 900 s, lo que hace que los mensajes de mantenimiento sean menos frecuentes.

Ahora algunas aplicaciones que mencionas no usan SIP para el inicio de la sesión, y por lo tanto tienen formas patentadas de señalización.

Otras aplicaciones aprovechan lo que se conoce como "perforado" para permitir la comunicación directa cliente a cliente (o peer-to-peer) como Skype. La ventaja de esto es que el servidor no permanece en el medio de la transmisión de voz, y esto puede reducir efectivamente la latencia, lo que hace que TCP sea una opción potencial para la transmisión de audio.

Los tipos detrás del desarrollo de Asterisk, el famoso opensource PBX, se han dado cuenta de los problemas en SIP que requieren tener muchos puertos abiertos, y han desarrollado su propio protocolo, llamado IAX, para transmitir señales y medios en un puerto. Le animo a que considere la implementación de IAX para su cliente/servidor, ya que asegura que si un cliente puede conectarse (a través de señalización), entonces puede hacer llamadas.