{"id":8168,"date":"2016-09-14T10:08:05","date_gmt":"2016-09-14T15:08:05","guid":{"rendered":"http:\/\/www.servervoip.com\/blog\/?p=8168"},"modified":"2019-06-07T11:13:33","modified_gmt":"2019-06-07T16:13:33","slug":"protocolos-de-transporte-en-toip","status":"publish","type":"post","link":"http:\/\/www.servervoip.com\/blog\/protocolos-de-transporte-en-toip\/","title":{"rendered":"Protocolos de transporte en ToIP"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n <\/div>\n
\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n <\/div>\n<\/div>\n
\n <\/span>\n <\/div>\n<\/div>\n

Protocolos de transporte: <\/strong> Los protocolos de transporte son los responsables de transportar en tiempo real la voz digitalizada y paquetizada sobre redes IP. Dado que se trata de un servicio de tiempo real, el nivel de transporte no puede ser TCP (las retransmisiones en los servicios orientados a conexi\u00f3n son incompatibles con los requisitos de los servicios interactivos de tiempo real como la voz). Como en UDP el transporte se realiza sin garant\u00edas, -modo best effort-, se requieren mecanismos que permitan la detecci\u00f3n de paquetes perdidos y\/o desordenados as\u00ed como que faciliten la gesti\u00f3n del almacenamiento (buffer) en el receptor.<\/p>\n

Para cubrir estos requisitos se desarroll\u00f3 el protocolo Realtime Transport Protocol (RTP) definido en la RFC 3550. Sus principales caracter\u00edsticas son :
\n\u2022\tTransporte datos en tiempo real, nivel aplicaci\u00f3n.
\n\u2022\tUnidireccional, sin garant\u00edas (marcado de paquetes o reserva de recursos).
\n\u2022\tIncorpora n\u00fameros de secuencia (para la detecci\u00f3n de paquetes perdidos y desordenados) y marcas temporales (time stamp) para la gesti\u00f3n del buffer de recepci\u00f3n.
\nEste protocolo se complement\u00f3 con el RTCP (RTP Control Protocol) definido tambi\u00e9n en la RFC 3550. Es un protocolo de control de RTP que se basa en el env\u00edo peri\u00f3dico de paquetes de control entre todos los participantes en la sesi\u00f3n mediante el cual \u00e9stos proporcionan informaci\u00f3n (feedback) del desarrollo de la misma.<\/p>\n

Protocolos de se\u00f1alizaci\u00f3n: H.323 y SIP <\/strong><\/p>\n

Los protocolos de se\u00f1alizaci\u00f3n permiten establecer y liberar la presencia (log-on y log-out) y localizar a los potenciales usuarios, as\u00ed como establecer, modificar y liberar sesiones propiamente dichas. En este contexto se desarrollaron dos grandes familias de protocolos: H.323 y SIP.<\/p>\n

H.323 es un conjunto de protocolos (protocol suite) definidos por la International Telecommunication Union (ITU) que incluye funcionalidades de:
\n\u2022\tCodificado de audio (G. 711, G. 722, G. 723, G. 728, G. 729) y video (H. 261 y H263)
\n\u2022\tTransporte (RTP, RTCP)
\n\u2022\tEstablecimiento y liberaci\u00f3n (log-on\/log-out) de presencia de potenciales usuarios (H. 225)
\n\u2022\tNegociaci\u00f3n de par\u00e1metros(codec, bitrate, …) (H. 245)
\n\u2022\tEstablecimiento y liberaci\u00f3n de llamadas (Q.931)<\/p>\n

SIP (Session Initiation Protocol, RFC 3261) es un protocolo dise\u00f1ado para iniciar, modificar y terminar sesiones multimedia (1 o m\u00e1s participantes). Es un protocolo muy simple desarrollado por la Internet Engineering Task Force (IETF) para simplificar al muy complejo H.323 que, a semejanza de HTTP y SMTP, se basa en mensajes de texto lo que le dota de una gran trazabilidad. Durante cierto tiempo coexistieron ambos, hasta que finalmente (finales de la d\u00e9cada de los 90) SIP se impuso, recibiendo su espaldarazo definitivo en 2000-2002 cuando fue elegido por IMS\/3GPP<\/p>\n

En SIP existen dos componentes b\u00e1sicos:<\/strong><\/p>\n

Agentes de usuario que incorporan las aplicaciones finales seg\u00fan el modelo cliente\/servidor:
\n\u2022\tUAC (user agents clients) que originan las llamadas
\n\u2022\tUAS (user agent server) a la espera de llamadas<\/p>\n

y agentes de red:<\/strong>
\n\u2022\tProxy server realizando funciones de relay (responde en nombre de) de llamadas (uas + uac)
\n\u2022\tRedirect server: redirecciona llamadas a otros servidores
\n\u2022\tRegistrar: donde los usuarios se registran (log-in\/log-out)<\/p>\n

A modo de ejemplos se incluyen los formatos de los mensajes m\u00e1s habituales en SIP:
\n\u2022\tEstablecimiento de llamada (invite):
\n\u2022\tRegistro de un usuario
\n\u2022\tProxy server
\n\u2022\tRedirect server<\/p>\n

ToIP y calidad de servicio <\/strong><\/p>\n

Como en cualquier otra aplicaci\u00f3n, las caracter\u00edsticas de la red tienen una importancia directa sobre la calidad de servicio percibida por los usurarios de ToIP. Los par\u00e1metros que inciden de una manera m\u00e1s determinante sobre la calidad de servicio son la latencia (o retardo), su variaci\u00f3n (o jitter) y la p\u00e9rdida de paquetes.<\/p>\n

La latencia se define como el tiempo que tarda un paquete de ToIP en su viaje entre origen y destino, siendo este par\u00e1metro el que m\u00e1s afecta (o uno de los que m\u00e1s puede afectar) a las caracter\u00edsticas subjetivas de calidad de servicio. La latencia tiene m\u00faltiples or\u00edgenes:<\/p>\n

\u2022\tCodificaci\u00f3n: el tiempo que el codec necesita para codificar (transmisor) y decodificar (receptor) la voz
\n\u2022\tPaquetizaci\u00f3n: el tiempo necesario para completar un paquete con muestras de voz
\n\u2022\tTransporte: el tiempo requerido para transportar el paquete entre ambos extremos (transmisor y receptor), incluyendo tanto la propagaci\u00f3n por las l\u00edneas de transmisi\u00f3n entre routers, como el empleado en la conmutaci\u00f3n y almacenamiento (queuing) en los routers de la red IP.
\n\u2022\tAlmacenamiento en el receptor (buffer jitter) para compensar las variaciones de retardo (jitter) entre paquetes pertenecientes a una misma sesi\u00f3n de ToIP<\/p>\n

[rev_slider captions]
\n[rev_slider ServerVoip]
\n <\/p>\n

\n

Se recomienda (ITU) mantener este par\u00e1metro por debajo de 150 ms. Valores comprendidos entre 100 y 150 ms son indetectables para el usuario final, entre 150 y 200 ms la calidad se considera aceptable, y el servicio no es aceptable cuando supera los 200 \u2013 300 ms.<\/p>\n

El retardo variable (jitter en terminolog\u00eda anglosajona) es una medida de las diferencias de los tiempos de llegada de los paquetes correspondientes a una llamada de ToIP al receptor. Para calcularlo, cuando el extremo receptor recibe un paquete obtiene el instante en que dicho paquete llega y lo compara con el que fue generado (marca temporal en el protocolo RTP): la diferencia entre ambos es el retardo variable que el paquete ha sufrido. Para compensarlo (el descodificador necesita un flujo de paquetes constante) el receptor almacena los paquetes recibidos (buffer jitter) antes de su procesado. El inconveniente de este m\u00e9todo es que cuanto mayor sea esta capacidad de almacenamiento (mayor compensaci\u00f3n de retardos variables) mayor es la latencia a\u00f1adida por lo que se buscan soluciones de compromiso adaptativas en las que el tama\u00f1o se ajusta a las condiciones cambiantes del retardo en la red.<\/p>\n

Como los paquetes de voz se env\u00edan sobre RTP (y TCP), en caso de p\u00e9rdida no se retransmiten y dicha p\u00e9rdida afecta directamente a la calidad de servicio percibida. El impacto de esta p\u00e9rdida de paquetes, originada en la red (congesti\u00f3n o errores) o en el receptor (desbordamiento o retardo excesivo en el buffer jitter), depende varios factores:
\n\u2022\tLa tipolog\u00eda (estad\u00edstica) de las p\u00e9rdidas: p\u00e9rdidas aleatorias ocasionales, que habitualmente el codec compensa (p.e. repitiendo la \u00faltima muestra recibida) o p\u00e9rdidas consecutivas (r\u00e1fagas) cuyos efectos son mucho m\u00e1s perniciosos.
\n\u2022\tEl tama\u00f1o del paquete de voz: cuanto mayor sea el paquete mayor ser\u00e1 la eficiencia (informaci\u00f3n \u00fatil\/informaci\u00f3n total transmitida) y mayor el impacto (se pierden mas muestras de voz) en caso de p\u00e9rdida.
\n\u2022\tEl codec: la compresi\u00f3n de la voz hace m\u00e1s eficiente al sistema (m\u00e1s informaci\u00f3n de audio en cada paquete) y, por el contrario, mayor ser\u00e1 el impacto en caso de p\u00e9rdida<\/p>\n

Tomado de: https:\/\/telos.fundaciontelefonica.com\/url-direct\/pdf-generator?tipoContenido=articulo&idContenido=2010022410280001<\/p>\n

Emprendiendo en la Telefon\u00eda por Internet<\/h2>\n

\"empresa-de-telefonia-voip\"<\/a>
\n