tcp - funcionamiento - protocolo sip pdf
con SIP, cuando usar TCP no UDP? (5)
Muchas personas generalmente asocian UDP con voip y probablemente lo dejen así, pero en términos simples hay dos partes para voip: conexión y transferencia de datos de voz.
SIP es un protocolo muy liviano, una vez que se establecen las conexiones, se deja inactivo hasta el evento poco frecuente de que alguien realice una llamada telefónica. TCP (a diferencia de UDP) realmente reducirá el tráfico al servidor al eliminar la necesidad de hacerlo;
- Vuelva a registrarse cada pocos minutos
- Servidor de actualización / ping
Puede ejecutar SIP sobre TCP y luego usar (como se recomienda) UDP para RTP.
No pude evitar señalar las cosas obvias que he examinado. P.ej. Número de dispositivos conectados al servidor. A medida que el número crece, la ecuación se inclina en favor de los UDP. Pero también debe considerar la posibilidad de expandir los Agentes de usuario SIP para cubrir múltiples códecs, multimedia, video y pantalla compartida. Los paquetes INVITE pueden comenzar a crecer y potencialmente correr sobre el tamaño del datagrama único de UDP, inclinando la ecuación nuevamente a favor de TCP.
Dicho todo esto, espero que tenga suficiente información para responder la pregunta que desea responder.
Espero que esto ayude.
Crédito: La maravillosa discusión en onSip: https://www.onsip.com/blog/sip-via-udp-vs-tcp
Sé muy bien las diferencias entre UDP y TCP en general (por ejemplo, http://www.onsip.com/about-voip/sip/udp-versus-tcp-for-voip )
La pregunta es, ¿en qué circunstancias el uso de TCP como transporte tendría ventajas específicamente bajo las comunicaciones SIP VOiP?
No puede ensamblar de manera confiable una transmisión de audio desde un protocolo basado en TCP. En audio, es mucho mejor perder un paquete que tener un paquete retransmitido debido a una caída de paquete. El audio no funciona si hay una fluctuación excesiva en la sincronización del paquete. El audio es en tiempo real y requiere un protocolo como UDP para funcionar correctamente. La pérdida de paquetes no rompe el audio, solo reduce la calidad. La entrega perfecta de TCP no ayuda al audio de ninguna manera, no puede haber calidad si obtiene el 100% de los paquetes, pero no están en tiempo real. En audio, es el tiempo (latencia, jitter) lo que determina la calidad más que la integridad de los datos.
Este sorbo funciona MEJOR cuando la señal y el control están sobre TCP pero los datos de voz están sobre UDP.
He estado trabajando con la transmisión de voz digital a través de protocolos de red desde que diseñé uno de los primeros teléfonos inteligentes en 1987 para la red celular digital emergente en Japón. Desde 1987, el único aspecto de la transmisión de voz digital que no ha cambiado es lo que describo aquí. La naturaleza en tiempo real de la transmisión de audio (voz) y cómo afecta el diseño del sistema sigue siendo exactamente la misma que en los días de los dinosaurios de los que vengo.
SIP sobre TCP tiene una ventaja significativa sobre UDP para dispositivos móviles. El motivo se debe al uso de NAT y al hecho de que las entradas de la tabla NAT en un enrutador inalámbrico o en el enrutador de un proveedor de telefonía celular generalmente se agotan más rápidamente para UDP frente a TCP. Dado que es necesario mantener la misma entrada de la tabla NAT para poder recibir llamadas de manera confiable, SIP debe enviar periódicamente keep-alives para mantener la entrada de la tabla NAT. La frecuencia requerida de keep-alives es mucho mayor para UDP (quizás cada 30 segundos) frente a TCP (tal vez cada 15 minutos), lo que resulta en un uso de la batería del dispositivo móvil notablemente mayor. A menudo, cuando ve a alguien quejándose de cómo su uso de la batería tiene un gran impacto cuando usa un cliente VOIP, es porque el cliente está usando UDP.
Entonces, TCP gana sobre UDP indiscutiblemente para dispositivos móviles.
Tenga en cuenta que lo anterior asume que desea poder recibir llamadas de manera confiable en su dispositivo móvil. Si todo lo que quieres hacer es poder hacer llamadas, entonces es una historia diferente.
TCP puede pasar con perfecta claridad en una conexión con pérdida, cuando UDP puede no ser comprensible. Obtienes una latencia menor con UDP, pero eso no te ayuda si no puedes entender lo que se dice.
Si un mensaje es grande (dentro de 200 bytes del tamaño de MTU), la sección 18.1.1 del RFC 3261 exige el uso de TCP (para ser precisos, exige el uso de un "protocolo de transporte controlado por congestión, como TCP"). Lo logré en la práctica al enviar un INVITE inicial con muchos encabezados y un URI de solicitud complejo.