Puertos de protocolo Rtp. El uso de protocolos de Internet en telefonía IP

En esta sección se analizan algunos aspectos del transporte de paquetes RTP mediante protocolos de red y transporte. A menos que se especifique lo contrario en otras especificaciones de protocolo, se aplican las siguientes reglas generales al transmitir paquetes.

RTP se basa en protocolos subyacentes para proporcionar separación entre los flujos de datos RTP y la información de control RTCP. Para UDP y protocolos similares, RTP usa un número de puerto par, y el flujo RTCP correspondiente usa un número de puerto uno más alto.

Los paquetes de información RTP no contienen ningún campo de longitud, por lo tanto, RTP se basa en un protocolo subyacente para proporcionar una indicación de la longitud. La longitud máxima de los paquetes RTP está limitada solo por los protocolos subyacentes.

Se pueden transportar varios paquetes RTP en una única unidad de datos de protocolo de capa inferior, como un paquete UDP. Esto reduce la redundancia de encabezados y puede simplificar la sincronización entre diferentes flujos.

9. Lista de constantes de protocolo

Esta sección contiene una lista de constantes definidas en la especificación del protocolo RTP.

Las constantes de tipo de tráfico RTP (PT - tipo de carga útil) se definen en perfiles. Sin embargo, el octeto de encabezado RTP, que contiene los bits de marcador y el campo de tipo de tráfico, no DEBE contener los valores reservados 200 y 201 (decimal) para distinguir los paquetes RTP de los paquetes RTCP SR y RR. Para un formato estándar con un bit testigo y un campo de tipo de tráfico de siete bits, esta limitación significa que no se deben utilizar los tipos de tráfico 72 y 73.

Los valores para los tipos de paquetes RTCP (ver Tabla 1) se seleccionan en el rango de 200 a 204 para mejor control la exactitud del encabezado de los paquetes RTCP en comparación con los paquetes RTP. Cuando el campo de tipo de paquete RTCP se compara con el octeto correspondiente del encabezado RTP, este rango corresponde a un bit marcador de uno (que generalmente no es el caso en los paquetes de datos) y el bit más significativo del campo de tipo de tráfico estándar es igual a uno (mientras que los tipos de tráfico especificados estáticamente suelen tener valores de PT con un cero en el dígito más significativo). Este rango también se ha elegido para alejarlo aún más de los valores 0 y 255, ya que los campos que son completamente ceros o unos son en su mayoría datos específicos.

La comunidad de IANA define otros tipos de paquetes RTCP. Los desarrolladores tienen la capacidad de registrar los valores que necesitan para realizar una investigación experimental y luego cancelar el registro cuando la necesidad de esos valores desaparece.

Los tipos de elementos permitidos en el paquete SDES se presentan en la tabla. 2. La Comunidad IANA designa otros tipos de cláusulas SDES. Los desarrolladores tienen la capacidad de registrar los valores que necesitan cuando realizan una investigación experimental y luego anular el registro cuando esos valores ya no son necesarios.

10. Descripción del perfil y formato de tráfico

Como se señaló anteriormente (ver la Sección 2), para descripción completa El protocolo RTP para una aplicación específica requiere documentos adicionales de dos tipos: una descripción del perfil y el formato del tráfico.

RTP se puede utilizar para muchas clases de aplicaciones con requisitos muy diferentes. La flexibilidad para adaptarse a estos requisitos viene dada por el uso de diferentes perfiles (ver). Por lo general, una aplicación usa solo un perfil y no hay una indicación explícita de qué perfil está en este momento en uso - no.

Un documento adicional del segundo tipo, Especificación de formato de tráfico, define cómo se transmitirá un tipo particular de tráfico (por ejemplo, vídeo codificado según H.261) según RTP. El mismo formato de tráfico se puede utilizar para varios perfiles y, por tanto, se puede definir independientemente del perfil. Los documentos de perfil solo son responsables de ajustarse a este formato y valor de PT .

Los siguientes elementos pueden definirse en la descripción del perfil, pero esta lista no es exhaustiva.

Encabezado del paquete de datos RTP. El octeto en el encabezado de un paquete de datos RTP, que contiene un bit testigo y un campo de tipo de tráfico, puede redefinirse según el perfil para cumplir con diferentes requisitos, por ejemplo, para proporcionar más o menos bits testigo (sección 3.3).

Tipos de tráfico. Un perfil define típicamente una variedad de formatos de tráfico (por ejemplo, algoritmos de codificación de medios) y un mapeo estático predeterminado de estos formatos y valores de PT. Algunos de los formatos de tráfico pueden identificarse haciendo referencia a descripciones de formatos de tráfico individuales. Para cada tipo específico de tráfico, el perfil debe especificar la frecuencia de reloj de marca de tiempo RTP requerida para usar (Sección 3.1).

Adiciones de encabezado de paquete de datos RTP. Se pueden agregar campos adicionales al encabezado fijo del paquete de datos RTP si se requiere alguna funcionalidad adicional dentro de la clase de aplicación del perfil, independientemente del tipo de tráfico. .

Extensiones de encabezado de paquete de datos RTP. El contenido de los primeros 16 bits de la estructura de extensión del encabezado del paquete de datos RTP se especificará si el perfil permite el uso de este mecanismo. .

Tipos de paquetes RTCP. Se pueden definir nuevos tipos de paquetes RTCP específicos de la clase de aplicación (y registrarlos la IANA).

Intervalo de informes RTCP. El perfil debe definir los valores que se utilizarán para calcular el intervalo de informe RTCP: la fracción del ancho de banda de la sesión RTCP, el intervalo de informe mínimo y la división del ancho de banda entre remitentes y receptores.

Ampliación del paquete SR / RR. Si hay información adicional de origen o destino que debe transmitirse con regularidad, se puede especificar una sección de extensión para los paquetes RTCP SR y RR.

Utilizando SDES. El perfil puede definir prioridades relativas para que los elementos RTCP SDES se pasen o se eliminen (consulte la sección 4.2.2); sintaxis o semántica alternativa para la cláusula CNAME (sección 4.4.1); Formato de artículo LOC (sección 4.4.5); semántica y uso de la cláusula NOTE (sección 4.4.7) y nuevas cláusulas SDES que se registrarán en IANA.

Seguridad. El perfil puede definir qué servicios de seguridad y algoritmos deben utilizar las aplicaciones y puede controlar su uso (cláusula 7).

Coincidencia de contraseña a clave. El perfil puede determinar cómo se convierte una contraseña ingresada por el usuario en una clave de cifrado.

Protocolo de capa inferior. Los paquetes RTP pueden requerir el uso de una red subyacente específica o un protocolo de capa de transporte.

Cumplimiento de transporte. PUEDE definirse de forma distinta a las correspondencias estándar RTP y RTCP especificadas en la cláusula 8 para direcciones de capa de transporte, como puertos UDP.

Encapsulamiento. La configuración de paquetes RTP se puede definir para permitir la transmisión de múltiples paquetes de información RTP en una unidad de datos de protocolo de capa inferior (sección 8).

Cada aplicación que desarrolle no debería requerir un nuevo perfil. Es más conveniente expandir un perfil existente dentro de una clase de aplicaciones, en lugar de crear uno nuevo. Esto hará que sea más fácil para las aplicaciones interactuar, ya que cada una generalmente se ejecuta bajo un solo perfil. Las extensiones simples, como la definición de valores PT adicionales o tipos de paquetes RTCP, se pueden lograr registrándolos con IANA y publicando sus descripciones en una especificación de perfil o en una especificación de formato de tráfico.

11. Perfil RTP para conferencias de audio y video con un control mínimo

RFC 1890 describe un perfil para usar el protocolo de transporte en tiempo real RTP versión 2 y su protocolo de control asociado RTCP en una conferencia de audio o video grupal, el llamado perfil RTP para conferencias de audio y video con control mínimo (Perfil RTP para audio y videoconferencia). Videoconferencias con control mínimo). Este perfil define aspectos de RTP no especificados en la Especificación del protocolo RTP versión 2 (RFC 1889). El mínimo de control significa que no se requiere soporte para la negociación de parámetros o control de propiedad (por ejemplo, cuando se utilizan mapeos estáticos de tipos de tráfico e indicaciones de propiedad proporcionados por RTCP). Consideremos las principales disposiciones de este perfil.

11.1. Formatos de paquetes y parámetros de protocolo RTP y RTCP

Esta sección contiene una descripción de una serie de elementos que se pueden definir o cambiar en un perfil.

Encabezado del paquete de información RTP. Se utiliza el formato estándar del encabezado del paquete de información RTP fijo (un bit de testigo).

Tipos de tráfico. Los valores estáticos de los tipos de tráfico se definen en las secciones 11.3 y 11.4.

Adiciones de encabezado de paquete de información RTP. No se añaden campos fijos adicionales a los encabezados de los paquetes de información RTP.

Extensiones de encabezado de paquete de información RTP. No se definen extensiones de encabezado de paquete de información RTP, pero las aplicaciones que usan este perfil PUEDEN usar dichas extensiones. Es decir, no se debe suponer en aplicaciones que el bit X del encabezado RTP es siempre cero. Las aplicaciones deben estar preparadas para ignorar la extensión del encabezado. Si se especifica una extensión de encabezado en el futuro, entonces se debe especificar el contenido de los primeros 16 bits para que se puedan identificar muchas extensiones diferentes.

Tipos de paquetes RTCP. No se definen tipos de paquetes RTCP adicionales en esta especificación de perfil.

Intervalo de informes RTCP. Las constantes propuestas en RFC 1889 DEBEN utilizarse al calcular el intervalo de informe RTCP.

Extensiones de paquetes SR / RR. No se definen extensiones para paquetes RTCP SR y RR.

Utilizando SDES. Las aplicaciones pueden utilizar cualquiera de las cláusulas SDES descritas. Si bien la información del nombre canónico (CNAME) se envía en cada intervalo de informe, otros elementos solo deben enviarse en cada quinto intervalo de informe.

Seguridad. Los servicios de seguridad RTP predeterminados también se definen de forma predeterminada en este perfil.

Coincidencia de contraseña a clave. La contraseña ingresada por el usuario se convierte mediante el algoritmo MD5 en un resumen de 16 octetos. Una clave de N bits se obtiene de un resumen utilizando sus primeros N bits. Se supone que la contraseña solo puede incluir letras ASCII, números, guiones y espacios para reducir la probabilidad de distorsión al transmitir contraseñas por teléfono, fax, télex o correo electrónico. La contraseña puede ir precedida de una especificación del algoritmo de cifrado. Cualquier carácter hasta la primera barra diagonal (código ASCII 0x2f) se interpreta como el nombre del algoritmo de cifrado. Si no hay una barra diagonal, el valor predeterminado es el cifrado DES-CBC.

Antes de que se aplique el algoritmo de cierre, la contraseña ingresada por el usuario se convierte a forma canónica. Para hacer esto, la contraseña se convierte al juego de caracteres ISO 10646 utilizando la codificación UTF-8 como se define en el Apéndice P de ISO / IEC 10646-1: 1993 (los caracteres ASCII no requieren conversión); se eliminan los espacios al principio y al final de la contraseña; dos o más espacios se reemplazan por un espacio (ASCII o UTF-8 0x20); todas las letras se convierten a minúsculas

Protocolo subyacente. El perfil define el uso de RTP sobre UDP en modo bidireccional y multidifusión.

Cumplimiento de transporte. Se utiliza una correspondencia estándar entre las direcciones de la capa de transporte RTP y RTCP.

Encapsulamiento. La encapsulación de paquetes RTP no está definida.

11.2. Registro de tipos de tráfico

Este perfil define los tipos de codificación estándar que se utilizan con RTP. Otros tipos de codificación deben registrarse en IANA antes de su uso. Al registrar un nuevo tipo de codificación, se debe proporcionar la siguiente información:

• el nombre de código del tipo de codificación y la frecuencia de reloj de la marca de tiempo RTP (el nombre de código debe tener tres o cuatro caracteres de longitud para proporcionar una representación compacta, si es necesario);
• una indicación de quién tiene derecho a cambiar el tipo de codificación (por ejemplo, ISO, CCITT / ITU, otros organismos internacionales de normalización, consorcio, empresa específica o grupo de empresas);
• cualquier parámetro operativo;
• enlaces a descripciones disponibles del algoritmo de codificación, como (en orden de preferencia) RFC, artículo publicado, solicitud de patente, informe técnico, fuente de códec o referencia;
• para tipos de codificación privada, información de contacto (dirección postal y dirección de correo electrónico);
• valor para indicar el tipo de tráfico de este perfil, si es necesario (ver más abajo).
• Tenga en cuenta que no todos los tipos de codificación que se utilizarán con RTP deben asignarse estáticamente. Los medios que no son RTP, que no se tratan en este artículo, se pueden utilizar para mapear dinámicamente entre un valor de tipo de tráfico (PT) en el rango de 96 a 127 y un tipo de codificación.
• El espacio de valor disponible para los tipos de tráfico es bastante pequeño. Los nuevos tipos de tráfico se asignan estáticamente (permanentemente) solo si se cumplen las siguientes condiciones:
• la codificación es de gran interés para la comunidad Redes de internet;
• ofrece beneficios comparables a las codificaciones existentes y / o es necesario para la interoperabilidad con los sistemas de conferencias o multimedia existentes y ampliamente utilizados;
• la descripción es suficiente para crear un decodificador.

11.3. Codificación de audio

Para las aplicaciones que no envían paquetes durante las pausas, el primer paquete de voz activa (el primer paquete después de la pausa) se distingue por un bit de señal establecido en uno en el encabezado del paquete portador RTP. Las aplicaciones no silenciadas establecen este bit en cero.

El reloj RTP utilizado para generar la marca de tiempo RTP es independiente del número de canales y del tipo de codificación; es igual al número de períodos de muestreo por segundo. Para la codificación de N canales (estéreo, cuádruple, etc.), cada período de muestreo (digamos 1/8000 de segundo) genera N muestras. El número total de muestras generadas por segundo es igual a la frecuencia de muestreo multiplicada por el número de canales.

Cuando se utilizan varios canales de audio, se enumeran de izquierda a derecha, comenzando por el primero. En los paquetes de audio RTP, los datos de los canales con números más bajos preceden a los datos de los canales con números más altos. Para más de dos canales, utilice próximos sistemas designaciones:

• l - izquierda;
• r - correcto;
• c - central;
• S - periférico;
• F - frontal;
• R - espalda.

Número de canales	Nombre del sistema	Números de canal
		1	2	3	4	5	6
2	estéreo	l	r
3		l	r	C
4	patio	Florida	P.	Rl	Rr
4		l	C	r	S
5		Florida	P.	Fc	Sl	Sr
6		l	lc	C	r	rc	S

Las muestras de todos los canales que pertenecen al mismo tiempo de muestreo deben estar dentro del mismo paquete. El entrelazado de muestras de diferentes canales depende del tipo de codificación.

La frecuencia de muestreo debe seleccionarse entre una variedad de: 8000, 11025, 16000, 22050, 24000, 32000, 44100 y 48000 Hz (las computadoras Apple Macintosh tienen sus propias frecuencias de muestreo de 22254.54 y 11127.27, que se pueden convertir a 22050 y 11025 s calidad aceptable omitiendo cuatro o dos muestras en un marco de 20 ms). Sin embargo, la mayoría de los algoritmos de codificación de audio están definidos para un conjunto más limitado de frecuencias de muestreo. Los destinatarios deben estar preparados para recibir audio multicanal, pero también pueden seleccionar mono.

Para la paquetización de una señal de audio, el intervalo de paquetización por defecto será de 20 ms, a menos que se especifique lo contrario en la descripción de codificación. El intervalo de paquetización define la latencia mínima de un extremo a otro. Los paquetes más largos tienen relativamente menos bytes para el encabezado, pero causan más demoras y hacen que la pérdida de paquetes sea más significativa. Para aplicaciones no interactivas, como conferencias o canales con limitaciones significativas de ancho de banda, puede ser aceptable una latencia de paquetización más alta. El destinatario debe recibir paquetes con una señal de sonido con un retraso de 0 a 200 ms. Esta limitación proporciona un tamaño de búfer aceptable para el receptor.

En codificaciones basadas en muestras, cada muestra de señal está representada por un número fijo de bits. Dentro de los datos de audio comprimidos, los códigos de muestra individuales pueden cruzar los límites de los octetos. La duración de la señal transmitida en un paquete de sonido está determinada por el número de muestras en el paquete.

Para los tipos de codificación basados ​​en muestras que producen uno o más octetos para cada muestra, las muestras de diferentes canales muestreados simultáneamente se empaquetan en octetos adyacentes. Por ejemplo, para codificar sonido estéreo, la secuencia de octetos es: canal izquierdo, primera muestra; canal derecho, primer recuento; canal izquierdo, segundo recuento; canal derecho, segundo recuento, etc. En la codificación de múltiples octetos, el octeto más significativo se transmite primero. El empaquetado de codificaciones basadas en muestras que producen menos de un octeto para cada muestra se determina mediante el algoritmo de codificación.

Un algoritmo de codificación basado en cuadros convierte un bloque de audio de longitud fija en otro bloque de datos comprimidos, generalmente también de longitud fija. Para las codificaciones basadas en tramas, el remitente puede combinar varias de estas tramas en un solo mensaje.

Para los códecs basados ​​en cuadros, el orden de los canales es específico para todo el bloque. Es decir, para el sonido estéreo, las muestras de los canales izquierdo y derecho se codifican de forma independiente; donde la trama de codificación para el canal izquierdo precede a la trama para el canal derecho.

Todos los códecs de audio orientados a cuadros deben poder codificar y decodificar múltiples cuadros consecutivos transmitidos dentro de un solo paquete. Dado que se especifica el tamaño de la trama para los códecs orientados a tramas, no es necesario utilizar una notación separada para la misma codificación, pero con un número diferente de tramas por paquete.

Mesa 3 muestra los valores de los tipos de tráfico (PT) definidos por este perfil para señales de audio, su leyenda y el principal especificaciones algoritmos de codificación.

11.4. Codificación de video

Mesa 4 muestra los valores de los tipos de codificación (PT), los símbolos de los algoritmos de codificación y las características técnicas de los algoritmos de codificación de vídeo definidos por este perfil, así como los valores de PT no asignados, reservados y establecidos dinámicamente.

Los valores de tipo de tráfico en el rango de 96 a 127 se pueden determinar dinámicamente a través del protocolo de control de conferencia, que no se trata en este artículo. Por ejemplo, el directorio de sesión puede especificar que para una sesión determinada, el tipo de tráfico 96 denota codificación PCMU de doble canal a 8000 Hz. El rango de valores de tipo de tráfico marcados como "reservados" no se utiliza para que los paquetes RTCP y RTP se puedan distinguir de manera confiable. .

Una fuente RTP en cualquier momento dado solo genera un tipo de tráfico; intercalado de tráfico diferentes tipos en una sesión no se permite RTP. Se pueden utilizar varias sesiones RTP en paralelo para transportar diferentes tipos de tráfico. Los tipos de tráfico definidos en este perfil se refieren a audio o video, pero no a ambos. Sin embargo, se permite definir tipos de tráfico combinados que combinen, por ejemplo, audio y video, con la separación adecuada en el formato de tráfico.

Las aplicaciones de audio que utilizan este perfil deben, como mínimo, poder enviar y recibir tipos de tráfico 0 (PCMU) y 5 (DVI4). Esto permite la interoperabilidad sin negociación de formato.

11,5. Asignación de puerto

Como se define en la descripción del protocolo RTP, los datos RTP deben enviarse a través de un puerto UDP de número par y los paquetes RTCP correspondientes deben enviarse a través de un puerto impar.

Las aplicaciones que utilizan este perfil pueden utilizar cualquier par de puertos UDP. Por ejemplo, el programa de gestión de sesiones puede asignar aleatoriamente un par de puertos. No se puede especificar un solo par fijo de números de puerto porque, en algunos casos, varias aplicaciones que utilizan este perfil deben ejecutarse correctamente en el mismo host y algunos sistemas operativos no permiten que varios procesos utilicen el mismo puerto UDP con diferentes direcciones de multidifusión.

Sin embargo, los números de puerto predeterminados pueden ser 5004 y 5005. Las aplicaciones que utilizan varios perfiles pueden seleccionar este par de puertos como indicador de ese perfil. Pero las aplicaciones también pueden requerir que se especifique explícitamente un par de puertos.

12. Lista de términos y abreviaturas utilizados

• ASCII (Código estándar americano para el intercambio de información) es el código estándar americano para el intercambio de información. Código de presentación de 7 bits información de texto utilizado con algunas modificaciones en la mayoría de los sistemas informáticos
• CBC (encadenamiento de bloques de cifrado): cadena de bloques cifrada, modo estándar de cifrado de datos DES
• CELP (predicción lineal excitada por código) es un tipo de codificación de audio que utiliza predicción lineal excitada por código
• CNAME (nombre canónico) - nombre canónico
• CSRC (fuente contribuyente): fuente incluida. La fuente del flujo de paquetes RTP que contribuyó al flujo combinado producido por el mezclador RTP. El mezclador inserta en el encabezado del paquete RTP una lista de identificadores SSRC de aquellas fuentes que participaron en la formación de este paquete. Esta lista se llama lista CSRC. Ejemplo: el mezclador transmite los ID de los participantes de la teleconferencia que hablan actualmente cuyas voces se han mezclado y utilizado para crear el paquete saliente, señalando al destinatario a la fuente del mensaje actual, incluso si todos los paquetes de audio contienen el mismo ID SSRC (como el mezclador)
• DES (Estándar de cifrado de datos): estándar de cifrado de datos
• IANA (Autoridad de Números Asignados de Internet) - Comunidad de Números Asignados de Internet
• IMA (Asociación de multimedia interactiva) - Asociación de multimedia interactiva
• IP (Protocolo de Internet) - entre protocolo de red, protocolo de capa de red, protocolo de datagrama. Permite que los paquetes crucen varias redes en ruta a su destino
• IPM (IP Multicast): multidifusión utilizando el protocolo IP
• LD-CELP (predicción lineal excitada por código de bajo retardo): un algoritmo de codificación de voz que utiliza predicción lineal excitada por código con retardo bajo
• LPC (codificación predictiva lineal): codificación predictiva lineal
• NTP (Network Time Protocol) es una cuenta regresiva de tiempo en segundos en relación con cero horas el 1 de enero de 1900. El formato de marca de tiempo NTP completo es un número de coma fija sin signo de 64 bits con una parte entera en los primeros 32 bits y una parte fraccionaria en los últimos 32 bits. En algunos casos, se utiliza una representación más compacta, en la que solo se toman los 32 bits del medio del formato completo: los 16 bits inferiores de la parte entera y los 16 bits superiores de la parte fraccionaria.
• RPE / LTP (excitación de pulso residual / predicción a largo plazo): un algoritmo de codificación de voz con excitación de impulso diferencial y predicción a largo plazo
• RTCP (Protocolo de control en tiempo real): protocolo de control de transmisión de datos en tiempo real
• RTP (Protocolo de transporte en tiempo real): protocolo de transporte en tiempo real
• SSRC (fuente de sincronización): fuente de sincronización. El origen del flujo de paquetes RTP, identificado por el identificador SSRC numérico de 32 bits que se transporta en el encabezado RTP, independientemente de la dirección de red. Todos los paquetes con la misma fuente de sincronización utilizan el mismo espacio de tiempo y número de secuencia, por lo que el receptor agrupa los paquetes para su reproducción con la fuente de sincronización. Ejemplo de fuente de sincronización: remitente de una secuencia de paquetes recibidos de una fuente de señal tipo de micrófono, videocámara o mezclador RTP. La fuente de sincronización puede cambiar el formato de los datos con el tiempo, por ejemplo, codificación de audio... El identificador SSRC es un valor seleccionado aleatoriamente que se considera globalmente único dentro de una sesión RTP particular. No se requiere que el participante de la teleconferencia utilice el mismo SSRC para todas las sesiones RTP en una sesión de comunicación multimedia; La agregación de identidad SSRC se proporciona a través de RTCP. Si un participante genera múltiples transmisiones en una sesión RTP, por ejemplo, desde múltiples cámaras de video, entonces cada transmisión debe ser identificada por un SSRC separado.
• TCP (Protocolo de control de transmisión) es un protocolo de capa de transporte que se utiliza junto con IP
• UDP (User Datagram Protocol) es un protocolo de capa de transporte sin conexión. UDP solo permite enviar un paquete a una o más estaciones de la red. La validación y la garantía de la integridad (entrega garantizada) de la transmisión de datos se llevan a cabo a un nivel superior
• ADPCM - Modulación de código de pulso diferencial adaptativo
• jitter - jitter, desviaciones de fase o frecuencia de la señal; en relación con la telefonía IP: irregularidades en el retraso de los datagramas en la red
• ZPD - enlace de transmisión de datos (segundo nivel del Modelo de Referencia de Interacción sistemas abiertos)
• IVS - información y redes informáticas
• mezclador: un sistema intermedio que recibe paquetes RTP de una o más fuentes, posiblemente cambia el formato de datos, combina los paquetes en nuevo paquete RTP y luego lo transmite. Dado que muchas fuentes de señal generalmente no están sincronizadas, el mezclador ajusta la sincronización de los flujos de componentes y genera su propio tiempo para el flujo combinado. Por tanto, todos los paquetes de información generados por el mezclador se identifican como si tuvieran el mezclador como fuente de sincronización.
• monitor (monitor): una aplicación que recibe paquetes RTCP enviados por los participantes en una sesión RTP, en particular, informes de recepción, y evalúa la calidad del servicio actual para controlar la distribución, detectar errores y estadísticas a largo plazo. Por lo general, las funciones del monitor recaen en las aplicaciones utilizadas en la sesión, pero el monitor también puede ser una aplicación separada que no se utiliza de otra manera, no envía ni recibe paquetes de datos RTP. Estas aplicaciones se denominan monitores de terceros.
• UIT-T - Sector de Normalización de las Telecomunicaciones de la Unión Internacional de Telecomunicaciones
• sistema final: una aplicación que genera contenido transmitido en paquetes RTP y / o que consume el contenido de los paquetes RTP recibidos. El sistema final puede actuar como una o más (pero generalmente solo una) fuentes de reloj en cada sesión RTP
• Paquete RTCP: paquete de control que consta de una parte fija del encabezado, similar a los paquetes de información RTP, seguida de elementos estructurales que varían según el tipo de paquete RTCP. Normalmente, varios paquetes RTCP se envían juntos como un paquete RTCP compuesto en un único paquete de protocolo subyacente; esto lo proporciona el campo de longitud en el encabezado fijo de cada paquete RTCP
• El paquete RTP es una unidad de datos de protocolo que consta de un encabezado RTP fijo, posiblemente una lista vacía de fuentes, extensiones y tráfico incluidos. Por lo general, un paquete de protocolo de capa inferior contiene un paquete RTP, pero puede haber varios
• puerto es una abstracción utilizada por los protocolos de nivel de transporte para distinguir entre varios destinos dentro de una sola computadora host. El puerto se identifica por su número. Por lo tanto, el número de puerto es un número que identifica la aplicación específica para la que están destinados los datos que se envían. Este número, junto con la información sobre qué protocolo (por ejemplo, TCP o UDP) se utiliza en la capa superior, se incluye entre otra información de servicio en los datagramas enviados a través de Internet. Selectores de transporte (TSEL) utilizados por el transporte Capa OSI, son equivalentes a puertos
• perfil (perfil): un conjunto de parámetros para los protocolos RTP y RTCP para una clase de aplicaciones, que determina las características de su funcionamiento. El perfil define el uso de campos de tipo de tráfico y bit de token en el encabezado del paquete de datos RTP, tipos de tráfico, adiciones del encabezado del paquete de datos RTP, primeros 16 bits de la extensión del encabezado del paquete de datos RTP, tipos de paquetes RTCP, intervalo de informe RTCP, paquete SR / RR extensión, uso de paquetes SDES, servicios y algoritmos para garantizar la seguridad de las comunicaciones y los detalles del uso del protocolo de capa inferior
• Sesión RTP (sesión RTP): comunicación de muchos participantes que interactúan a través del protocolo RTP. Para cada participante, la sesión está determinada por un par específico de direcciones de transporte de destino (una dirección de red más un par de puertos para RTP y RTCP). Un par de direcciones de destino de transporte puede ser común para todos los participantes (como en el caso de IPM) o puede ser diferente para cada uno (dirección de red individual y un par común de puertos, como en la comunicación bidireccional). En una sesión multimedia, cada tipo de tráfico se envía en una sesión RTP separada con sus propios paquetes RTCP. Las sesiones de multidifusión RTP se distinguen por diferentes números de pares de puertos y / o diferentes direcciones de multidifusión
• Medios no RTP: protocolos y mecanismos que pueden ser necesarios además de RTP para proporcionar un servicio aceptable. Particularmente para conferencias multimedia, la aplicación de gestión de conferencias puede asignar direcciones de multidifusión y claves de cifrado, negociar el algoritmo de cifrado que se utilizará y determinar asignaciones dinámicas entre los valores de tipo de tráfico RTP y los formatos de tráfico que representan (formatos que no tienen una valor predefinido. tipo de tráfico). Para aplicaciones simples también puede ser usado Correo electrónico o base de datos de conferencias
• traductor: un sistema intermedio que reenvía paquetes RTP sin cambiar el identificador de la fuente de sincronización. Ejemplos de traductores: dispositivos que realizan transcodificaciones sin mezclar, replicadores multidireccionales o bidireccionales, aplicaciones de capa de aplicación en firewalls
• dirección de transporte: una combinación de dirección de red y número de puerto que identifica el punto final de la capa de transporte, como una dirección IP y un número de puerto UDP. Los paquetes se reenvían desde la dirección de transporte de origen a la dirección de transporte de destino.
• Tráfico RTP: datos multimedia transmitidos en un paquete RTP, como muestras de audio o datos de vídeo comprimidos.
• PSTN - redes telefónicas públicas conmutadas

El problema más urgente se está convirtiendo cada vez más en la falta de espacio de direcciones, lo que requiere un cambio en el formato de la dirección.

Otro problema es la falta de escalabilidad del enrutamiento, la base de las redes IP. El rápido crecimiento de la red provoca congestión en los enrutadores, que ya hoy tienen que mantener tablas de enrutamiento con decenas o cientos de miles de entradas, así como solucionar el problema de la fragmentación de paquetes. Es posible facilitar el funcionamiento de los enrutadores, en particular, actualizando el protocolo IP.

Junto con la introducción de nuevas funciones directamente en el protocolo IP, es aconsejable asegurar su interacción más estrecha con los nuevos protocolos mediante la introducción de nuevos campos en el encabezado del paquete.

Como resultado, se decidió actualizar el protocolo IP, persiguiendo los siguientes objetivos principales:

• creación de un nuevo esquema de direccionamiento ampliado;
• mejorar la escalabilidad de la red al reducir las funciones de los enrutadores troncales;
• garantizar la protección de datos.

Expandiendo el espacio de direcciones... El protocolo IP resuelve el problema potencial de la escasez de direcciones al expandir el ancho de la dirección a 128. Sin embargo, un aumento tan significativo en la longitud de la dirección se realizó en gran medida no para eliminar el problema de la escasez de direcciones, sino para mejorar la eficiencia de redes basadas en este protocolo. El objetivo principal era cambiar estructuralmente el sistema de direccionamiento, expandir su funcionalidad.

En lugar de los dos niveles existentes de la jerarquía de direcciones (número de red y número de nodo), IPv6 propone utilizar cuatro niveles, lo que implica una identificación de red de tres niveles y un nivel para la identificación de nodo.

Ahora la dirección está escrita en forma hexadecimal, con cada cuatro dígitos separados entre sí por dos puntos, por ejemplo:

FEDC: 0A96: 0: 0: 0: 0: 7733: 567A.

Para las redes que admiten ambas versiones de IPv4 e IPv6, es posible utilizar la notación decimal tradicional para los 4 bytes inferiores y hexadecimal para los superiores:

0: 0: 0: 0: FFFF 194.135.75.104.

Dentro del sistema de direccionamiento IPv6, también hay un espacio de direcciones dedicado para uso local, es decir, para redes fuera de Internet. Hay dos tipos direcciones locales: para redes planas sin subredes (Link-Local) y para redes en subredes (Site-Local), que difieren en el valor del prefijo.

Cambiar el formato de los encabezados de los paquetes. Esto se puede lograr mediante un nuevo esquema de organización para "encabezados anidados", que proporciona la división del encabezado en el principal, que contiene el mínimo necesario de información, y otros adicionales, que pueden estar ausentes. Este enfoque abre ricas posibilidades para extender el protocolo mediante la definición de nuevos encabezados opcionales, lo que abre el protocolo.

El encabezado del datagrama IPv6 básico de 40 bytes tiene el siguiente formato (Figura 2.4).

Campo Clase de tráfico es equivalente en propósito al campo Tipo de servicio y el campo Límite de saltos- campo Tiempo para vivir Protocolo IPv4.

Campo Etiqueta de flujo le permite aislar y procesar específicamente flujos de datos individuales sin la necesidad de analizar el contenido de los paquetes. Esto es muy importante en términos de reducir la carga en los enrutadores.

Campo Encabezado siguiente es análogo al campo Protocolo IPv4 y define el tipo de encabezado que sigue al encabezado principal. Cada encabezado adicional subsiguiente también contiene un campo de Encabezado siguiente.

2.3.3. Protocolo TCP

Protocolo de control La transmisión de información (Protocolo de control de transmisión - TCP) se desarrolló para respaldar la comunicación interactiva entre computadoras. El protocolo TCP asegura la confiabilidad y confiabilidad del intercambio de datos entre procesos en computadoras que forman parte de una red común.

Desafortunadamente, TCP no es capaz de transmitir información multimedia... La razón principal es la presencia de control sobre la entrega. La monitorización tarda demasiado en transmitir más información sensible a retrasos. Además, TCP proporciona mecanismos para controlar la velocidad de transmisión para evitar la congestión de la red. Sin embargo, los datos de audio y video requieren velocidades de bits estrictamente definidas que no se pueden cambiar arbitrariamente.

Por un lado, TCP interactúa con el protocolo de aplicación de la aplicación de usuario y, por otro, con el protocolo que proporciona funciones de enrutamiento y direccionamiento de paquetes de "bajo nivel", que generalmente se realizan mediante IP.

La estructura lógica del software de red que implementa los protocolos de la familia TCP / IP en cada nodo de Internet se muestra en la Fig. 2.5.

Los rectángulos representan los módulos que procesan los datos y las líneas que conectan los rectángulos representan las rutas de transferencia de datos. La línea horizontal en la parte inferior de la figura indica una red Ethernet, que se utiliza como ejemplo de medio físico.

Arroz. 2.5.

Para establecer una conexión entre dos procesos en diferentes computadoras red, necesita saber no solo las direcciones de Internet de las computadoras, sino también el número de esos puertos TCP (sockets) que los procesos utilizan en estas computadoras. Cualquier conexión TCP en Internet se identifica de forma única mediante dos direcciones IP y dos números de puerto TCP.

TCP puede manejar paquetes dañados, perdidos, duplicados o desordenados. Esto se logra mediante un mecanismo para asignar un número de secuencia a cada paquete transmitido y un mecanismo para verificar la recepción de paquetes.

Cuando TCP transmite un segmento de datos, se coloca una copia de esos datos en una cola de retransmisión y se pone en marcha un temporizador para esperar un acuse de recibo.

2.3.4. Protocolo UDP

El Protocolo de datagramas de usuario (UDP) se utiliza para intercambiar datagramas entre procesos de computadoras ubicadas en un sistema unificado de redes de computadoras.

UDP se basa en IP y proporciona a los procesos de aplicación servicios de transporte que no son muy diferentes de los de IP. El protocolo UDP proporciona entrega de datos no garantizada, es decir, no requiere confirmación de su recepción; Además, este protocolo no requiere el establecimiento de una conexión entre la fuente y el receptor de información, es decir, entre módulos UDP.

2.3.5. Protocolos RTP y RTCP

Conceptos básicos

El protocolo de transporte en tiempo real RTP proporciona transmisión en tiempo real de un extremo a otro de datos multimedia, como audio y video interactivos. Este protocolo implementa el reconocimiento del tipo de tráfico, la numeración de la secuencia de paquetes, la marca de tiempo y el control de la transmisión.

La acción del protocolo RTP se reduce a asignar marcas de tiempo a cada paquete saliente. En el lado receptor, las marcas de tiempo de los paquetes indican en qué secuencia y con qué demoras deben reproducirse. La compatibilidad con RTP y RTCP permite al nodo receptor organizar los paquetes recibidos en el orden correcto, reducir el efecto de la fluctuación de retardo de los paquetes en la calidad de la señal y restaurar la sincronización entre el audio y el video para que los usuarios puedan escuchar y ver correctamente la información entrante.

Tenga en cuenta que RTP en sí no tiene ningún mecanismo para garantizar la transmisión oportuna de datos y calidad de servicio pero utiliza los servicios subyacentes para proporcionar esto. No evita que los paquetes se desordenen, pero no implica que la red troncal sea completamente confiable y reenvíe los paquetes en el orden correcto. Los números de secuencia incluidos en RTP permiten al receptor reconstruir la secuencia de los paquetes del remitente.

RTP admite tanto la comunicación bidireccional como la transferencia de datos a un grupo de destinos si la multidifusión es compatible con la red subyacente. RTP está diseñado para proporcionar la información requerida por aplicaciones individuales y, en la mayoría de los casos, está integrado en el funcionamiento de la aplicación.

Aunque RTP se considera un protocolo de capa de transporte, generalmente se ejecuta sobre otro protocolo de capa de transporte, UDP (Protocolo de datagramas de usuario). Ambos protocolos contribuyen a la funcionalidad de la capa de transporte. Cabe señalar que RTP y RTCP son independientes de las capas de red y de transporte subyacentes, por lo que RTP / RTCP se puede utilizar con otros protocolos de transporte adecuados.

Bloques de datos de protocolo RTP / RTCP se denominan paquetes. Los paquetes generados de acuerdo con el protocolo RTP y utilizados para transmitir datos multimedia se denominan paquetes de datos y los paquetes generados de acuerdo con el protocolo RTCP y utilizados para transferir información de servicio que se requiere para un funcionamiento confiable. teleconferencias se denominan paquetes de control. Un paquete RTP incluye un encabezado fijo, una extensión de encabezado variable opcional y un campo de datos. Un paquete RTCP comienza con una parte fija (similar a la parte fija de los paquetes de información RTP) seguida de bloques de construcción de longitud variable.

Para que el protocolo RTP sea más flexible y pueda utilizarse para diversas aplicaciones, algunos de sus parámetros se hacen deliberadamente indefinidos, pero prevé el concepto de perfil. Un perfil es un conjunto de parámetros para los protocolos RTP y RTCP para una clase específica de aplicaciones, que determina las características de su funcionamiento. El perfil define: el uso de campos de encabezado de paquete individuales, tipos de tráfico, adiciones de encabezado y extensiones de encabezado, tipos de paquetes, servicios y algoritmos de seguridad de comunicación, detalles del uso del protocolo de capa inferior, etc. Cada aplicación generalmente trabaja con un solo perfil, y el tipo de perfil se establece seleccionando la aplicación adecuada. No hay una indicación explícita del tipo de perfil por número de puerto, identificador de protocolo, etc.

Por lo tanto, una especificación RTP completa y específica de la aplicación debe incluir documentos adicionales que incluyan una descripción del perfil, así como una descripción del formato del tráfico que defina cómo se manejará el tráfico de un tipo particular, como audio o video, en RTP.

Conferencia de audio grupal

Las conferencias de audio de multidifusión requieren una dirección de multidifusión multiusuario y dos puertos. En este caso, se requiere un puerto para el intercambio de datos de audio y el otro se usa para paquetes de control RTCP. La dirección de multidifusión y la información del puerto se transmite a los posibles participantes teleconferencias... Si se requiere el secreto, entonces los paquetes de información y control se pueden cifrar, en cuyo caso también se deben generar y clave distribuida cifrado.

La aplicación de audioconferencia utilizada por cada participante de la conferencia envía datos de audio en pequeños fragmentos, como 20 ms. Cada fragmento de datos de audio está precedido por un encabezado RTP; el encabezado RTP y los datos se forman (encapsulan) alternativamente en un paquete UDP. El encabezado RTP indica qué tipo de codificación de audio (por ejemplo, PCM, ADPCM o LPC) se usó para formar los datos en el paquete. Esto permite cambiar el tipo de codificación durante la conferencia, por ejemplo, cuando aparece un nuevo participante que utiliza una línea de comunicación con poco ancho de banda, o cuando la red está congestionada.

En Internet, como en otras redes de datos de conmutación de paquetes, los paquetes a veces se pierden y se reordenan, y también se retrasan en diferentes momentos. Para contrarrestar estos eventos, el encabezado RTP contiene una marca de tiempo y un número de secuencia que permiten a los destinatarios volver a sincronizarse a su estado original para que, por ejemplo, el altavoz reproduzca partes de la señal de audio continuamente cada 20 ms. Esta reconstrucción de sincronización se realiza por separado e independientemente para cada fuente de paquetes RTP en teleconferencias... El receptor también puede utilizar el número de secuencia para estimar el número de paquetes perdidos.

Dado que los participantes teleconferencias puede entrar y salir durante la conferencia, es útil saber quién está participando en él en ese momento y qué tan bien reciben los datos de audio los participantes de la conferencia. Para este propósito, cada instancia de la aplicación de audio durante la conferencia emite periódicamente mensajes en el puerto de control (puerto RTCP) para las aplicaciones de todos los demás participantes sobre la recepción de paquetes con la indicación de su nombre de usuario. El mensaje de recepción indica qué tan bien se escucha al hablante actual y se puede usar para controlar codificadores adaptativos. Además del nombre de usuario, también se puede incluir otra información de identificación para el control del ancho de banda. Al salir de la conferencia, el sitio envía un paquete RTCP BYE.

Videoconferencia

Si en teleconferencias se utilizan tanto señales de audio como de vídeo, se transmiten por separado. Para la transmisión de cada tipo de tráfico, independientemente del otro, la especificación del protocolo introduce el concepto de sesión RTP. Una sesión se identifica mediante un par específico de direcciones de transporte de destino (una dirección de red más un par de puertos para RTP y RTCP). Los paquetes para cada tipo de tráfico se transmiten utilizando dos pares diferentes de puertos UDP y / o direcciones de multidifusión. No existe una conexión RTP directa entre las sesiones de comunicación de audio y video, excepto que el usuario que participa en ambas sesiones debe usar el mismo nombre canónico en los paquetes RTCP para ambas sesiones para que las sesiones se puedan vincular.

Una de las razones de esta separación es que a algunos participantes de la conferencia se les debería permitir recibir solo un tipo de tráfico si así lo desean. A pesar de la separación, se puede lograr la reproducción sincrónica de los medios de origen (audio y video) utilizando información de tiempo que se transporta en paquetes RTCP para ambas sesiones.

Comprensión de mezcladores y traductores

No todos los sitios siempre pueden recibir datos multimedia en el mismo formato. Considere un caso en el que los participantes de la misma ubicación están conectados a través de una línea de baja velocidad con la mayoría de los demás participantes de la conferencia que tienen acceso de banda ancha a la red. En lugar de obligar a todos a usar un ancho de banda más estrecho y una codificación de audio de menor calidad, se puede colocar una instalación de comunicación de capa RTP llamada mezclador en un área de ancho de banda estrecho. Este mezclador resincroniza los paquetes de audio entrantes para restaurar los intervalos originales de 20 ms, mezcla estos flujos de audio reconstruidos en un solo flujo, codifica la señal de audio para un ancho de banda estrecho y transmite el flujo de paquetes a través de un enlace de baja velocidad. En este caso, los paquetes pueden dirigirse a un destinatario o un grupo de destinatarios con diferentes direcciones. Para que se pueda proporcionar la indicación correcta en los puntos finales receptores fuente de mensajes El encabezado RTP incluye un medio para identificar las fuentes involucradas en el paquete mixto para mezcladores.

Algunos de los participantes de la audioconferencia pueden estar conectados por líneas de banda ancha, pero es posible que no se pueda acceder a ellos a través de la conferencia de multidifusión IP (IPM). Por ejemplo, pueden estar detrás de un firewall de capa de aplicación que no permitirá ninguna transmisión de paquetes IP. Para tales casos, no se necesitan mezcladores, sino otros tipos de comunicaciones de nivel RTP, llamados traductores. De los dos traductores, uno está instalado fuera del cortafuegos y desde el exterior reenvía todos los paquetes de multidifusión recibidos a través de la conexión segura al otro traductor detrás del cortafuegos. El traductor detrás del cortafuegos los vuelve a transmitir como paquetes de multidifusión al grupo multiusuario limitado a la red interna del sitio.

Los mezcladores y traductores pueden diseñarse para varios propósitos. Ejemplo: un mezclador de video que escala imágenes de video de individuos en transmisiones de video independientes y las compone en una sola transmisión de video, simulando una escena grupal.

Protocolo de control RTCP

Todos los campos de los paquetes RTP / RTCP se transmiten a través de la red por bytes (octetos); el byte más significativo se transmite primero. Todos los datos del campo de encabezado se alinean de acuerdo con su longitud. Los octetos designados como opcionales tienen un valor de cero.

Protocolo de control RTCP (RTCP - Protocolo de control en tiempo real) se basa en la transmisión periódica de paquetes administración a todos los participantes en una sesión de comunicación utilizando el mismo mecanismo de distribución que RTP. El protocolo de capa inferior debe proporcionar multiplexación de paquetes de información y control, por ejemplo, utilizando diferentes números Puertos UDP. RTCP tiene cuatro funciones principales.

1. La función principal es proporcionar retroalimentación para evaluar la calidad de la distribución de datos. Es una función inherente de RTCP como protocolo de transporte y está asociada con las funciones de control de flujo y control de congestión de otros protocolos de transporte. Realimentación puede ser directamente útil para gestionar la codificación adaptativa, pero los experimentos con multidifusión IP han demostrado que la retroalimentación del receptor también es importante para diagnosticar defectos de propagación. Enviar informes de retroalimentación sobre la ingestión de datos a todos los participantes permite observar los problemas para evaluar si son locales o globales. Con el mecanismo de distribución de IPM para entidades como proveedores de servicios de red, también es posible recibir información de retroalimentación y actuar como un monitor de terceros en el diagnóstico de problemas de red. Esta función de retroalimentación la proporcionan los informes de emisor y receptor de RTCP.
2. RTCP mantiene un identificador de fuente de datos RTP persistente en la capa de transporte llamado "nombre canónico" (CNAME). Debido a que el ID de SSRC puede cambiar si se detecta un conflicto o se reinicia el programa, los destinatarios necesitan el CNAME canónico para rastrear a cada colaborador. Los destinatarios también requieren CNAME para mapeando el conjunto la información fluye de un participante dado a múltiples sesiones RTP asociadas, por ejemplo, al sincronizar señales de audio y video.
3. Las dos primeras características requieren que todos los pares envíen paquetes RTCP, por lo que RTP debe tener una velocidad de aceleración para permitir la escalabilidad de igual a igual. Cuando lo envía cada participante teleconferencias paquetes de control a todos los demás participantes, cada uno puede estimar de forma independiente el número total de participantes.
4. Una cuarta función RTCP opcional debe proporcionar información de control de sesión (por ejemplo, identificación de participante) que se reflejará en la interfaz de usuario. Es más probable que esto sea útil en sesiones "poco controladas" en las que los miembros se unen y abandonan un grupo sin control de propiedad ni negociación.

Las funciones uno a tres son necesarias cuando se utiliza RTP en multidifusión IP y se recomiendan en todos los demás casos. Se recomienda a los desarrolladores de aplicaciones RTP que eviten los mecanismos solo bidireccionales que no se escalan para adaptarse a los usuarios.

Tasa de paquetes RTCP

RTP permite que una aplicación escale automáticamente la representatividad de una sesión de comunicación de unos pocos participantes a varios miles. Por ejemplo, en las conferencias de audio, el tráfico de datos es esencialmente autolimitado porque solo una o dos personas pueden hablar a la vez, y en la distribución grupal, la velocidad de datos en cualquier enlace permanece relativamente constante, independientemente del número de participantes. Sin embargo, el tráfico de gestión no es autolimitante. Si los informes de recepción de cada participante se envían a una velocidad constante, entonces el tráfico de gestión crecerá linealmente con el aumento en el número de participantes. Por lo tanto, debe proporcionarse un mecanismo especial para reducir la frecuencia de transmisión de los paquetes de control.

Para cada sesión, se asume que el tráfico de datos alcanza un límite agregado, llamado ancho de banda de la sesión, que es compartido por todos los participantes. Este ancho de banda puede ser reservado y limitado por la red. El ancho de banda de la sesión es independiente del tipo de codificación de medios, pero la selección del tipo de codificación puede estar limitada por el ancho de banda de la sesión de comunicación. Se espera que la aplicación de gestión de sesiones proporcione el parámetro de ancho de banda de la sesión cuando invoca la aplicación de medios, pero las aplicaciones de medios también pueden establecer un valor predeterminado basado en el ancho de banda de datos de un solo remitente para el tipo de codificación seleccionado para la sesión.

Los cálculos de ancho de banda para el control y el tráfico de datos se basan en los protocolos de capa de red y transporte subyacentes (como UDP e IP). Los encabezados de la capa de enlace de datos (DLC) no se tienen en cuenta en los cálculos, ya que un paquete puede encapsularse con diferentes encabezados de nivel RPC a medida que se transmite.

El tráfico de control debe limitarse a una parte pequeña y conocida del ancho de banda de la sesión: lo suficientemente pequeño para que la función principal del protocolo de transporte, la transmisión de datos, no se vea afectada; conocido para que el tráfico de gestión se pueda incluir en la especificación de ancho de banda dada al protocolo reserva de recursos y para que cada participante pueda calcular de forma independiente su participación. Se supone que la parte del ancho de banda de la sesión asignada a RTCP debe establecerse en 5%. Todos los participantes de la sesión DEBEN utilizar la misma cantidad de ancho de banda RTCP para que el intervalo de paquetes de control calculado sea el mismo. Por lo tanto, estas constantes deben establecerse para cada perfil.

El algoritmo para calcular el intervalo entre el envío de paquetes RTCP compuestos para dividir el ancho de banda asignado para el tráfico de control entre los participantes tiene las siguientes características principales:

• los remitentes comparten al menos 1/4 del ancho de banda del tráfico de control como en las sesiones con gran cantidad destinatarios, pero con un número reducido de remitentes; tan pronto como se establece la conexión, los participantes reciben el CNAME de los sitios transmisores en un corto período de tiempo;
• Se requiere que el intervalo estimado entre paquetes RTCP sea de al menos 5 segundos para evitar ráfagas de paquetes RTCP que excedan el ancho de banda permitido cuando el número de participantes es pequeño y el tráfico no se suaviza de acuerdo con la ley de los grandes números;
• el intervalo entre paquetes RTCP varía aleatoriamente entre la mitad y la mitad de los intervalos calculados para evitar la sincronización involuntaria de todos los participantes. El primer paquete RTCP enviado después de unirse a una sesión también se retrasa aleatoriamente (hasta la mitad del intervalo RTCP mínimo) si una aplicación se inicia en varios sitios al mismo tiempo, por ejemplo, cuando se anuncia el inicio de una sesión;
• para adaptarse automáticamente a los cambios en la cantidad de información de control transmitida, se calcula una estimación dinámica del tamaño medio del paquete RTCP compuesto utilizando todos los paquetes recibidos y enviados;
• este algoritmo se puede utilizar para sesiones en las que la transmisión de paquetes es válida para todos los participantes. En este caso, el parámetro de ancho de banda de la sesión es el producto del ancho de banda del remitente individual por el número de participantes, y el ancho de banda RTP se basa en el protocolo subyacente para proporcionar una indicación de la longitud. La longitud máxima de los paquetes RTP está limitada solo por los protocolos subyacentes.

  Se pueden transportar varios paquetes RTP en una única unidad de datos de protocolo de capa inferior, como un paquete UDP. Esto reduce la redundancia de encabezados y simplifica la sincronización entre diferentes flujos.

El rápido crecimiento de Internet impone nuevas exigencias a la velocidad y el volumen de la transferencia de datos. El aumento de la capacidad de la red por sí solo no es suficiente para satisfacer todas estas demandas; se requieren métodos inteligentes y eficientes de gestión del tráfico y la congestión de la línea.

En las aplicaciones en tiempo real, el remitente genera un flujo de datos a una velocidad constante y el receptor (o receptores) deben proporcionar estos datos a la aplicación a la misma velocidad. Dichas aplicaciones incluyen, por ejemplo, conferencias de audio y video, video en vivo, diagnóstico remoto en medicina, telefonía por computadora, simulación interactiva distribuida, juegos, monitoreo en tiempo real, etc.

El protocolo de transporte más utilizado es TCP. Si bien TCP puede admitir una amplia variedad de aplicaciones distribuidas, no es adecuado para aplicaciones en tiempo real.

El nuevo protocolo de transporte en tiempo real está diseñado para resolver este problema: RTP(Protocolo de transporte en tiempo real), que garantiza la entrega de datos a uno o más destinos con un retraso dentro de los límites especificados, es decir, los datos se pueden reproducir en tiempo real.

Principios de la construcción del protocolo RTP

RTP no admite ningún tipo de entrega de paquetes, fidelidad de transmisión o mecanismos de confiabilidad de la conexión. Todas estas funciones están asignadas al protocolo de transporte. RTP se ejecuta sobre UDP y puede admitir la transferencia de datos en tiempo real entre varios participantes en una sesión RTP.

Nota

Para cada participante de RTP, una sesión se determina mediante un par de direcciones de transporte de destino de paquetes (una dirección de red: IP y un par de puertos: RTP y RTCP).

Los paquetes RTP contienen los siguientes campos: identificador del remitente que indica cuál de los participantes está generando los datos, marcas de tiempo cuando se generó el paquete para que el lado receptor pueda reproducir los datos a intervalos correctos, información sobre el orden de transmisión e información sobre la naturaleza del contenido del paquete, por ejemplo, sobre el tipo de codificación de video (MPEG, Indeo, etc.). La presencia de dicha información permite estimar el valor del retardo inicial y el tamaño del búfer de transmisión.

Nota

En un entorno típico de tiempo real, el remitente genera paquetes a una velocidad constante. Se envían a intervalos regulares, atraviesan la red y son recibidos por el destinatario, que reproduce los datos en tiempo real una vez recibidos. Sin embargo, debido a cambios en la latencia de la transmisión de paquetes a través de la red, pueden llegar a intervalos irregulares. Para compensar este efecto, los paquetes entrantes se almacenan en búfer, se adhieren durante un tiempo y luego se proporcionan a una velocidad constante. software generando salida. Por lo tanto, para que funcione el protocolo en tiempo real, cada paquete debe contener una marca de tiempo para que el receptor pueda reproducir los datos entrantes a la misma velocidad que el remitente.

Dado que RTP define (y regula) el formato de la carga útil de los datos transmitidos, el concepto de sincronización está directamente relacionado con esto, por lo que el motor de traducción RTP es en parte responsable: el mezclador. Al recibir flujos de paquetes RTP de una o más fuentes, el mezclador los combina y envía un nuevo flujo de paquetes RTP a uno o más destinatarios. El mezclador puede simplemente combinar los datos y cambiar su formato, por ejemplo, al combinar múltiples fuentes de audio. Supongamos que el nuevo sistema quiere participar en la sesión, pero su canal a la red no tiene la capacidad suficiente para soportar todas las transmisiones RTP, entonces el mezclador recibe todas estas transmisiones, las combina en una y transfiere la última al nuevo miembro de La sesión. Al recibir múltiples flujos, el mezclador simplemente agrega los valores PCM. El encabezado RTP generado por el mezclador incluye el identificador del remitente cuyos datos están presentes en el paquete.

Un dispositivo más simple, un traductor, crea un paquete RTP saliente para cada paquete RTP entrante. Este mecanismo puede cambiar el formato de los datos en el paquete o usar un conjunto diferente de protocolos de bajo nivel para transferir datos de un dominio a otro. Por ejemplo, es posible que un destinatario potencial no pueda procesar videos de alta velocidad utilizados por otros participantes en la sesión. El traductor convierte el video a un formato de menor calidad que requiere una tasa de bits menor.

Métodos de control del trabajo

RTP se usa solo para transmitir datos de usuario, generalmente multidifusión, a todos los participantes de la sesión. Junto con RTP, funciona el protocolo RTCP (Protocolo de control de transporte en tiempo real), cuya tarea principal es proporcionar control sobre la transmisión RTP. RTCP usa el mismo protocolo de transporte subyacente que RTP (generalmente UDP), pero un número de puerto diferente.

RTCP tiene varias funciones:

1. Brindar y monitorear la calidad de los servicios y retroalimentación en caso de sobrecarga. Dado que los paquetes RTCP son paquetes de multidifusión, todos los participantes de la sesión pueden apreciar qué tan bien se están desempeñando y recibiendo los demás participantes. Los mensajes del remitente permiten a los destinatarios medir la velocidad de los datos y la calidad de la transmisión. Los mensajes de los destinatarios contienen información sobre los problemas que encuentran, incluida la pérdida de paquetes y la fluctuación excesiva. Los comentarios de los destinatarios también son importantes para diagnosticar errores de distribución. Al analizar los mensajes de todos los participantes en la sesión, el administrador de la red puede determinar si un problema dado afecta a un participante o es de naturaleza general. Si la aplicación emisora ​​concluye que el problema es característico del sistema en su conjunto, por ejemplo, debido a una falla en uno de los canales de comunicación, entonces puede aumentar la tasa de compresión de datos al reducir la calidad o incluso negarse a transmitir video. esto permite que los datos se transmitan a través de la conexión de baja capacidad.
2. Identificación del remitente. Los paquetes RTCP contienen una descripción textual estándar del remitente. Proporcionan más información sobre el creador de los paquetes de datos que una ID de fuente de sincronización seleccionada al azar. Además, ayudan al usuario a identificar transmisiones de diferentes sesiones.
3. Estimación y escalado del tamaño de la sesión. Para garantizar la calidad del servicio y la retroalimentación para gestionar la congestión, así como para identificar al remitente, todos los participantes envían periódicamente paquetes RTCP. La frecuencia de transmisión de estos paquetes disminuye a medida que aumenta el número de participantes. Con un número reducido de participantes, se envía un paquete RTCP como máximo cada 5 segundos. RFC-1889 describe un algoritmo mediante el cual los participantes limitan la frecuencia de los paquetes RTCP en función del número total de participantes. El objetivo es que el tráfico RTCP no supere el 5% del tráfico total de la sesión.

Formato de encabezado RTP

RTP es un protocolo orientado a la transmisión. El encabezado del paquete RTP se creó teniendo en cuenta las necesidades de transmisión en tiempo real. Contiene información sobre el orden de los paquetes para que el flujo de datos esté correctamente ensamblado en el extremo receptor, y una marca de tiempo para el entrelazado de cuadros correcto durante la reproducción y para sincronizar múltiples flujos de datos, como video y audio.

Cada paquete RTP tiene un encabezado principal y posiblemente campos adicionales específicos de la aplicación.

El uso de TCP como protocolo de transporte para estas aplicaciones no es posible por varias razones:

1. Este protocolo solo permite una conexión entre dos puntos finales, por lo tanto, no es adecuado para la transmisión de multidifusión.
2. TCP permite la retransmisión de segmentos perdidos que llegan cuando la aplicación en tiempo real ya no los espera.
3. TCP no tiene un mecanismo conveniente para vincular la información de tiempo a los segmentos, un requisito adicional para las aplicaciones en tiempo real.

Otro protocolo de capa de transporte ampliamente utilizado, LJDP, no tiene algunas de las limitaciones de TCP, pero tampoco proporciona información de tiempo crítica.

Si bien cada aplicación en tiempo real puede tener sus propios mecanismos para admitir la transmisión en tiempo real, tienen muchas similitudes, lo que hace que sea muy deseable definir un solo protocolo.

Esta tarea tiene como objetivo resolver el nuevo protocolo de transporte en tiempo real - RTP (Real-time Transport Protocol), que garantiza la entrega de datos a uno o más destinatarios con un retraso dentro de los límites especificados, es decir, los datos se pueden reproducir en tiempo real.

En la Fig. 1 muestra un encabezado RTP fijo que contiene varios campos que identifican elementos como el formato del paquete, el número de secuencia, las fuentes, los límites y el tipo de carga útil. El encabezado fijo puede ir seguido de otros campos que contienen información adicional sobre los datos.

0

2

3

4

8

16

31

Identificador de fuente de sincronización (SSRC)
Identificadores de fuente contributiva (CSRC)

Arroz. 1. Cabecera RTP fija.

V(2 bits). Campo de versión. La versión actual es la segunda.
R(1 bit). Llenar campo. Este campo indica la presencia de octetos de relleno al final de la carga útil. El relleno se utiliza cuando la aplicación requiere que la carga útil sea un múltiplo de, por ejemplo, 32 bits. En este caso, el último octeto indica el número de octetos de relleno.
NS(1 bit). Campo de extensión de encabezado. Cuando se especifica este campo, otro encabezado opcional sigue al encabezado principal utilizado en las extensiones RTP experimentales.
SS(4 bits). Campo de recuento de remitentes. Este campo contiene el número de identificadores de los remitentes cuyos datos están en el paquete, con los propios identificadores siguiendo el encabezado principal.
METRO(1 bit). Campo de marcador. El significado del bit marcador depende del tipo de carga útil. El bit marcador se usa generalmente para indicar los límites del flujo de datos. En el caso del video, especifica el final del cuadro. En el caso de una voz, especifica el inicio del discurso después de un período de silencio.
RT(7 bits). Campo de tipo de carga útil. Este campo identifica el tipo de carga útil y el formato de los datos, incluida la compresión y el cifrado. En un estado estable, el remitente usa solo un tipo de carga útil por sesión, pero puede cambiarlo en respuesta a las condiciones cambiantes si lo indica el Protocolo de control de transporte en tiempo real.
Secuencia de números(16 bits). Campo de número de secuencia. Cada fuente comienza a numerar los paquetes con un número aleatorio, luego se incrementa en uno por cada paquete de datos RTP enviado. Esto le permite detectar la pérdida de paquetes y determinar el orden de los paquetes con la misma marca de tiempo. Varios paquetes consecutivos pueden tener la misma marca de tiempo si se generan lógicamente en el mismo momento, como los paquetes que pertenecen a la misma trama de video.
Marca de tiempo(32 bits). Campo de marca de tiempo. Este campo contiene el momento en el que se generó el primer octeto de datos de carga útil. Las unidades en las que se especifica el tiempo en este campo dependen del tipo de carga útil. El valor lo determina el reloj local del remitente.
Fuente de sincronización (SSRC) Identificador(32 bits). Campo de identificador de fuente de sincronización: un número generado aleatoriamente que identifica de forma única la fuente durante la sesión y es independiente de la dirección de red. Este número juega un papel importante en el procesamiento de la porción entrante de datos de una fuente.
Identificador de fuente contribuyente (CSRC)(32 bits). Lista de campos de identificador de fuente, "mezclados" en el flujo principal, por ejemplo, usando un mezclador. El mezclador inserta una lista completa de ID de fuente SSRC que participaron en la construcción de este paquete RTP. Esta lista se llama CSRC. El número de elementos de la lista: de 0 a 15. Si el número de participantes es superior a 15, se seleccionan los primeros 15. Un ejemplo es una audioconferencia, en la que se recopilan paquetes RTP discursos de todos los participantes, cada uno con su propio SSRC: forman la lista CSRC. Además, toda la conferencia tiene un SSRC común.

El protocolo RTCP, como cualquier protocolo de control, es mucho más complejo tanto en estructura como en las funciones que realiza (comparar, por ejemplo, IP y TCP). Aunque RTCP se basa en RTP, contiene muchos campos adicionales que utiliza para implementar sus funciones.

Protocolo de reserva de recursos - RSVP

El Protocolo de reserva de recursos (RSVP), que actualmente está siendo considerado por el Grupo de trabajo de ingeniería de Internet (IETF), aborda el problema de prioridad para los datos sensibles a la latencia, a diferencia de los datos tradicionales donde la latencia es menos crítica. RSVP permite que los sistemas finales reserven recursos de red para obtener la calidad de servicio requerida, especialmente recursos para tráfico en tiempo real a través de RTP. RSVP se ocupa principalmente de los enrutadores, aunque las aplicaciones en los puntos finales también necesitan saber cómo utilizar RSVP para reservar el ancho de banda necesario para una determinada clase de servicio o nivel de prioridad.

RTP, junto con otros estándares descritos, le permite transferir con éxito video y audio a través de redes IP convencionales. RTP / RTCP / RSVP es una solución estandarizada para redes de datos en tiempo real. Su único inconveniente es que solo está destinado a redes IP. Sin embargo, esta limitación es temporal: las redes de alguna manera se desarrollarán en esta dirección. Esta solución promete resolver el problema de la transmisión de datos sensibles a retrasos a través de Internet.

Literatura

Se puede encontrar una descripción del protocolo RTP en RFC-1889.

RTP y RTCP en VoIP

RTP es el principal protocolo de transporte en las redes de telefonía IP. RTP (Real Time Protocol) es un protocolo en tiempo real que fue creado para la transmisión de multimedia (audio, video), codificado y empaquetado en paquetes, información sobre redes IP en estrictos marcos de tiempo. Los segmentos RTP se transmiten a través de UDP e IP, respectivamente, a diferentes niveles del modelo OSI. El uso de UDP, que no garantiza la entrega, está asociado con la sincronización estricta de la transmisión de medios en tiempo real y la incapacidad de TCP para operar en tiempo real. Por tanto, a pesar de la pérdida de una parte de los datos, la puntualidad de la entrega es más importante en este caso.
V vista general la distribución por el protocolo sobre las capas del modelo OSI es la siguiente:
Capa de transporte: RTP sobre UDP
Red: IP
Canal: Ethernet
Físico: Ethernet
Al transmitir información multimedia utilizando el protocolo RTP, se utiliza la siguiente encapsulación:

El tamaño mínimo del segmento RTP es de 12 bytes. Los dos primeros bits definen la versión del protocolo. Hoy se utiliza RTPv.2. El siguiente campo P también tiene 2 bits de longitud e indica la presencia de caracteres de relleno en el campo de datos cuando se utilizan segmentos de la misma longitud. El campo X determina si se utiliza el encabezado extendido. El campo CC de 4 bits define el número de campos CSRC al final del encabezado RTP, es decir, el número de fuentes que forman el flujo. Luego viene el campo M, un bit marcador que se usa para resaltar datos importantes. El siguiente campo PT tiene una longitud de 7 bits. Diseñado para determinar el tipo de carga útil: los datos necesarios para la aplicación. Usando el código especificado, la aplicación determina el tipo de información multimedia y el método de decodificación.
El resto del encabezado consta de un campo SequenceNumber, el número de secuencia del segmento, que realiza un seguimiento del orden de los paquetes y su pérdida; Campos de marca de tiempo: código de sincronización que indica la hora de la primera muestra codificada en la carga útil; los búferes de recuperación de sincronización utilizan esta marca para eliminar las pérdidas de calidad causadas por la variación del retardo; Los campos de origen de sincronización SSRC son un número arbitrario que distingue una sesión RTP de otra para crear capacidades de multiplexación. Después de la parte fija permanente del encabezado RTP, se pueden agregar hasta 15 campos CSRC de treinta y dos bits que identifican las fuentes de datos.
Describamos el procedimiento para establecer una sesión RTP. El protocolo estableció que el tráfico diferentes tipos transmitido en sesiones de comunicación separadas. Para establecer una sesión, es necesario definir un par de direcciones de transporte de destino, es decir, una dirección de red y dos puertos para RTP y RTCP. Entonces, para una videoconferencia, es necesario transmitir audio y video en diferentes sesiones con puertos de destino correspondientemente diferentes. La transmisión de diferentes tipos de tráfico mediante el entrelazado en la misma sesión podría causar los siguientes problemas:
- al cambiar uno de los tipos de tráfico, es imposible determinar qué parámetro de la sesión necesita ser reemplazado por un nuevo valor;
- solo se usa un intervalo de tiempo para establecer una sesión, y cuando se transmite tráfico heterogéneo, cada tipo tendrá su propio intervalo, y serán diferentes;
- El mezclador RTP no puede combinar flujos intercalados de diferentes tipos de tráfico en un solo flujo;
- la transmisión de varios tipos de tráfico en una sesión RTP es imposible por las siguientes razones: el uso de diferentes rutas de red o la distribución de recursos de red; recibir un subconjunto de los datos multimedia cuando sea necesario, por ejemplo, solo audio si la señal de video ha excedido el ancho de banda disponible; implementaciones de receptores que usan procesos separados para diferentes tipos de tráfico, mientras que el uso de sesiones RTP separadas permite implementaciones de procesos únicos o múltiples.

Sin embargo, RTP (Protocolo de transporte en tiempo real) y UDP (Protocolo de datagramas de usuario) no garantizan la calidad, es decir, no funcionan con QoS (Calidad de servicio). Por lo tanto, RTP es compatible con el Protocolo de control de transporte en tiempo real (RTCP), que proporciona información adicional sobre el estado de una sesión RTP.
RTCP tiene cuatro funciones principales:
I. El objetivo principal del protocolo RTCP es proporcionar información para garantizar la calidad de la transmisión de datos. La retroalimentación puede ser directamente útil en aplicaciones de transmisión de codificación adaptativa. Además, al utilizar la multidifusión IP, es extremadamente importante que los destinatarios diagnostiquen errores en la transmisión de mensajes (paquetes). El envío de mensajes con informes de recepción permite a la parte emisora ​​determinar el motivo de la transmisión fallida del mensaje, si lo hubiera.
II. RTCP contiene un identificador de capa de transporte inmutable para el RTP de origen, que se denomina Nombre canónico o Nombre canónico. Dado que el identificador SSRC se puede cambiar en caso de colisiones (colisiones), el receptor necesita el valor Cname para rastrear a cada uno de los participantes. El destinatario también usa Cname para hacer coincidir muchos flujos de datos de un participante cuando establece múltiples sesiones al mismo tiempo, por ejemplo, para sincronizar canales de audio y video al transmitir video con audio.
III. Las dos características anteriores asumen que todos los participantes de la sesión están enviando paquetes RTCP, por lo que la velocidad de transmisión debe controlarse para que RTP establezca sesiones con una gran cantidad de usuarios. Cuando cada participante envía sus paquetes de control a todos los demás, cualquier socio puede determinar de forma independiente el número total de participantes en la sesión. Esto es necesario para calcular la tasa de transmisión de mensajes RTCP.
IV. Esta función sirve para transmitir la información de control mínima necesaria, como la identificación del participante, que utiliza la interfaz gráfica de usuario. Esta función se utiliza para sesiones poco controladas en las que los usuarios entran y salen sin una negociación adecuada de los parámetros y características. RTCP actúa como un canal conveniente para el contacto con todos los participantes, pero no necesariamente es compatible con todos los requisitos de comunicación de una aplicación.
En las redes IP que utilizan multidifusión, las funciones uno, dos y tres son obligatorias cuando se utilizan sesiones RTP. También se recomienda utilizarlos al realizar transferencias en otras redes y entornos. Hoy en día se recomienda que los desarrolladores de aplicaciones RTP utilicen herramientas que permitan trabajar en modo multicast, y no solo en uno único.
Echemos un vistazo al formato de paquete RTCP.
El protocolo estándar define varios tipos de paquetes RTCP. RTCP está diseñado para transferir información de servicio:
sr: Informe del remitente. Es necesario para las estadísticas de recepción y transmisión de los participantes de la sesión que son remitentes directamente activos;
rr: Informe del destinatario. Requerido para estadísticas de participantes que no son destinatarios;
sdes: describe la fuente, incluye Cname;
bye: Sirve para indicar el final (salida) de la sesión;
aplicación: funciones específicas de la aplicación;
Cada paquete RTCP consta de una parte constante, al igual que el protocolo RTP, que utilizan los paquetes RTP, seguida de campos que pueden variar en longitud según el tipo de paquete, pero múltiplos de 32 bits. Los requisitos de alineación y el campo de longitud en la parte fija del encabezado se introducen para concatenar los paquetes RTCP. Se pueden concatenar varios paquetes RTCP entre sí sin introducir separadores para obtener un paquete RTCP compuesto que se envía a través de un protocolo de transporte de capa baja como UDP. No hay un contador específico para paquetes RTCP individuales, ya que el protocolo de capa baja establecerá la longitud total y determinará el final del paquete compuesto.


El formato del paquete RTCP del mensaje del remitente es el siguiente, como se muestra en la figura anterior.

Los paquetes RTCP están sujetos a las siguientes comprobaciones de validación.
- El campo de la versión RTP debe ser igual a 2.
- El campo de tipo de datos del primer paquete RTCP en un paquete compuesto será SR o RR.
- El bit de relleno (P) debe ser cero para el primer paquete de un paquete RTCP compuesto, ya que el relleno solo puede estar presente en el último.
- La longitud de los campos del paquete RTCP individuales debe sumar la longitud total del paquete compuesto.

Si algún día tienes que descubrir rápidamente qué es VoIP (voz sobre IP) y qué significan todas estas abreviaturas salvajes, espero que este tutorial te ayude. Observo de inmediato que los problemas de configuración de tipos adicionales de servicios de telefonía (como transferencia de llamadas, correo de voz, conferencias telefónicas, etc.) no se consideran aquí.

Entonces, de lo que trataremos debajo del corte:

1. Conceptos básicos telefonía: tipos de dispositivos, esquemas de conexión
2. Paquete de protocolos SIP / SDP / RTP: cómo funciona
3. Cómo se transmite la información sobre los botones presionados
4. Cómo se transmiten la voz y los faxes
5. Procesamiento de señales digitales y aseguramiento de la calidad del sonido en telefonía IP

1. Conceptos básicos de telefonía

En general, el esquema para conectar un abonado local a un proveedor de telefonía a través de una línea telefónica regular es el siguiente:

Un módulo telefónico con un puerto FXS (Suscriptor de intercambio extranjero) está instalado en el lado del proveedor (PBX). En casa o en la oficina, se instala un teléfono o fax con un puerto FXO (Foreign eXchange Office) y un módulo de marcador.

Por aspecto externo los puertos FXS y FXO no difieren de ninguna manera, estos son conectores RJ11 ordinarios de 6 pines. Pero con la ayuda de un voltímetro es muy fácil distinguirlos: siempre habrá algo de voltaje en el puerto FXS: 48/60 V cuando está colgado, o 6-15 V durante una llamada. En FXO, si no está conectado a la línea, el voltaje siempre es 0.

Para transferir datos a través de una línea telefónica en el lado del proveedor, se necesita lógica adicional, que se puede implementar en el módulo SLIC (circuito de interfaz de línea del suscriptor) y en el lado del suscriptor, utilizando el módulo DAA (Arreglo de acceso directo).

Hoy en día, los teléfonos inalámbricos DECT (telecomunicaciones digitales inalámbricas europeas) son bastante populares. Por diseño, son similares a los teléfonos comunes: también tienen un puerto FXO y un módulo de marcador, pero también se ha agregado un módulo inalámbrico estaciones y teléfonos a 1,9 GHz.

Los suscriptores están conectados a la red PSTN (red telefónica pública conmutada), una red telefónica pública, también conocida como PSTN, PSTN. La red PSTN se puede organizar usando diferentes tecnologias: RDSI, óptica, POTS, Ethernet. Un caso especial de PSTN, cuando se utiliza una línea normal analógica / de cobre - POTS (Servicio telefónico antiguo normal) - un sistema telefónico antiguo y sencillo.

Con el desarrollo de Internet comunicaciones telefónicas cambiado a nuevo nivel... Los teléfonos fijos se utilizan cada vez menos, principalmente para necesidades comerciales. Los teléfonos DECT son un poco más convenientes, pero están limitados por el perímetro de la casa. Los teléfonos GSM son aún más convenientes, pero están limitados dentro del país (el roaming es caro). Pero para los teléfonos IP, también son softphones (SoftPhone), no hay restricciones, excepto para el acceso a Internet.

Skype es el ejemplo más famoso de softphone. Puede hacer muchas cosas, pero tiene dos inconvenientes importantes: la arquitectura cerrada y las escuchas telefónicas se conocen por qué autoridades. Por el primero, no hay forma de crear su propia micro-red telefónica. Y debido al segundo, no es muy agradable que lo espíen, especialmente durante las conversaciones personales y comerciales.

Afortunadamente, existen protocolos abiertos para crear sus propias redes de comunicación con ventajas: estos son SIP y H.323. Hay un poco más de softphones basados ​​en el protocolo SIP que en H.323, lo que puede explicarse por su relativa simplicidad y flexibilidad. Pero a veces esta flexibilidad puede encajar grandes palos en las ruedas. Tanto SIP como H.323 utilizan el protocolo RTP para transferir medios.

Consideremos los principios básicos del protocolo SIP para comprender cómo se conectan dos suscriptores.

2. Descripción de un paquete de protocolos SIP / SDP / RTP

SIP (Session Initiation Protocol) es un protocolo para establecer una sesión (no solo telefónica), es un protocolo basado en texto sobre UDP. También es posible utilizar SIP sobre TCP, pero estos son casos raros.

SDP (Session Description Protocol) es un protocolo para negociar el tipo de datos transmitidos (para audio y video, estos son códecs y sus formatos, para faxes - velocidad de transmisión y corrección de errores) y sus direcciones de destino (IP y puerto). También es un protocolo basado en texto. Los parámetros SDP se transmiten en el cuerpo de los paquetes SIP.

RTP (Protocolo de transporte en tiempo real) es un protocolo de transferencia de datos de audio / video. Es un protocolo binario sobre UDP.

Estructura general de paquetes SIP:

• Start-Line: un campo que indica el método SIP (comando) cuando se solicita o el resultado de ejecutar un método SIP al responder.
• Encabezados: información adicional a la línea de inicio, formateada como líneas que contienen pares ATRIBUTO: VALOR.
• Cuerpo: datos binarios o de texto. Normalmente se utiliza para transferir parámetros o mensajes SDP.

A continuación, se muestra un ejemplo de dos paquetes SIP para un procedimiento común: configuración de llamada:

A la izquierda está el contenido del paquete SIP INVITE, a la derecha - la respuesta - SIP 200 OK.

Los campos principales están resaltados con marcos:

• Method / Request-URI contiene el método SIP y el URI. En el ejemplo, se establece una sesión: el método INVITE, una llamada al suscriptor [correo electrónico protegido]
• Código de estado: código de respuesta al comando SIP anterior. En este ejemplo, el comando se completó con éxito: código 200, es decir, el suscriptor 555 descolgó el teléfono.
• Vía: la dirección en la que el suscriptor 777 está esperando una respuesta. Para un mensaje 200 OK, este campo se copia del mensaje INVITE.
• De / A: el nombre para mostrar y la dirección del remitente y el destinatario del mensaje. Para un mensaje 200 OK, este campo se copia del mensaje INVITE.
• Cseq contiene el número de secuencia del comando y el nombre del método al que pertenece este mensaje... Para un mensaje 200 OK, este campo se copia del mensaje INVITE.
• Content-Type es el tipo de datos que se transmite en el bloque Body, en este caso, datos SDP.
• Información de conexión: dirección IP a la que el segundo suscriptor necesita enviar paquetes RTP (o paquetes UDPTL en caso de transmisión de fax a través de T.38).
• Descripción de medios: el puerto al que el segundo suscriptor debe transmitir los datos especificados. En este caso, se trata de sonido (audio RTP / AVP) y una lista de tipos de datos admitidos: PCMU, PCMA, códecs GSM y señales DTMF.

Un mensaje SDP consta de líneas que contienen pares CAMPO = VALOR. De los campos principales, puede observar:

• o- Origen, el nombre del organizador de la sesión y el ID de la sesión.
• con- Información de conexión, campo descrito anteriormente.
• metro- Descripción de medios, campo descrito anteriormente.
• a- atributos de los medios, especifique el formato de los datos transmitidos. Por ejemplo, indique la dirección de recepción o transmisión del sonido (sendrecv), para los códecs indique la frecuencia de muestreo y el número de referencia (rtpmap).

Los paquetes RTP contienen datos de audio / video codificados en un formato específico. Este formato especificado en el campo PT (tipo de carga útil). Tabla de correspondencia de valores de este campo formato específico, consulte https: // wikipedia org wiki Perfil de audio y video RTP.

Los paquetes RTP también contienen un identificador SSRC único (define la fuente del flujo RTP) y una marca de tiempo (marca de tiempo, utilizada para la reproducción uniforme de audio o video).

Un ejemplo de interacción entre dos suscriptores SIP a través de un servidor SIP (Asterisk):

Tan pronto como se inicia el teléfono SIP, lo primero que registra en el servidor remoto (SIP Registar), le envía un mensaje de REGISTRO SIP.

Cuando se llama a un suscriptor, se envía un mensaje SIP INVITE, cuyo cuerpo contiene un mensaje SDP, que especifica los parámetros de transmisión de audio / video (qué códecs son compatibles, a qué IP y puerto enviar sonido, etc.).

Cuando el suscriptor remoto descuelga el teléfono, recibimos un mensaje SIP 200 OK también con parámetros SDP, solo el suscriptor remoto. Con los parámetros SDP enviados y recibidos, puede establecer una sesión de transmisión de audio / video RTP o una sesión de transmisión de fax T.38.

Si los parámetros SDP recibidos no nos convenían, o el servidor SIP intermedio decidió no pasar tráfico RTP a través de sí mismo, entonces se realiza el procedimiento de renegociación SDP, el llamado REINVITE. Por cierto, es precisamente debido a este procedimiento que los servidores proxy SIP gratuitos tienen un inconveniente: si ambos suscriptores están en la misma red local y el servidor proxy está detrás de NAT, luego de redirigir el tráfico RTP, ninguno de los suscriptores escuchará otro.

Una vez finalizada la conversación, el suscriptor que cuelga el teléfono envía un mensaje SIP BYE.

3. Transferencia de información sobre botones presionados

A veces, después de establecer una sesión, durante una conversación, necesita acceder a tipos de servicios adicionales (ADO): retención de llamadas, transferencia, correo de voz, etc. - que reaccionan a ciertas combinaciones de botones presionados.

Entonces, en una línea telefónica normal, hay dos formas de marcar un número:

• Pulse: históricamente el primero, se utilizó principalmente en teléfonos con marcador rotatorio. La marcación se produce debido al cierre y apertura secuenciales de la línea telefónica de acuerdo con el dígito marcado.
• Tono: marcar un número con códigos DTMF (multifrecuencia de tono dual): cada botón del teléfono tiene su propia combinación de dos señales (tonos) sinusoidales. Al ejecutar el algoritmo de Goertzel, es bastante fácil determinar el botón presionado.

Durante una llamada, el método de pulso es inconveniente para transmitir el botón presionado. Entonces, toma alrededor de 1 segundo transmitir "0" (10 pulsos de 100 ms: 60 ms - salto de línea, 40 ms - cierre de línea) más 200 ms para una pausa entre dígitos. Además, a menudo se escucharán clics característicos durante la marcación por pulsos. Por lo tanto, en telefonía ordinaria, solo se usa el modo de acceso por tonos al VAS.

En telefonía VoIP, la información sobre los botones presionados se puede transmitir de tres formas:

1. DTMF en banda: generación de un tono de audio y su transmisión dentro de los datos de audio (canal RTP actual): se trata de una marcación por tono normal.
2. RFC2833: se genera un evento telefónico de paquete RTP especial, que contiene información sobre la tecla presionada, el volumen y la duración. El número del formato RTP en el que se transmitirán los paquetes DTMF RFC2833 se especifica en el cuerpo del mensaje SDP. Por ejemplo: a = rtpmap: 98 teléfono-evento / 8000.
3. SIP INFO: un paquete SIP INFO se forma con información sobre la tecla presionada, el volumen y la duración.

La transmisión DTMF dentro de los datos de audio (en banda) tiene varios inconvenientes: estos son recursos de sobrecarga al generar / incrustar tonos y durante su detección, limitaciones de algunos códecs que pueden distorsionar los códigos DTMF y poca confiabilidad durante la transmisión (si se pierden algunos de los paquetes, entonces la detección puede ocurrir presionando dos veces la misma tecla).

La principal diferencia entre DTMF RFC2833 y SIP INFO: si el servidor proxy SIP habilita la transmisión RTP directamente entre suscriptores sin pasar por el servidor en sí (por ejemplo, canreinvite = yes en asterisco), entonces el servidor no notará los paquetes RFC2833, como resultado de lo cual se convierten servicios no disponibles FEB. Los paquetes SIP siempre se transmiten a través de servidores proxy SIP, por lo que VAS siempre funcionará.

4. Transmisión de voz y fax

Como ya se mencionó, el protocolo RTP se utiliza para transferir datos multimedia. Los paquetes RTP siempre indican el formato de los datos transmitidos (códec).

Hay muchos códecs diferentes para la transmisión de voz, con diferentes relaciones de tasa de bits / calidad / complejidad, los hay abiertos y cerrados. Cualquier softphone definitivamente tiene soporte para codecs alaw / ulaw G.711, su implementación es muy simple, la calidad de sonido no es mala, pero requieren un ancho de banda de 64 kbps. Por ejemplo, el códec G.729 requiere solo 8 kbps, pero es muy intensivo en el procesador y, además, no es gratuito.

Para la transmisión de fax, se suele utilizar el códec G.711 o el protocolo T.38. La transmisión de fax G.711 es la misma que la transmisión de fax T.30, como si el fax se enviara a través de una línea telefónica normal, pero al mismo tiempo Señal analoga de la línea se digitaliza de acuerdo con la ley alaw / ulaw. Esto también se denomina transmisión de fax en banda T.30.

Los faxes T.30 negocian sus parámetros: velocidad de transmisión, tamaño del datagrama, tipo de corrección de errores. El protocolo T.38 se basa en el protocolo T.30, pero a diferencia de la transmisión en banda, se analizan los comandos T.30 generados y recibidos. De esta forma, no se transmiten datos brutos, sino comandos de control de fax reconocidos.

Para transmitir comandos T.38, se usa el protocolo UDPTL, es un protocolo basado en UDP, se usa solo para T.38. Para transferir comandos T.38, aún puede usar los protocolos TCP y RTP, pero se usan con mucha menos frecuencia.

Las principales ventajas de T.38 son una carga de red reducida y una mayor fiabilidad en comparación con la transmisión de fax en banda.

El procedimiento para enviar un fax en modo T.38 es el siguiente:

1. Se establece una conexión de voz regular mediante cualquier códec.
2. Cuando se carga papel en el fax de envío, envía periódicamente una señal T.30 CNG (tono de llamada) para indicar que está listo para enviar el fax.
3. En el lado de recepción, se genera una señal T.30 CED (Identificación de terminal llamado): esta es la disposición para recibir un fax. Esta señal se envía después de presionar el botón "Recibir fax" o el fax lo hace automáticamente.
4. En el lado de envío, se detecta la señal CED y se produce el procedimiento SIP REINVITE, y el tipo T.38 se indica en el mensaje SDP: m = imagen 39164 udptl t38.

Es deseable transmitir faxes a través de Internet en T.38. Si el fax debe transmitirse dentro de la oficina o entre objetos con una conexión estable, se puede utilizar la transmisión de fax Inband T.30. En este caso, antes de enviar un fax, el procedimiento de cancelación de eco debe desactivarse para no introducir distorsiones adicionales.

El libro Fax, módem y texto para telefonía IP, de David Hanes y Gonzalo Salgueiro, es muy detallado sobre la transmisión de fax.

5. Procesamiento de señales digitales (DSP). Garantizar la calidad del sonido en telefonía IP, ejemplos de prueba

Descubrimos los protocolos para establecer una sesión de conversación (SIP / SDP) y el método de transmisión de audio a través del canal RTP. Queda un problema importante: la calidad del sonido. Por un lado, la calidad del sonido viene determinada por el códec seleccionado. Pero, por otro lado, todavía se necesitan procedimientos DSP adicionales (DSP - procesamiento de señal digital). Estos procedimientos tienen en cuenta las peculiaridades de la telefonía VoIP: no siempre se usa un auricular de alta calidad, hay caídas de paquetes en Internet, a veces los paquetes llegan de manera desigual, el ancho de banda de la red tampoco es de goma.

Procedimientos básicos para mejorar la calidad del sonido:

VAD(Detector de actividad de voz): procedimiento para detectar tramas que contienen voz (trama de voz activa) o silencio (trama de voz inactiva). Esta separación puede reducir significativamente la carga en la red, ya que la transmisión de información sobre el silencio requiere muchos menos datos (basta con transmitir el nivel de ruido o no transmitir nada en absoluto).

Algunos códecs ya contienen procedimientos VAD (GSM, G.729), para otros (G.711, G.722, G.726) es necesario implementarlos.

Si el VAD está configurado para transmitir información sobre el nivel de ruido, los paquetes SID especiales (Descriptor de inserción de silencio) se transmiten en formato RTP CN (ruido de confort) de 13 m.

Vale la pena señalar que los servidores proxy SIP pueden eliminar paquetes SID, por lo que, para la verificación, es aconsejable configurar la transmisión del tráfico RTP más allá de los servidores SIP.

GNC(generación de ruido de confort): procedimiento para generar ruido de confort basado en la información de los paquetes SID. Por lo tanto, VAD y CNG funcionan en conjunto, pero el procedimiento de GNC tiene mucha menos demanda, ya que no siempre es posible notar el funcionamiento del GNC, especialmente a bajo volumen.

SOCIEDAD ANÓNIMA(ocultación de pérdida de paquetes): procedimiento para recuperar un flujo de audio en caso de pérdida de paquetes. Incluso con una pérdida de paquetes del 50%, un buen algoritmo de PLC logra una calidad de voz aceptable. Habrá distorsiones, por supuesto, pero las palabras se pueden distinguir.

La forma más fácil de emular la pérdida de paquetes (en Linux) es usar la utilidad tc del paquete iproute con el módulo netem. Solo da forma al tráfico saliente.

Un ejemplo de cómo iniciar una emulación de red con una pérdida de paquetes del 50%:

Tc qdisc change dev eth1 pérdida de red raíz 50%

Deshabilitar la emulación:

Tc qdisc del dev eth1 raíz

Búfer de fluctuación- un procedimiento para eliminar el efecto de fluctuación, cuando el intervalo entre los paquetes recibidos varía mucho y que, en el peor de los casos, conduce a un orden incorrecto de los paquetes recibidos. Además, este efecto conduce a interrupciones en el habla. Para eliminar el efecto de fluctuación, es necesario implementar un búfer de paquetes en el lado receptor con un tamaño suficiente para restaurar el orden original de envío de paquetes con un intervalo dado.

También puede emular el efecto de jitter utilizando la utilidad tc (el intervalo entre el momento esperado de llegada del paquete y el momento real puede ser de hasta 500 ms):

tc qdisc agregar dev eth1 root netem delay 500ms reordenar 99%

LEC(Cancelador de eco de línea): procedimiento de cancelación de eco local cuando el sitio remoto comienza a escuchar su propia voz. Su esencia es restar la señal recibida de la señal transmitida con un cierto coeficiente.

Los ecos pueden ocurrir por varias razones:

• eco acústico debido a una ruta de audio de baja calidad (el sonido del altavoz ingresa al micrófono);
• eco eléctrico debido al desajuste de impedancia entre teléfono y el módulo SLIC. La mayoría de las veces, esto ocurre en una línea telefónica de 4 hilos a 2 hilos.

No es difícil averiguar el motivo (eco acústico o eléctrico): el abonado en cuyo lado se genera el eco debe apagar el micrófono. Si el eco aparece de todos modos, entonces es eléctrico.

Para obtener más información sobre los procedimientos de VoIP y DSP, consulte el libro Procesamiento de señales de voz y fax de VoIP. Hay una vista previa disponible en Google Books.

Sobre este teórico superficial Descripción general de VoIP terminado. Si está interesado, en el próximo artículo se puede considerar un ejemplo de implementación práctica de una mini-PBX en una plataforma de hardware real.

[!?] Preguntas y comentarios son bienvenidos. Serán respondidas por el autor del artículo Dmitry Valento, ingeniero de software del centro de diseño de electrónica de Promwad.

Etiquetas:

• para principiantes
• para novatos

Agregar etiquetas