Anexo I. VoIPbibing.us.es/proyectos/abreproy/11969/fichero/Memoria... · que no se permita la transmisión de datos si no pueden ser gestionados por el receptor. H.323 es un estándar

MIGRACIÓN DE UN SISTEMA DE TELEFONÍA EN PRODUCCIÓN HACIA VOIP CON ASTERISK 93

Anexo I. VoIP


1. VoIP

1.1. CARACTERÍSTICAS FUNDAMENTALES DE UNA RED NGN (ITU-T. Rec. Y-2001)

Como ha visto en el apartado correspondiente, una red NGN (Next Generation Networking) es una red basada en paquetes que permite prestar servicios de telecomunicación en la que se pueden utilizar múltiples tecnologías de transporte de banda ancha propiciadas por la QoS (Quality of Service), y en la que las funciones relacionadas con los servicios son independientes de las tecnologías subyacentes relacionadas con el transporte. Permite a los usuarios el acceso sin trabas a redes y a proveedores de servicios y/o servicios de su elección. Se soporta movilidad generalizada que permitirá la prestación coherente y ubicua de servicios a los usuarios. Las características que debe cumplir son:

� Transporte basado en conmutación de paquetes multiservicio: multiplexión estadística y aprovechamiento óptimo de la red. Se puede dar sobre ATM o sobre IP, sin embargo, se prefiere IP aprovechando su ubicuidad. � Separación de las funciones de control en: capacidad de la portadora, control de la sesión o llamada y servicio o aplicación.

� Desacoplo entre la provisión del servicio y la red de transporte: provisión de interfaces normalizados, desarrollo y despliegue rápido de servicios, evolución independiente de red de servicios y transporte… � Interfuncionamiento con redes heredadas: GSM, RTC, RDSI, FR… usando interfaces abiertas. Se usan pasarelas (GW) para el interfuncionamiento entre operadores de redes NGN y otras redes, por ejemplo la red telefónica.

� Soporte de movilidad generalizada (usuario, terminal) donde se lleva a cabo:

� Gestión de identidad (de usuario, de dispositivo, localización, presencia, autenticación, registro…)

� Gestión dinámica de sesión (control de sesión, ancho de banda y QoS por sesión, tarificación)

� Gestión de la movilidad (heredada de GSM/UMTS, suscripción a servicios, invocación, itinerancia, movilidad de usuario,…)

� Numeración, nombrado y direccionamiento: dado que NGN está compuesta por multitud de redes heterogéneas, accesos heterogéneos y terminales heterogéneos, los usuarios individuales deben ser identificaos por nombres o números y se debe usar un método fiable para la resolución de nombres/números que sea capaz de traducir un nombre/número dado a una dirección IP. El método debe ser fiable, integro y seguro.

1.2. PROTOCOLO H.323. El estándar H.323 proporciona la base para la transmisión de voz, datos y vídeo sobre redes no orientadas a conexión y que no ofrecen un grado de calidad del


servicio, como son las basadas en IP, incluida Internet, de manera tal que las aplicaciones y productos conforme a ella puedan interoperar, permitiendo la comunicación entre los usuarios sin necesidad de que éstos se preocupen por la compatibilidad de sus sistemas. La LAN sobre la que los terminales H.323 se comunican puede ser un simple segmento o un anillo, o múltiples segmentos (es el caso de Internet) con una topología compleja, lo que puede resultar en un grado variable de rendimiento. H.323 es la especificación, establecida por la UIT (Unión Internacional de Telecomunicaciones) en 1996, que fija los estándares para la comunicación de voz y vídeo sobre redes de área local, con cualquier protocolo, que por su propia naturaleza presentan una gran latencia y no garantizan una determinada calidad del servicio (QoS). Para la conferencia de datos se apoya en la norma T.120, con lo que en conjunto soporta las aplicaciones multimedia. Los terminales y equipos conforme a H.323 pueden tratar voz en tiempo real, datos y vídeo, incluida videotelefonía. El estándar contempla el control de la llamada, gestión de la información y ancho de banda para una comunicación punto a punto y multipunto, dentro de la LAN, así como define interfaces entre la LAN y otras redes externas, como puede ser la RDSI. Es una parte de una serie de especificaciones para videoconferencia sobre distintos tipos de redes, que incluyen desde la H.320 a la H.324, estas dos válidas para RDSI y RTC, respectivamente. H.323 establece los estándares para la compresión y descompresión de audio y vídeo, asegurando que los equipos de distintos fabricantes se entiendan. Así, los usuarios no se tienen que preocupar de cómo el equipo receptor actúe, siempre y cuando cumpla este estándar. La gestión del ancho de banda disponible para evitar que la LAN se colapse con la comunicación de audio y vídeo, por ejemplo, limitando el número de conexiones simultáneas, también está contemplada en el estándar. La norma H.323 hace uso de los procedimientos de señalización de los canales lógicos contenidos en la norma H.245, en los que el contenido de cada uno de los canales se define cuando se abre. Estos procedimientos se proporcionan para fijar las prestaciones del emisor y receptor, el establecimiento de la llamada, intercambio de información, terminación de la llamada y como se codifica y decodifica. Por ejemplo, cuando se origina una llamada telefónica sobre Internet, los dos terminales deben negociar cual de los dos ejerce el control, de manera tal que sólo uno de ellos origine los mensajes especiales de control. Una cuestión importante es, que se deben determinar las capacidades de los sistemas, de forma que no se permita la transmisión de datos si no pueden ser gestionados por el receptor. H.323 es un estándar creado por el grupo de estudio 16 de la ITU-T para la transmisión de voz, vídeo y datos multimedia a través de redes basadas en conmutación de paquetes sin calidad de servicio (QoS) garantizada, como las redes IP. Inicialmente, H.323 fue diseñado para transportar voz y vídeo en redes de área local, aunque posteriores revisiones del estándar habilitaron su expansión a redes de área amplia como Internet y mejoraron ciertas deficiencias del diseño inicial. La arquitectura de H.323 define todo lo necesario (componentes, protocolos, señalización, códecs...etc) para llevar a cabo la comunicación y garantizar así la compatibilidad entre dispositivos.


La norma H.323 hace uso de los procedimientos de señalización de los canales lógicos contenidos en la norma H.245, en los que el contenido de cada uno de los canales se define cuando se abre. Estos procedimientos se proporcionan para fijar las prestaciones del emisor y receptor, el establecimiento de la llamada, intercambio de información, terminación de la llamada y como se codifica y decodifica. Por ejemplo, cuando se origina una llamada telefónica sobre Internet, los dos terminales deben negociar cual de los dos ejerce el control, de manera tal que sólo uno de ellos origine los mensajes especiales de control. Una cuestión importante es, como se ha dicho, que se deben determinar las capacidades de los sistemas, de forma que no se permita la transmisión de datos si no pueden ser gestionados por el receptor. Los protocolos usados son:

� H.225 para el control de llamadas (incluyendo señalización, registro y admisión) y la sincronización y empaquetamiento de flujos de medios. � H.235 para la seguridad y cifrado � H.245 para la señalización de control y la apertura/cierre de canales multimedia � H.450 para los servicios suplementarios. � RTP/RTCP para el transporte de contenido multimedia � T.120 como protocolo de datos para conferencia multimedia

Toda esta información se ve más claramente en la figura siguiente: .

Figura 40. Arquitectura de protocolos de H.323


1.3. PROTOCOLO SIP (Session Inicial Protocol) En las arquitecturas de red VoIP se usan para señalización ambos protocolos. Tanto uno como otro ofrecen ventajas y desventajas en función de la arquitectura concreta sobre la que se vaya a trabajar. Se ha tomado como base el artículo ‘Comparación entre H.323 v4 y SIP’ realizado por William Sánchez [6] así como diversos estudios comparativos que aparece en la bibliografía. En función de este artículo y las características propias del escenario de trabajo, se ha analizado la mejor opción para la señalización a usar en la solución propuesta.

Definición

El protocolo de inicio de sesión SIP (Session Inicial Protocol) es un protocolo de señalización de nivel de aplicación que permite crear, modificar y terminar sesiones con uno o más participantes en redes IP. Fue desarrollado por el grupo de trabajo MMUSIC del IETF y actualmente se encuentra recogido en la RFC 3261. Entre estas sesiones se incluyen conferencias multimedia, llamadas telefónicas a través de Internet, sesiones de enseñanza a distancia, sesiones de acceso a información multimedia distribuida, etc.…El protocolo SIP contempla, además, procedimientos de desvío, permitiendo así la implementación de servicios de red inteligente, de movilidad personal… que tratan de solventar los problemas derivados de la actuación de los participantes en las sesiones. En conclusión, SIP presta soporte a cinco facetas relacionadas con el establecimiento y la liberación de comunicaciones multimedia:

1. Localización de usuario destino. 2. Determinación de las capacidades – tiempos medios y parámetros- que el

usuario puede o desea emplear en la comunicación. 3. Determinación de la disponibilidad del usuario llamado para incorporarse a

la sesión (aceptar la llamada). 4. Establecimiento de la llamada y sus parámetros en ambos extremos de la

comunicación. 5. Gestión de la llamada, incluyendo transferencia, liberación …

Una aplicación puede hacer uso del protocolo SIP en cualquiera de sus facetas. De este modo, el protocolo SIP supone una alternativa a otros protocolos, o bien es susceptible de utilizarse en conjunción con otros protocolos de establecimiento y señalización. Los participantes en una sesión pueden comunicarse mediante procedimientos de multidistribución, mediante un conjunto de conexiones punto a punto o empleando una combinación de ambos mecanismos. Las sesiones se crean mediante un proceso de invitación a participar en las mismas. Las invitaciones incluyen descripciones de las sesiones, que facilitan a los participantes negociar unos medios y formatos compatibles con las capacidades de sus terminales, además, una vez establecida una sesión es posible modificar los parámetros de los medios empleados, así como incorporar a la misma medios adicionales y nuevos participantes. De ello se ocuparé el protocolo SDP (Session Description Protocol). SDP no se encarga de entregar los contenidos propiamente dichos sino de entablar una negociación entre las entidades que intervienen en la sesión como tipo de contenido, formato, y todos los demás parámetros asociados. Este conjunto de parámetros se conoce como perfil de sesión. En el apartado siguiente “Protocolo de descripción de sesiones” se profundiza en ello.


SIP no es un sistema de integración vertical de comunicaciones. SIP es más bien un componente que se puede usar con otros protocolos de IETF para construir una arquitectura multimedia completa. Normalmente, estas arquitecturas incluyen protocolos tales como RTP (Real-time Transport Protocol, RFC 1889), para el transporte de información multimedia en tiempo real (incluyendo video, audio y texto). El protocolo permite codificar y dividir los datos en paquetes y el transporte de estos paquetes a través de Internet. En paralelo con RTP, se usará un protocolo que permita proporcionar calidad de servicio, RTSP (Real Time Streaming Protocol, RFC 2326) estableciendo y controlando uno o muchos flujos sincronizados de datos, ya sean de audio o de video. SIP se ha diseñado en conformidad con el modelo de Internet. Se trata de un protocolo de señalización extremo a extremo donde toda la lógica se almacena en los sistemas finales (excepto el enrutamiento de mensajes SIP). Este concepto, es una divergencia importante de la PSTN regular (Public Switched Telephone Network) donde estado y lógica se almacena en la red y los dispositivos de terminales son primitivos. El objetivo de SIP, es proporcionar la misma funcionalidad que las PSTN tradicional pero extremo a extremo lo que hace que el diseño de redes SIP sea mucho más potente y abierto a la implementación de nuevos servicios que pueden ser aplicadas apenas en la PSTN tradicional. Sin embargo, ambas redes deben coexistir y poder utilizarse. Para ello se hace uso de pasarelas a las que se entregarán los medios, cuyo control recaerá en un protocolo de comunicación denominado MEGACO (Media Gateway Control, RFC 3015). Es importante resaltar, que la naturaleza de los servicios prestados hace que la seguridad sea particularmente importante. Para ello, SIP proporciona un conjunto de servicios de seguridad que incluyen la denegación de servicio por prevención, la autenticación (tanto de usuarios para el usuario como de proxy para el usuario), la protección de la integridad y la encriptación y los servicios de privacidad. En resumen, SIP debe utilizarse en conjunción con otros protocolos a fin de proporcionar un servicio completo a los usuarios. Sin embargo la funcionalidad básica y el funcionamiento de SIP no dependen de ninguno de esos protocolos.

Elementos de Red

Su arquitectura básica es la natural cliente/servidor: un terminal SIP está compuesto por entidades de tipo cliente y de tipo servidor por lo que puede generar peticiones y respuestas. Existen dos componentes de la arquitectura de las redes SIP: el SIP User Agent y el SIP Network Server.

Agente de usuario SIP User Agent es el sistema terminal que contiene un componente cliente, conocido como ‘cliente de agente de usuario’ el (UAC, User Agent Client) que genera las peticiones, y un componente servidor, conocido como el (UAS, User Agent Server) que responde a las peticiones.

� User Agent Client (UAC): es una entidad lógica que inicia una transacción SIP con una petición SIP (SIP request).


� User Agent Server (UAS): es una entidad lógica que responde a una petición SIP, generalmente actuando en nombre de algún usuario. La respuesta acepta, rechaza o redirecciona la petición. Por lo tanto, cualquier componente software puede actuar como UAC o bien como UAS si mas tarde recibe una petición.

Funciona del siguiente modo, las solicitudes SIP son iniciadas por una aplicación UAC a instancias de un usuario, que puede ser humano o no. Cuando el servidor de agente de usuario (UAS) recibe la solicitud procedente del cliente, contacta con el usuario llamado y le consulta sobre la acción que debe tomar (responder la llamada, ignorarla…). De acuerdo con las instrucciones del usuario devuelve una respuesta en su nombre, aceptando, rechazando o desviando la llamada. El procedimiento por el cual el UAC realiza una petición al UAS y el las normas que rigen el mismo están descritas en el anexo correspondientes (obtenidas del RFC 3261) Además del agente de usuario, existen algunos agentes más que se detallan a continuación:

� Agente de Presencia: recolecta y proporciona información de presencia vía SIP u otros procedimientos. Ofrece un servicio de suscripción a eventos. Enviará notificaciones a la lista de los elementos suscritos, generadas directamente por el PA, que trabaja apoyándose en el proxy SIP tanto para enviar como para recibir mensajes. No implementa, pues, los mismos mensajes que el resto y debe ser accesible en todo momento. Cuando un elemento se suscribe al evento “presence”, es decir, cuando se produce una nueva suscripción, el PA recupera los datos del elemento suscrito, los añade a una lista y envía los mensajes de tipo NOTIFY correspondientes con información en una cadena de bytes en formato XML.

� Pasarela de Señalización: caso particular de agente de usuario donde este es un protocolo. Habitualmente tiene un elevado número de usuarios y realiza conversiones entre SIP e ISUP, CAS, Q.931, H.323…

� Adosado: pasarela de aplicación que genera nuevos mensajes SIP. Realmente funciona como un traductor de mensajes SIP-SIP para servicios especiales como por ejemplo facilitar el anonimato. Sortea cortafuegos y NAT (Network Address Translation).

Servidores. SIP Network Server

Es un elemento de la red que maneja la señalización asociada a llamadas múltiples. Existen tres tipos de servidores:

� Servidor de Intermediación o Proxy: representa a un agente o servidor para el reenvío o contestación de mensajes. No genera peticiones, solo las reenvía (la alteración del mensaje SIP es limitada y está normalizada, no se toca el orden ni se borran campos). No entiende de medios y no procesa contenido de mensajes SIP (información de sesión).Existen dos tipos:

� Proxy con estado (SIP Stateful Proxy): es una entidad lógica que

mantiene la información a cerca del estado de la llamada durante la transacción SIP. Recuerda la petición entrante que ha recibido junto con las respuestas que ha enviado y con las peticiones generadas a raíz de la inicial. Los Stateful Proxy Servers generalmente son


componentes locales más cercanos a UA (User Agent), controlan los dominios de usuario y son la primera plataforma para acceder a las aplicaciones.

� Proxy sin estado (SIP Stateless Proxy): olvida toda la información una vez que ha enviado la respuesta a una petición. Esto permite enviar una petición de manera simultánea a varios terminales (“forking”). Los Servidores Proxy que son Stateless (no mantienen el estado) son por lo general muy rápidos y se encuentran en el backbone de la infraestructura SIP.

� Servidor de redirección: acepta una solicitud SIP, a continuación relaciona la

dirección de destino que tiene con cero, una o más nuevas direcciones y, finalmente las devuelve al cliente. Realmente lo que hace es indicar la localización del destinatario y para ello usa respuestas 3xx (Redirection).

� Servidor de Registro: el servidor de registro acepta solicitudes de un tipo

particular, denominado REGISTER, mediante las cuales un cliente hace saber en qué dirección o direcciones puede alcanzarse, es decir, permite al agente de usuario indicar una dirección de contacto que sustituye a la actual. Las direcciones se conocen por configuración, dominio o multicast. La comunicación con el servidor de redirección o de intermediación de su dominio esta fuera del ámbito SIP (puden residir en el mismo equipo físico).

Al igual que el servidor Proxy, el servidor de redirección y el de registro se presentan en sus versiones con y sin estado. En la

Figura 41 se muestra la arquitectura necesaria para una sesión.

Figura

41.Señalización SIP en una llamada


Identificación de los usuarios

Las partes participantes en una llamada son identificadas mediante un identificador de recursos uniforme, o URI (‹‹Uniform Resource Identifier››), de una clase especial denominada URI SIP. Un URI, en sentido general, consiste en una tira de caracteres con una sintaxis particular mediante la cual se identifica de forma compacta un recurso disponible vía Internet. Los URI se utilizan, por ejemplo, para nombrar recursos a los que un usuario puede acceder mediante el servicio WWW. Para un estudio más en profundidad consultar el Anexo II. VOIP. IV. Identificador de Recursos Uniforme. Un URI SIP presenta una estructura como se muestra a continuación:

sip: [email protected]; parámetros

� La sección de usuario consiste en un nombre de usuario de una red IP o en un número de teléfono. � La segunda parte identifica al dominio al que pertenece administrativamente el usuario.

Además, las URI de SIP contienen otra serie de parámetros separados de la dirección principal por medio de punto y coma que determinan algunas de las características de la conexión. Ejemplo de ellos es el parámetro “transport” que determina el mecanismo utilizado en el transporte de peticiones y respuestas SIP, siendo UDP (‹‹User Datagram Protocol ››) el mecanismo por defecto y TCP (‹‹Transmission Control Protocol ››), TLS (‹‹Transport Layer Security ››), y SCTP (‹‹Stream Control Transmission Protocol ››) otros de los mecanismos posibles. El parámetro “maddr” indica la dirección del servidor con la que hay que contactar para comunicarse con ese usuario, sobrescribiendo los datos proporcionados por el campo “host”. Esta dirección normalmente es una dirección multicast. La dirección sip de un usuario se obtiene por diferentes vías. A continuación se muestran algunos ejemplos: sip:[email protected] sip:alice:[email protected];transport=tcp sips:[email protected]?subject=project%20x&priority =urgent sip:+1-212-555-1212:[email protected];user=phone sips:[email protected] sip:[email protected]

El URI tipo SIP puede designar a un usuario individual, el cual es posible que se halle localizable en diferentes sistemas finales, mediante el servicio de movilidad personal, a un grupo de usuarios o a la primera persona disponible de un grupo. Sin embargo, la principal ventaja de este modo de direccionar es la capacidad de movilidad, una de las principales características de la filosofía SIP; las direcciones URI ofrecen un método con el que el usuario se identifica en múltiples terminales y localizaciones, rompiendo con el concepto de la telefonía tradicional de que número de abonado se asocia a una única entidad física. En la mayoría de los casos la dirección SIP o URL coincidirá con la dirección de e-mail del usuario. El uso de “dominio” nos libera de tener que especificar la dirección numérica del servidor, pues los servidores DNS se encargan de resolver la relación nombre- dirección.


Estructura de los Mensajes

Una vez conocidas las características básicas del protocolo SIP, resulta indispensable, para comprender sus mecanismos, detenerse en el estudio de los formatos de los mensajes intercambiaos. SIP usa sintaxis textual con elementos SMTP11 (‹‹Simple Mail Transfer Protocol ››) y HTTP12 (‹‹HyperText Transfer Protocol ››). Los mensajes intercambiados son de dos tipos: solicitudes también llamadas métodos o respuestas. Las solicitudes son los mensajes enviados por los procesos clientes, mientras que las respuestas son los mensajes devueltos por los servidores. Ambos tipos de mensajes tienen una estructura genérica como la mostrada a continuación:

Línea de Inicio+ Línea de Cabecera + Cuerpo opcional El cuerpo del mensaje, en el caso del protocolo SIP se utiliza para transportar las descripciones de las sesiones de medios especificadas según el formato de SDP (consultar anexo III.1). A continuación se describen los componentes fundamentales de los mensajes:

� Línea de inicio: tipo de mensaje. Es distinto en la solicitud y en la respuesta por ello se detallará más concretamente en el apartado destinado a cada uno de ellos.

� Vía: identificador del equipo. Este campo informa sobre el camino seguido por la solicitud hasta el momento presente (todos los servidores por los que ha pasado). Cada uno de los servidores que atraviesa la solicitud antes de llegar al agente de usuario llamado, van agregando una línea que los identifica. Este campo aparece como:

� Max-forwards: este campo se usa para limitar el máximo número de saltos que podrá dar el mensaje en su camino hacia el destino. Es un número entero que se reduce en uno en cada salto. Si el valor de Max-Forwards llega a 0 antes de que la solicitud llegue a su destino, será rechazada con la respuesta de error 483 (Too Many Hops). Normalmente el valor inicial es 70.Este número fue elegido porque era lo suficientemente grande como para garantizar que una solicitud no sería eliminada de una red SIP cuando hay lazos redundantes, pero no tan grande como para aumentar considerablemente el consumo de recursos cuando se produce un bucle. Los valores más bajos deben utilizarse con precaución y sólo en las topologías de redes en las que se conoce al agente de usuario.

� From: direcciones de origen, identifica al usuario que ha iniciado la solicitud. El servidor copia este campo en las respuestas correspondientes. Es importante

11 Protocolo Simple de Transferencia de Correo, es un protocolo de la capa de aplicación. Protocolo de red basado en texto utilizado para el intercambio de mensajes de correo electrónico entre computadoras u otros dispositivos (PDA's, teléfonos móviles, etc.). Está definido en el RFC 2821 y es un estándar oficial de Internet. 12 El protocolo de transferencia de hipertexto (HTTP, HyperText Transfer Protocol) es el protocolo usado en cada transacción de la Web (WWW). HTTP define la sintaxis y la semántica que utilizan los elementos software de la arquitectura web (clientes, servidores, proxies) para comunicarse. Es un protocolo orientado a transacciones y sigue el esquema petición-respuesta entre un cliente y un servidor. Se recoge en RFC 2616


que el de URI no contiene direcciones IP o el FQDN13 de la máquina en la que la UA se está ejecutando, ya que estos no son nombres lógicos.

� To: Especifica la dirección destino de la solicitud. El servidor copia este campo en sus respuestas. En SIP tanto la dirección origen como la destino son de la forma: [email protected].

� Call-Id: este campo identifica de forma única una invitación (INVITE) particular. Debe ser el mismo para todas las solicitudes y las respuestas enviadas por cualquiera de las UA en un diálogo. Debe ser el mismo en cada registro de una UA. Una invitación que contiene un campo Call-Id que hace

referencia a una sesión ya establecida debe interpretarse como una solicitud de modificación de la sesión ya establecida. Un ejemplo:

Call-ID: [email protected] ar.com

� Cseq: es el número de secuencia del mensaje y se usa para detectar duplicidades (no pérdidas) y correlado (en ACK). Las retransmisiones de la misma solicitud deben contener el mismo número de secuencia; pero a una solicitud del mismo tipo con campos de cabecera o un cuerpo distinto (por ejemplo, una reinvitación, dentro de un proceso de negociación de parámetros) debe asignarse un número de secuencia superior. El servidor incluye en sus respuestas el Cseq de la solicitud a que se refiere (correlado). Un ejemplo de este campo:

CSeq: 4711 INVITE

� Contact: dirección de acceso directo a terminal. Proporciona un URI donde el usuario puede ser localizado en comunicaciones siguientes.

Estos campos integran la cabecera del mensaje. La línea de inicio es diferente en el método y en la respuesta.

Métodos

La solicitud o método, comienza con una línea de inicio como la siguiente:

Método+ URI_Solicitud + Versión El método contiene la orden concreta de la solicitud. En la tabla siguiente se detallan los métodos soportados y la función de cada uno. El campo URI_Solicitud identifica al destinatario de la solicitud y consiste en una URI14 tipo SIP. En el anexo II sub-apartado ‘Identificador de Recursos Uniforme, URI’ se profundiza respecto a esto. 13Fully Qualified Domain Name es un nombre que incluye el nombre de la computadora y el nombre de dominio asociado a ese equipo. Por ejemplo, dada la computadora llamada «serv1» y el nombre de dominio «bar.com», el FQDN será «serv1.bar.com», a su vez un FQDN asociado a serv1 podría ser «post.serv1.bar.com».

14 Uniform Resource Identifier, identificador uniforme de recurso, definido en RFC 2396 (Uniform Resource Identifiers: Generic Syntax). Algunos URI pueden ser URL, URN o ambos. Un URI es una cadena corta de caracteres que identifica inequívocamente un recurso (servicio, página, documento, dirección de correo electrónico, enciclopedia, etc.). Normalmente estos recursos son accesibles en una red o sistema.


El campo versión, proporciona información sobre la versión del protocolo que se está usando. La versión más reciente es SIP/2.0. Método Función INVITE Permite invitar a un usuario a participar en una sesión

ACK Confirma que el cliente ha recibido una respuesta final a una solicitud de invitación INVITE

OPTIONS Se emplea para interrogar a un servidor sobre sus capacidades, sin que ello suponga el establecimiento de una sesión

BYE El UAC usa este método para expresar su deseo de liberar la llamada CANCEL Solicita la cancelación de una solicitud pendiente de respuesta

REGISTER Transporta información sobre las direcciones donde puede localizarse un usuario. La solicitud se envía a un servidor de registro

Tabla 7.Métodos del protocolo SIP

A continuación se muestra un ejemplo de método: INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnas hds8 Max-Forwards: 70 To: Bob <sip:[email protected]> From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 142

Respuestas

El mensaje de respuesta comienza con una línea de estado (línea de inicio) con el siguiente formato:

Versión+Código de Estado + Frase Razón El campo versión es igual al del método. El código de estado consiste en un número entero de tres dígitos que indica el resultado del intento, por parte del servidor, de entender y satisfacer la solicitud recibida. El primero de los dígitos del código define la clase de respuesta. Así, las respuestas se organizan en las siguientes categorías:

� De información (1xx): indican que la solicitud se ha recibido y que su procesamiento continúa. Por ejemplo, el servidor puede notificar al cliente que el agente de usuario que el timbre del terminal llamado está sonando. � De éxito (2xx): significan que la solicitud se recibió con éxito, se entendió y aceptó.


� De desvío (3xx): informan del requerimiento de acciones adicionales para completar su solicitud. Este tipo de respuestas se utilizan, por ejemplo, para ofrecer determinados servicios suplementarios como el desvío de llamadas. � De error de cliente (4xx): se devuelve este tipo de código cuando la solicitud contiene un error de sintaxis o cuando es imposible llevarla a cabo, por ejemplo, porque el terminal llamado está ocupado, porque se requiere autenticación o porque el método no está permitido. � De error de servidor (5xx): se produce este tipo de errores cuando el servidor falló al tratar de ejecutar una solicitud aparentemente válida. Una situación en la que cabe la posibilidad de aparición de tales errores es cuando el servidor no dispone de una función requerida para completar la solicitud. � De fallo global (6xx): se utiliza esta clase de códigos para informar de que la solicitud no puede ser atendida por ningún servidor, por ejemplo, porque todos los posibles terminales de destino para una llamada se encuentran ocupados.

La frase de razón consiste en un texto corto que acompaña al código de estado con la finalidad que proporcionar una explicación del mismo legible por humanos. Otros datos adicionales relativos a la respuesta del servidor pueden incluirse en el campo de la cabecera de respuesta denominado Warning. En particular los problemas relacionados con la descripción de sesión contenida en el cuerpo de la solicitud se señalan en este campo. Algunos de los problemas referibles son los siguientes: los medios indicados en la solicitud o sus formatos no se encuentran disponibles, el protocolo de red o de transporte en incompatible, el ancho de banda demandado es excesivo… Gracias a este campo es posible establecer un proceso de negociación de los parámetros de la sesión que va a establecerse. Así, cuando un servidor detecta que la descripción de la sesión recibida en una solicitud INVITE contiene parámetros no aceptables, puede devolver una respuesta del tipo 606 (No aceptable) señalando en el campo Warning los motivos de la denegación. El cuerpo del mensaje de respuesta incluiría una descripción de sesión con los parámetros aceptables. El cliente dispone de la opción, ante este tipo de respuesta, de intentar enviar una nueva solicitud conteniendo una descripción de sesión con nuevos parámetros, adaptados a las preferencias expresadas por el servidor. Un ejemplo que ilustra la respuesta al método del apartado anterior sería: SIP/2.0 200 OK Via: SIP/2.0/UDP server10.biloxi.com; branch=z9hG4b K4b43c2ff8.1 ; received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com; branch=z9hG4bK77ef4c2312983.1 ; received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com; branch=z9hG4bKna shds8 ; received=192.0.2.1 To: Bob <sip:[email protected]>;tag=a6c85cf From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 131


1.4. PROTOCOLO DE DESCRIPCIÓN DE SESIONES El protocolo de descripción de sesiones (SDP, ‹‹ Session Description Protocol ››) ha sido diseñado para ser portador de la información requerida por un usuario para unirse a una conferencia o para establecer una nueva sesión con otro usuario. En realidad, y a pesar de su nombre, se trata de n formato de descripción de sesiones (más que de un protocolo de transporte) que hace uso de distintos mecanismos de transporte de información disponibles en Internet: correo electrónico, protocolo de transporte de hipertexto, etc. Aunque su principal aplicación se encuentra en las sesiones de multiconferencia, el propósito de este formato es más general, siendo posible su utilización en otros contextos.

Información proporcionada por SDP

Fundamentalmente, la información que proporciona SDP sobre una sesión determinada incluye los siguientes datos:

� Nombre y propósito de la sesión � Los medios que se emplean en la sesión. Esta información comprende: los tipos de medios (audio, video…), el protocolo de transporte usado para cada uno (ej. RTP/UDP/IP), y su formato (vídeo H.261, vídeo MPEG, etc.) � La información necesaria para recibir dichos medios; es decir, la dirección y el puerto de transporte utilizados para cada medio. � Los periodos de tiempo durante los cuales la sesión está activa. Las sesiones pueden estar acotadas o no en el tiempo, pero, en cualquier caso, únicamente se encontrarán activas durante periodos de tiempo específicos. Así pues, esta información puede indicarse de diferentes modos: como una lista arbitraria de tiempos de inicio y fin de la sesión, si la sesión está acotada; como un horario que se repite periódicamente, por ejemplo, cada viernes a las 15h, durante una hora, etc.

Frecuentemente, los recursos disponibles por un usuario para participar en la sesión son limitados; por este motivo, también se proporciona información sobre el ancho de banda que va a emplearse en la conferencia. Opcionalmente, se facilitan los datos de contacto de la persona responsable de la sesión, quien puede resolver dudas adicionales.

Especificación de SDP

Las descripciones de sesiones especificadas mediante SDP son enteramente textuales. Así pues, una descripción de sesión SDP consiste en un conjunto de líneas de texto. El formato de cada una de estas líneas es el siguiente:

Tipo= valor (sin espacio en blanco entre el carácter = y cada uno de los campos). El campo ‘tipo’ está constituido por un único carácter ASCII, mientras que el campo ‘valor’ es un texto estructurado cuyo formato depende de ‘tipo’. Los anuncios de sesiones se estructuran en dos niveles:

� Un nivel de descripción de sesión, cuyas especificaciones afecta a la sesión completa y a los flujos de medios. � Un nivel de descripción de medios, que contiene detalles a un único flujo.


Un anuncio de sesión esta constituido por una sección de nivel de sesión seguida por cero o más secciones de nivel de medios. La parte correspondiente a nivel de sesión comienza con la línea ‹‹v= (versión del protocolo) ›› y termina cuando empieza la primera sección de descripción de medios. Cada sección de descripción de medios empieza con una línea ‹‹m=…›› y continúa hasta la descripción del siguiente medio (nueva línea ‹‹m=…››) o hasta que finaliza el anuncio completo de la sesión. Las líneas que aparecen en cada descripción de sesión se detallan a continuación. Algunas líneas son de carácter obligatorio, mientras que las marcadas con el símbolo ‹‹*›› son opcionales. En cualquier caso, las líneas deben escribirse en orden espaciado. Sección de descripción de Sesiones

� v= (versión del protocolo, actualmente la ‹‹0››). � o= (identificador de la sesión y de su creador, indicando el tipo de red y la

dirección. � s= nombre de la sesión � i=*información sobre la sesión � u=*URI de la descripción � e=*dirección de correo electrónico de la persona responsable � p=*número de teléfono de la persona responsable � c=*información sobre la conexión, no requerida si se incluye en cada medio. � b=*información sobre el ancho de banda.

Una o más descripciones de tiempo en el formato:

� t=tiempo durante el cual la sesión está activa � r=*cero o varios periodos de repetición

Otros campos:

� z=*ajuste de zona de tiempos � k=*información sobre el cifrado � a=*cero o más líneas de atributos de la sesión.

Sección de descripción de medios

� m=tipo de medio, puerto de transporte, protocolo de transporte y formato empleado. Los tipos de medios definidos son audio, vídeo, aplicación, datos y control.

� i=*título del medio � c=*información sobre la conexión, opcional, si se incluye en el nivel de

sesión. � b=*información sobre el ancho de banda. � k=*información sobre el cifrado. � a=*cero o más líneas de atributos. Los atributos dependen del tipo de medio

empleado y permiten aportar mayor información sobre ellos.

Ejemplo de descripción de sesión

v= 0 o= profesorSAT 2890844526 2890842807 IN IP 125.116. 64.109 s= las conferencias de Internet. i= Seminario sobre los protocolos implicados en las co nferencias de Internet. u= http://www.ic.tel.es/sat/conf.html e= [email protected] (profesor MDT)


c= IN IP4 224.2.17.12/127 t=2873397496 2873404696 a= recvonly m= audio 49170 RTP/AVP 0 m= video 51372 RTP/AVP 31 m= application 32416 udp wb a=orient:portrait

Figura 42. Ejemplo de anuncio de conferencia en formato SDP Algunos comentarios referentes al ejemplo mostrado en la Figura 42. La descripción de la sesión consta de tres secciones:

� Una sección de nivel de sesión, que comienza con una línea ‹v›› y cuya última línea es la ‹‹a››. � Tres secciones de nivel de medio, cada una de las cuales empiezan con una línea ‹‹m›› y describe uno de los medios que va a emplearse.

Sección de nivel de sesión:

� Línea v: Esta línea, que da comienzo a la sección, indica que la versión de SDP utilizada en la descripción es la ‹‹0››.

� Línea o: La tira de caracteres ‹‹profesorSAT›› identifica al usuario que organiza la sesión. Los números que aparecen a continuación son el número de sesión y su versión, respectivamente. Seguidamente se indican los datos de la máquina del usuario organizador: el tipo de red (Internet, IN, en este caso), el tipo de dirección (dirección en formato IPv4) y, por último, el valor de la dirección.

� Línea s: Informa sobre el título de la conferencia ‹‹Las conferencias de Internet››

� Línea i: Contiene un breve resumen sobre el tema de la conferencia. � Línea u: URI de una página web donde puede encontrase información

adicional sobre la conferencia. � Línea e: Dirección de correo de la persona responsable de la conferencia. � Línea c: Proporciona información sobre la dirección que debe ‹‹sintonizarse››

para asistir a la conferencia. La dirección se expresa como: tipo de red (Internet, IN), tipo de dirección (IPv4), valor de la dirección y TTL (‹‹Time To Live››), campo que restringe el ámbito de multidistribución de la conferencia.

� Línea t: Informa sobre los tiempos de inicio y fin de la conferencia. � Línea a: Atributo de la sesión indicando que los asistentes sólo pueden

actuar como oyentes, no como emisores. Sección de medios ‹‹ m= audio 49170 RTP/AVP 0››: Contiene una sola línea ‹‹m›› especificando las propiedades de la señal de audio: se enviarán al puerto ‹‹49170››, empleando el protocolo RTP como mecanismo de transporte y utilizando una codificación denominada AVP 0. Obsérvese que, en relación a este medio, no se especifica una dirección de red, sino un puerto de nivel de transporte. La razón es que en esta sesión los medios se multiplexan en el nivel de transporte, utilizándose una sola dirección de multidistribución para todos ellos. Además, sólo se especifica un número de puerto, el correspondiente al protocolo RTP, que además es par. Para el protocolo de control asociado, RTCP, se sobrentiendo, por convenio, que debe emplearse el número de puerto siguiente, el ‹‹49171››, que es impar.


Sección de medios ‹‹ m= video 51372 RTP/AVP 31››: Como en el caso anterior, una sola línea es suficiente para especificar los datos relativos a la señal de vídeo: protocolo de transporte RTP en el puerto ‹‹51372›› (puerto, para RTCP) y perfil de codificación AVP 31. Sección de medios ‹‹ m=application 32416 udp wb ››: Además de audio y vídeo, se utilizará una aplicación de pizarra compartida (‹‹wb››=‹‹whiteboard››), cuyos datos se envían al puerto ‹‹32416›› mediante el protocolo UDP. La segunda línea de esta sección define un atributo para esta aplicación: la orientación de la pizarra, que se representará en vertical (‹‹portrait››).

Utilización de SDP

El formato SDP puede ser empleado para describir todo tipo de sesiones de conferencia. Un primer ejemplo de aplicación de las descripciones de sesiones mediante SDP puede encontrarse en las sesiones que hacen uso de invitaciones explícitas a los participantes. Así, por ejemplo, algunos mensajes del protocolo SIP contienen una descripción de la sesión que va a tener lugar. Estas descripciones se emplean para tomar decisiones relativas a la aceptación de la invitación a la sesión o para negociar sus parámetros. La descripción de la sesión puede expresarse haciendo uso del formato SDP. Un segundo ámbito de aplicación de SDP son las conferencias con un extenso círculo de asistentes, en las cuales se permite que estos se unan a la misma sin previa invitación expresa. Las descripciones de sesión proporcionan, en este caso, datos suficientes para que los usuarios que lo deseen se incorporen a la conferencia. Los métodos más habituales de difundir estas descripciones de sesión son los siguientes:

� Anuncio mediante multidistribución: una alternativa habitual de anunciar una sesión de conferencia consiste en el envío periódico, mediante mecanismos de multidistribución, de paquetes de anuncio a una dirección de grupo y puerto de multidistribución previamente acordados. Para ello hace uso del denominado Protocolo de Anuncio de Sesión (SAP, ‹‹Session Announcement Protocol››). Cuando las descripciones de sesión son transportadas mediante SAP, sólo se permite una descripción de sesión por paquete. � Anuncio mediante correo electrónico y WWW: el correo electrónico MIME y el protocolo de transporte de hipertexto (HTTP) constituyen dos medios alternativos al anterior para el envío de descripciones de sesiones. En ambos casos, se hace uso del tipo de contenido MIME15(‹‹Multipurpose Internet Mail Extensions ››) específico ‹‹aplication/sdp››. La ventaja de estos tipos de mecanismos de transporte SDP reside en que permiten que desde el mismo cliente WWW o desde el programa lector de correo se lancen automáticamente las aplicaciones necesarias para participar en la sesión. Cuando se emplean estos medios de transporte para SDP, se permite que varias descripciones de

15 MIME es el acrónimo inglés de (Multipurpose Internet Mail Extensions), (Extensiones Multipropósito de Correo de Internet). Consiste en una serie de convenciones o especificaciones dirigidas a que se puedan intercambiar a través de Internet todo tipo de archivos (texto, audio, vídeo, etc.) de forma transparente para el usuario. Una parte importante del MIME está dedicada a mejorar las posibilidades de transferencia de texto en distintos idiomas y alfabetos


sesiones sean transportadas de forma concatenada. En ese caso, cada línea ‹‹v=›› indica el comienzo de una nueva descripción y el final del anterior.

Identificador de recursos uniforme, URI

Un identificador de recursos uniforme o URI (‹‹Uniform Resource Identifier››) consiste en una tira de caracteres con una sintaxis particular, mediante la cual se identifica de forma compacta un recurso disponible vía Internet. Los caracteres permitidos en los URI son de tres clases:

� Reservados: su uso se restringe a servir como delimitadores de las componentes del URI. Estos caracteres reservados son: ‹‹;››,‹‹/››,‹‹?››,‹‹:››,‹‹@››,‹‹&››,‹‹=››,‹‹+››,‹‹$›› y ‹‹,››. � No reservados: no tienen un propósito especial. Pertenecen a este grupo de caracteres las letras mayúsculas y minúsculas, los dígitos decimales y los siguientes signos de puntuación: ‹‹-››, ‹‹_››, ‹‹.››, ‹‹!››, ‹‹~››, ‹‹*››, ‹‹|››. � Secuencia de escape: Los datos-octetos que no poseen una representación mediante caracteres no reservados se codifican como un triplete de caracteres constituido por el carácter ‹‹%›› seguido de dos caracteres más que simbolizan los dígitos hexadecimales del octeto.

Los URIs se clasifican en dos categorías:

� URL (‹‹Uniform Resource Locator››) o Localizador de Recursos Uniforme: subconjunto de URIs que identifican a un recurso mediante la representación de su mecanismo de acceso, por ejemplo, indicando su localización en la red. El URL resultará familiar a los usuarios habituales del servicio WWW. � URN (‹‹Uniform Resource Name››) o Nombre de Recursos Uniforme: subconjunto de URI que son globalmente únicos y persistentes, cuya principal función consiste en etiquetar un recurso con un identificador. Este identificador forma parte de un espacio de nombramiento definido, con una estructura de nombres y unos procedimientos de asignación de nombres propios.

Algunos esquemas de URI adoptan un sistema de nombramiento jerárquico, donde los diferentes niveles en la jerarquía del nombre se delimitan mediante el símbolo ‹‹/›› separando los componentes del nombre. En este caso, los URI pueden ser absolutos o relativos:

� URI absoluto: hace referencia a un recurso determinado independientemente del contexto en que se utilice el identificador. � URI relativo: identifica al recurso dentro de un contexto. El URI relativo hace referencia al recurso mediante la descripción de la diferencia entre el nombre jerárquico y que identifica el contexto actual y el identificador absoluto del recurso. La combinación del URI relativo de un recurso y un URI base identificador del contexto da lugar a un URI absoluto.

La sintaxis básica de un URI absoluto es la siguiente:

URI_absoluto= <esquema> ‹‹:››<parte_especifica_de_esquema> El esquema define el espacio de nombramiento, es decir, restringe la sintaxis y semántica de los identificadores que siguen ese esquema. Muchos URL reciben el nombre de un protocolo, que habitualmente es el que debe emplearse para obtener el recurso, aunque ello no implica que el protocolo sea el único necesario o posible para acceder a él. Entre los posibles esquemas se encuentran:


Esquema Definición

sip URI de SIP, en el To;From;Contact;Request-URI;etc. sips URI de SIP seguro, sobre TLS tel URI de un número E.164, en To: o From: pres URI de agente de presencia im URI de cliente de mensajería instantánea malito URL de correo electrónico, en Contact: http URL Web

Tabla 8.URIS en SIP

Como se puede apreciar en al Tabla 8.URIS en SIP además de los esquemas, aparecen los campos del mensaje en los que puede ser usado. La sintaxis de un URI no requiere que la parte_especifica_del_esquema presente una estructura general o semántica común a todos los URI. No obstante, existe un subconjunto de URI que comparten una sintaxis común. Dicha sintaxis representa una serie de relaciones jerárquicas dentro del espacio de nombramiento. La sintaxis genérica de estos URI es la siguiente:

<esquema>‹‹:›› <autoridad> <camino> ? <pregunta>

� Componente de esquema: define la semántica del resto del URI, es decir, el modo en que debe interpretarse. Los URI relativos no comienzan con un nombre de esquema; en lugar de ello, el esquema se hereda del URI base. Esta propiedad permite discernir un URI relativo de uno absoluto. � Componente autoridad: representa el nivel jerárquico superior, del cual depende el resto de la URI. Generalmente, la autoridad es un servidor de Internet, aunque también se admite otro tipo de autoridad de nombramiento especifica. � Componente camino: contiene datos específicos de la autoridad (o del esquema si no existe el componente autoridad) que identifican el recurso dentro del ámbito del esquema y de la autoridad. Consiste en una secuencia de segmentos del camino separados por el carácter ‹‹/››, cada uno de los cuales alude a un nivel jerárquico. � Componente pregunta: está formado por una tira de caracteres que contienen información que debe ser interpretada por el recurso. Se utiliza, por ejemplo, cuando el recurso es un programa que ofrece un servicio.


Anexo II. Codificación de voz e

imágenes


1.5. SELECCIÓN DE UN CODEC DE AUDIO

Premisas a tener en cuenta a la hora de seleccionar el códec de audio

La VoIP enfrenta problemáticas propias de las redes de datos, que se manifiestan como degradaciones en la calidad del servicio percibida por los usuarios (QoE). Estas degradaciones pueden deberse por ejemplo a retardos, jitter (diferencia de retardos) y pérdida de paquetes, entre otros factores. Todos estos parámetros son específicos de cada uno de los códecs, por lo que la elección del mismo (en función de las características del escenario sobre el que trabajar) irá completamente ligada a la calidad de servicio percibida por los usuarios de la misma. En el anexo correspondiente, aparece una comparativa entre los parámetros de los distintos códecs obtenida de la norma G114 de la ITU-T. En una codificación normal se emplea el códec g711 o PCM, que es un estándar para la digitalización de señales de audio, ampliamente usado en sistemas RSDI, CD de audio, etc.., si queremos reducir el tamaño de los bits necesarios para cada muestra sin perder información, será necesario algún tipo de algoritmo de compresión. Bajo esta idea se crean otro tipo de códecs, que reducen significativamente el ancho de banda necesario, pero que requieren de mayor capacidad de proceso y ofrecen algo menos de calidad, ejemplos de estos algoritmos son g726, g728 o g729. Este estudio se centrará básicamente en el análisis de los códecs G711 y G729 cuyas características ofrecen una mejor solución a la arquitectura existente.

Factores críticos para VoIP

Los tres principales factores técnicos que afectan la efectividad de una red VoIP son Latencia, Jitter y Razón de Pérdida de Paquetes (DPR), asociados a factores sensitivos como la claridad de la voz, el retraso y el eco.

� Latencia: Latencia se refiere al tiempo necesario para que un paquete VoIP sea transferido desde el origen al destino. Esto implica los tiempos de procesamiento tales como codificación de la señal de voz y empaquetado. Según el estándar G.114 del The International Telecommunication Union (ITU) se considera que la latencia máxima total debe ser < 150ms (véase tabla) para comunicación de voz de alta calidad.

� Jitter: Las variaciones de la latencia producen el fenómeno Jitter, que se manifiesta en una pérdida de datos debido a que el buffer de entrada del dispositivo receptor de paquetes VoIP no logró mantener la cantidad de paquetes para ser procesados. Se produce un “vacío” de datos que se manifiesta en “cortes” de la señal de voz. El Jitter está más relacionado con las latencias variables. El RFC 1889 define el Jitter como la desviación promedio de la variación de la latencia entre dos paquetes transmitidos. Para la estimación del Jitter y posterior ajuste del buffer, se utiliza el tiempo marcado en el paquete RTP (Si) que ingresa al destino y se compara con el reloj RTP en el receptor (Ri). Así, para dos paquetes i y j, se define Jitter como:

D(i, j) = (Rj − Ri) − (Sj − Si)

La variable Jitter, supeditada a un fenómeno estocástico, debe ser estudiada una vez que suceda, mediante análisis de tráfico, en las condiciones críticas.


Para predecir el fenómeno fuera del campo, es necesario realizar simulaciones.

� Relación de pérdida de paquetes: DPR por sus siglas en inglés, corresponde

a la relación de paquetes perdidos que pueden afectar seriamente la transferencia de información de voz en una comunicación. En general, una instalación de red local bien lograda, cumpliendo con las normas correspondientes, garantiza la no pérdida de paquetes [3]. Sin embargo, cuando los buffers de los switches se colapsan, se producen pérdida de paquetes. Esto se puede solventar mediante el soporte de mecanismos agresivos para evitar el bloqueo en los switches

Control de latencias variables

Para evitar al máximo el incremento de la latencia, la presencia de Jitter y pérdida de paquetes, se emplean herramientas de Calidad de Servicio (QoS), tales como Clasificación, Colas y Reserva de Recursos.

� Clasificación de paquetes VoIP: Es posible marcar los paquetes VoIP desde el origen, utilizando las marcas de la capa 2, conocidas como Class of Services. Esto corresponde al campo User Priority de la porción 802.1p dentro del encabezado 802.1Q. También es posible marcar los paquetes a nivel de IP, mediante el campo Type of Service del encabezado IPv4, conocido como los bits de Servicios Diferenciados (DiffServ).

� Colas: El uso de colas distintas para cada tipo de tráfico clasificado dentro de

los switches, permite disminuir la probabilidad de pérdida de paquetes y Jitter [1]. La clasificación se hace de acuerdo a prioridades.

� Reservación de Recursos: La reservación de recursos se divide en dos

partes: Fijos y Dinámicos. La reservación Fija corresponde al establecimiento de los recursos de red de acuerdo al diseño, tales como la selección de enlaces de un determinado ancho de banda, etc. La reservación Dinámica corresponde a la asignación de recursos, tales como ancho de banda, trunking, etc, que pueden ser realizados de forma dinámica, dependiendo de la contingencia. Una de las técnicas de reservación de recursos dinámica se conoce como RSVP; una vez que los terminales VoIP inician una conexión, los equipos de red establecen valores que aseguran la propagación de los paquetes en la menor latencia posible.

Ancho de Banda disponible para VoIP.

El análisis del ancho de banda se resume a calcular en ancho de banda que ofrece el puerto de conexión y el análisis del número de llamadas simultáneamente, en función de los parámetros de los códecs de voz motivo de estudio. A continuación se muestra un breve resumen sobre las características expuestas anteriormente para cada uno de los códecs:


Figura 43. Torre de protocolos medios VoIP

Tabla 9. Códecs y Características La torre de protocolo empleada en una comunicación VoIP usando Ethernet (como será el caso a tratar) se muestra en la torre de protocolos que se muestra a su izquierda y a la derecha se muestran los anchos de banda necesarios para los distintos códecs. A continuación se detallan estos datos:

(12 )

(8 ) (20 )

Tamañodelpaquetefinal Bytescodec CabeceraRTP bytes

CabeceraUDP bytes CabeceraIP bytes

= + ++

( )* ( )

( )* º *2

BytesCodec Tiempodehabla ms TasadeTxon Kbps

Bandwidth Tamañodelpaquete bytes N depaquetesporsegundo

==

Como se indicó anteriormente el análisis se centrará en los códecs G711 y G729:

3 1.711 30*10 *64000 * 240

8(240) (12 )

(8 ) (20 ) (18 ) 298

298

bytebitsBytecódecG s bytess bitsTamañodelpaquetefinal Bytescodec CabeceraRTP bytes

CabeceraUDP bytes CabeceraIP bytes CabeceraEthernet bytes bytes

Bandwidth

−= =

= + ++ + =

=3

1 8* * *2 158933

30*10 1

paquete bitsbytes bitspaquete ss byte− =

3 1.711 30*10 *8000 * 30

8(30) (12 )

(8 ) (20 ) (18 ) 88

88

bytebitsBytecódecG s bytess bitsTamañodelpaquetefinal Bytescodec CabeceraRTP bytes

CabeceraUDP bytes CabeceraIP bytes CabeceraEthernet bytes bytes

bytesBandwidth

−= =

= + ++ + =

=3

1 8* * *2 469933.33

30*10 1

paquete bits bitspaquete ss byte− =


Una vez justificados los valores de las tablas y conocidas las premisas que guiarán la comparativa se procederá a realizar dicho estudio apoyándose en las definiciones y parámetros indicados en este apartado.

Estudio para seleccionar el códec en función de la Arquitectura:

Los códecs de voz tienen un comportamiento no lineal con las degradaciones que ocurren en la red (pérdida de paquetes, latencia y jitter). Los modernos códecs vocales actúan sobre conjuntos de muestras vocales conocidos como tramas. Cada bloque de muestras vocales de entrada se procesa para convertirlo en una trama comprimida. La trama vocal codificada no se genera hasta que todas las tramas vocales del bloque de entrada hayan sido recogidas por el codificador. De este modo, hay un retardo de una trama antes de que pueda comenzar el procesamiento. Además, muchos codificadores también miran a la trama siguiente para mejorar la eficacia de compresión. La longitud de esta indagación se sabe que es igual al tiempo de indagación del codificador. El tiempo requerido para procesar una trama de entrada se supone que es el mismo que la longitud de trama, ya que el uso eficiente de los recursos de procesador se conseguirá cuando un par codificador/decodificador (o múltiples pares codificador/decodificador que actúan en paralelo sobre trenes de entrada múltiples) utiliza totalmente la potencia de procesamiento disponible (uniformemente distribuida en el dominio del tiempo). Si la red de salida es una red IP, el retardo adicional requerido para un ensamblado de paquetes IP y la presentación a la capa de enlace subyacente dependerá de la capa de enlace. Cuando la capa de enlace es una LAN (por ejemplo, Ethernet que será este caso), este tiempo adicional será normalmente bastante pequeño. Por tanto, el máximo retardo atribuible al procesamiento correspondiente al códec en los sistemas basados en IP es:

2 × tamaño de trama + indagación Cuando la capa de enlace es una capa con velocidad de temporización inferior (por ejemplo, conexión del módem) o una con alta carga de tráfico (por ejemplo, una LAN congestionada), el retardo adicional aumentará sustancialmente. A fin de sincronizar las tramas comprimidas al menos con la misma velocidad a la facilidad que se recogen las tramas vocales a la entrada del codificador, el retardo adicional no debe ser superior a un tamaño de trama. Por tanto, el máximo retardo atribuible al procesamiento correspondiente al códec en los sistemas basados en IP que funcionan en tiempo real es:

3 × tamaño de trama + indagación

A continuación se muestran los valores para estos parámetros en función del códec. Estos valores se han obtenido directamente de la recomendación G114 para latencia.


Tabla 10. Retardo códecs

El máximo retardo atribuible a los codecs a estudiar sería:

msmsLatenciaG 250.00125.0*2711 =+=

msmsLatenciaG 50102729 =++=

Estos valores se deben considerar como latencias fijas, independientes de la carga presente tanto en la CPU de los teléfonos/PCs, y de la carga de la red. Los valores de latencia variables deben ser estimados mediante pruebas, sin embargo, se puede garantizar la reducción considerable de esas latencias, siguiendo algunas recomendaciones en el diseño de la red, que permitan dar prioridad a paquetes de VoIP.

Para el desarrollo de este apartado, se ha hecho uso de un artículo publicado en la AHCEIT [29] donde se ha estudiado el comportamiento de los distintos codificadores de la voz utilizados actualmente en las Redes de Nueva Generación (NGN) para aplicaciones a tiempo real. A continuación se recogen los fragmentos de dicho artículo que se han usado para este desarrollo:

A medida que los algoritmos de compresión son más sofisticados las demoras introducidas en este proceso son mayores por lo que el tamaño de la carga útil que se transmite en el paquete (tramas de voz por paquetes) debe ser menor, para compensar la demora. Por tal motivo para un mismo retardo de paquetización la carga útil que se transmite para los distintos codificadores es diferente. En la tabla siguiente se muestran los atributos mas comúnmente utilizados en los codecs, además se relacionan con el MOS (Notas Medias de Opinión) que es la medida de la calidad subjetiva relativa al ser humano.


Codec Velocidad

(Kbps) Tamaño del

paquete (ms) Relación de compresión Carga Útil MOS

G711 64 20 2:1 160 4.1 G723 5.3 30 8:1 20 3.5 G723 6.3 30 7:1 24 3.9 G729 8 20 8:1 20 3.7

Tabla 11. Parámetros comúnmente configurados en los codecs

Análisis de los resultados: A continuación se muestran los resultados obtenidos para cada escenario (figuras 5, 6, 7, 8 y 9). Para analizar los resultados obtenidos se ha utilizado el programa MATLAB, al cual se han exportado los datos obtenidos en el proceso de simulación. Como se puede observar en la Figura 44 el tráfico de paquetes de voz mayor corresponde al codificador g.729 con VAD activado respecto a los demás codificadores, luego el codificador g.729 sin activación del supresor de silencio o VAD y a continuación el codificador g.723.1. Se puede concluir que el codificador g.729VAD es el que utiliza más eficientemente los recursos de la red al transmitir mayor cantidad de llamadas por la misma red, el empleo de VAD permite un gran ahorro de ancho de banda. El menos eficiente es el codificador g.711.

Figura 44. Evaluación del tráfico de voz enviado y recibido para los distintos códecs (pérdida de paquetes de 1% y demora de 100mseg)

En la

Figura 45 se reafirma lo observado en la gráfica anterior, el codificador g.711 es el que más carga a la red, ocupa mayor ancho de banda haciendo un empleo menos eficiente de los recursos de esta. A continuación le siguen el codificador g.729VAD, el codificador g.729 y por último el que menos carga a la red es el codificador g.723.1. Este mismo comportamiento se mantiene para el resto de las evaluaciones que se realizaron en los demás escenarios. Los codificadores g.729 y g.723.1 tienen


menos requerimientos de ancho de banda lo que posibilita de cara a la red establecer un mayor número de comunicaciones simultáneas.

Figura 45. Evaluación de la utilización de la red para los diferentes códecs (pérdida de paquetes 0.5% y demora 100mseg)

En la Figura 46 se obtiene la demora extremo e-e que admite cada codificador. Como se puede observar el codificador g.711 es el que mayor demora soporta e-e, siendo la demora total de alrededor de 120 mseg ya que por sus características propias el algoritmo de codificación introduce la mas baja demora que es de 0.125 mseg. El resto de los codificadores admiten demoras e-e muy inferiores, como se puede apreciar es de alrededor de 25 mseg cada uno de ellos. La razón es no sobrepasar los 150 mseg de demora, lo cual es establecido por la UIT-T en la recomendación G.114 que la demora e-e debe estar por debajo de este valor.

Figura 46. Evaluación de la demora e-e que admite cada códec

En la Figura 47 se representan los resultados obtenidos para la evaluación de la demora de paquetes e-e que admite el codificador g.711 para diferentes escenarios de pérdida de paquetes y demora fija de 100 mseg. Se observa


como a medida que las condiciones de la red son más desfavorables con el aumento de la pérdida de paquetes, el codificador g.711 admite menos tiempo en la demora de los paquetes de e-e, llegando admitir una demora de alrededor de 40 mseg cuando se registra una pérdida de paquetes de un 15%.

Figura 47. Evaluación de la demora e-e que admite el códec G711 En la Figura 48 se observa o se realiza la evaluación del comportamiento de los codificadores g.711 y g.729 para diferentes escenarios de red, se varía la pérdida de paquetes y la demora se mantiene fija a 100 mseg. El resultado obtenido demuestra que para una pérdida de paquetes de un 1% se afecta más la comunicación cuando se utiliza un codificador g.729 que cuando se utiliza el g.711, esta condición se mantiene alrededor de un 5% de pérdidas. A partir de este valor el comportamiento es diferente, se observa que el codificador g.729 es más robusto que el codificador g.711, a medida que aumenta la pérdida de paquetes, el mismo exhibe una afectación menor.

Figura 48. Comportamiento de los códecs (G711 y G729) para diferentes escenarios


Al aumentar el deterioro de la red se deben activar en los terminales los mecanismos que permitan contrarrestar las deficiencias en la red IP, es decir, se debe cambiar automáticamente por orden del elemento de control centralizado o Softswitch.

Este es el elemento de la red que debe centralizadamente, con la información enviada por los terminales, ordenar el cambio hacia un códec que permita mejores garantías a la QoS teniendo en cuenta la degradación de las condiciones o parámetros de la red. Como se planteó en la introducción, las pruebas de QoS son uno de los principales aspectos en las telecomunicaciones modernas, por lo que deben considerarse en las pruebas de aceptación. La QoS debe estar contemplada en la fase de aceptación del equipamiento antes de cursar tráfico real, de forma tal que de forma cuantificada queden relacionados el MOS, PESQ (Evaluación de la Calidad de la Voz Percibida) tipo de Codec y los parámetros de la red.

Los resultados obtenidos y en los que se fundamentará el razonamiento de esta elección se resumen a continuación:

� El codificador G711 es el que mayor demora extremo a extremo soporta, siendo la demora total alrededor de 120 ms ya que por sus características propias el algoritmo de codificación introduce la más baja demora que es de 0.125ms. El resto de los codificadores (entre ellos el G.729) admiten demoras muy inferiores y en torno a los 25 ms. La razón es no sobrepasar los 150 ms de demora máximos aceptables establecido por la ITU-T en la recomendación G114. A medida que las condiciones de la red son más desfavorables con el aumento de la pérdida de paquetes, el codificador G.711 admite menos tiempo extremo a extremo, llegando reducirse el valor anterior a 40ms cuando registra una pérdida de paquetes de paquetes de un 15%.

� En cuanto a la pérdida de paquetes, se obtiene que si se mantiene fija una demora de 100 ms y para varios escenarios se varía la pérdida de paquetes con ambos códecs, el resultado obtenido demuestra que para una pérdida de paquetes de un 1% se afecta más la comunicación cuando se utiliza un codificador G729 que cuando se usa G.711, esta condición se mantiene alrededor de un 5% de pérdidas. A partir de este valor el comportamiento es diferente, se observa que el codificador G729 es más robusto que el G711 a medida que aumenta la pérdida de paquetes el mismo exhibe una afectación menor.

El estudio de las latencias variables se considera innecesario puesto que se usan todas las técnicas disponibles para garantizar la calidad de servicio (QoS). Se dispone de varias colas hardware en cada puerto y priorización de tráfico (802.1p) que permiten reservar el ancho de banda garantizado. El tráfico no sensible al retardo se usa control de flujo (802.3x) para disminuir las pérdidas de paquetes en enlaces congestionados. En cuanto al ancho de banda y la limitación de las llamadas simultáneas, se dispone de elementos de conmutación Ethernet con puertos dedicados a 100Mb/s para usuarios y 1 Gb/s para enlaces entre conmutadores. Se toman estos valores en función de las características actuales de la red sobre la que se va a trabajar. Estos datos se han obtenido de la memoria definitiva del proyecto Persan ([27]). Con un sencillo cálculo se podría conocer el número aproximado de llamadas simultáneas que soportaría un puerto de conexión. Por ejemplo 100Mbps


permitirían una 62993.158

100 =Kbps

Mbps llamadas simultáneas bajo el códec G711

(consultar los datos de ancho de banda estudiados en el apartado anterior) suponiendo que suponiendo el uso del 100% del ancho de banda sólo para VoIP. Si se considera un 30% de los recursos para VoIP, se obtienen 189 llamadas simultáneas, con stream de voz sin compresión. El número de llamadas aumentaría usando un códec con compresión como el G729

siendo, 213093.46

100 =Kbps

Mbps llamadas o 639 si se dedica solo el 30% de los recursos.

Estas cifras, aunque calculadas a grandes rasgos y sin entrar en mucho detalle permiten hacerse una idea sobre los rangos de valores para cada uno de los códecs. Además de estos criterios para la comparación se deben tener en cuenta otros detalles que influyen directamente en la elección del códec.

1. El uso del códec G729 necesita licencia, con lo que el presupuesto del proyecto tendría un valor añadido.

2. Al utilizar g729 se tendrán ciertas limitaciones, ya que será necesario que todos los elementos (terminales, gateways, sistemas de buzón de voz, IVR etc…), lo soporten, de no ser así será necesario utilizar algún equipo (un gateway con DSP´s, por ejemplo) que realice transcoding, además hay que tener en cuenta que Asterisk está conectada con la red PSTN y sería necesario hacer transcodificación de códec para la salida a la red telefónica. Todo esto supone además de un retardo en la transmisión de los paquetes un gasto computacional para Asterisk puesto que consume gran cantidad de recursos. A continuación se muestra el tiempo de transcodificación obtenido directamente desde Asterisk mediante la opción:

CLI> show translations

Aparece una tabla con los "costos" en milisegundos de retraso en cada llamada al convertir 1 segundo información de un códec a otro.

Tabla 12.Translation Times between formats (in miliseconds) for one second of data

Conclusión

Una vez analizados todos los criterios comparativos se obtiene que los códecs que tienen mayor razón de codificación admiten mayor demora y son los que proporcionan mejor calidad de voz (en concreto G711)


Los codificadores presentan un comportamiento no lineal ante condiciones diferentes o variables de la red, diferentes tasas de pérdidas de paquetes y latencia. Según aumentan las pérdidas la calidad ofrecida por el códec G729 que inicialmente era peor que G711 se va acercando considerablemente, llegando a superarlo en calidad ante una tasa de pérdidas del 5%. Sin embargo, para una red como la que es motivo de estudio la tasa aceptable de pérdidas es menor por lo que el códec G711 sigue siendo más apropiado. Además de una mejor respuesta ante pérdidas, latencia y jitter por parte del códec G711, se toma en cuenta a la hora de seleccionarlo como códec de trabajo el hecho de que al estar conectada directamente la red VoIP con una red PSTN (a través de Asterisk) sería necesario hacer un cambio de códec a G729, lo que supondría un valor añadido a la latencia así como un costo económico asociado a la licencia del mismo. En cuanto al ancho de banda, que se presenta como la mayor desventaja del códec seleccionado, los cálculos aproximados de número de llamadas simultáneas que se podrían realizar en el caso de tener una conexión de 100Mbps, supera el número de llamadas simultáneas cursadas en la arquitectura motivo de estudio.

1.6. ESTÁNDARES PARA LA CODIFICACIÓN DE VIDEO

MPEG ( Moving Pictures Expert Group)

El MPEG, grupo de expertos en imágenes en movimiento, comenzó en 1988 como el grupo de trabajo 11, subcomité 29 del comité técnico consultivo número 1 de la Organización Internacional de Estandarización y de la Organización Electrónica Internacional (ISO/IEC JTC1). Su propósito fue definir los estándares para la compresión digital de señales de audio y vídeo. Tomo como base su estándar de la UIT para vídeo conferencia y vídeo telefonía, y el estándar del grupo de expertos en fotografía JPEG (Joint Photografies Expert Group), que había sido desarrollado para la compresión de imágenes fijas, como la fotografía electrónica. La tarea básica de MPEG fue tomar las señales de audio y vídeo y convertirlas en paquetes de información digital, de forma que pudieran ser transportadas en redes de comunicaciones con mayor eficiencia, anulando toda información que sea redundante, con lo cual se reduce considerablemente el ancho de banda desde que se genera hasta que se visualiza en el receptor, manteniendo la calidad de la imagen. MPEG comprime las señales de audio y vídeo, desechando gran parte de la información redundante, consumiendo menos ancho de banda y manteniendo la calidad de transmisión desde la generación de la señal hasta la descodificación y presentación de la misma.

La codificación MPEG determina una estructura de información de vídeo digital, audio y datos asociados.

MPEG ha normalizado los siguientes formatos de compresión y normas auxiliares:

� MPEG-1: estándar inicial de compresión de audio y vídeo. Usado después como la norma para CD de vídeo, incluye el popular formato de compresión de audio Capa 3 (MP3).

� MPEG-2: normas para audio y vídeo para difusión de calidad de televisión. Utilizado para servicios de TV por satélite como DirecTV (Cadena


estadounidense de televisión vía satélite de difusión directa), señales de televisión digital por cable y (con ligeras modificaciones) para los discos de vídeo DVD.

� MPEG-3: diseñado originalmente para HDTV (Televisión de Alta Definición), pero abandonado posteriormente en favor de MPEG-2.

� MPEG-4: expande MPEG-1 para soportar "objetos" audio/vídeo, contenido 3D, codificación de baja velocidad binaria y soporte para gestión de derechos digitales (protección de copyright) actualmente se emplea como códec HDTV en detrimento de MPEG-2.

� MPEG-7: sistema formal para la descripción de contenido multimedia � MPEG-21: MPEG describe esta Norma futura como un "marco multimedia".

El MPEG utiliza códecs (codificadores-decodificadores) de compresión con bajas pérdidas de sonido usando códecs de transformación. En los códecs de transformación con bajas pérdidas, las muestras tomadas de imagen y sonido son troceadas en pequeños fragmentos y solamente las diferencias con estas imágenes reconstruidas y algún extra necesario para llevar a cabo la predicción es almacenado. Es necesario hacer hincapié en el hecho de que las distintas versiones de MPEG son la versión anterior ampliada, es decir reúne las características de su predecesor y las amplía. En la especificación MPEG-1 y MPEG-2 existen tres partes diferenciadas, llamadas, Sistema, Video y Audio. La parte de video define la sintaxis y la semántica del flujo de bits de la señal de video comprimida. La parte de audio opera igual, mientras que la parte Sistema se dirige al problema de la multiplexación de audio y video en un único flujo de datos con toda la información necesaria de sincronismo, sin desbordar los buffers del decodificador.

MPEG-1.

El primer estándar público del comité MPEG fue el MPEG-1, ISO/IEC 11172, cuya primera parte fue publicada en 1993. La compresión de vídeo MPEG-1 está basada en la misma técnica que se usó para JPEG. Además incluye técnicas para la codificación eficiente de una secuencia de vídeo.

Figura 49.Una secuencia de vídeo JPEG de tres imágenes

Considere la secuencia de vídeo mostrada en la Figura 49. La imagen de la izquierda es la primera imagen en la secuencia seguida por la imagen del medio y después la imagen de la derecha. Cuando se muestra, la secuencia de vídeo muestra a un hombre caminando de derecha a izquierda con un árbol que permanece estático. En MPEG video sólo las partes de la secuencia de vídeo se incluye junto con la información de las partes que ofrecen movimiento. La secuencia de vídeo de Figura 49 aparecerá entonces como se muestra en Figura 50. Sin embargo esto es sólo


real durante la transmisión de la secuencia de vídeo para limitar el consumo de ancho de banda. Cuando se visualice aparecerá nuevamente como la secuencia de vídeo original.

Figura 50.Una secuencia de vídeo MPEG de tres imágenes. MPEG-1 está centrado en streams de bits de aproximadamente 1,5 Mbps y originalmente para el almacenamiento de vídeo digital en CD’s. El foco está en el ratio de compresión más que en la calidad de las imágenes. Puede ser considerado como la calidad tradicional del VCR (Video Cassette Recorder) pero en formato digital.

MPEG-2

El proyecto MPEG-2 se centró en la ampliación de la técnica de compresión MPEG-1 para cubrir imágenes más grandes y mayor calidad con un menor ratio de compresión y por consiguiente mayor uso de ancho de banda. MPEG-2, ISO/IEC 13818, también ofrece técnicas más avanzadas para mejorar la calidad del vídeo con el mismo ratio de bits. El inconveniente es la necesidad de un equipamiento más complejo. En cualquier caso estas características no suelen adaptarse a su uso en aplicaciones de vigilancia en tiempo real. A nivel anecdótico, las películas en DVD están comprimidas utilizando las técnicas MPEG-2

MPEG-4

También la tercera generación de MPEG está basada en la misma técnica. Una vez más, el nuevo proyecto se enfocó en los usos de nuevas aplicaciones. Las características nuevas más importantes de MPEG-4, ISO/IEC 14496, relacionadas con la compresión de vídeo son el soporte de aplicaciones con menor consumo de ancho de banda, por ejemplo: unidades móviles, y, por otro lado, para aplicaciones con una calidad extremadamente alta y sin casi limitación de ancho de banda. La realización de películas de estudio es sólo un ejemplo. La mayoría de las diferencias entre MPEG-2 y MPEG-4 son características no relacionadas con codificación de vídeo y por tanto no relacionadas con las aplicaciones de vigilancia.

Comparación MPEG

Todos los estándares MPEG ofrecen compatibilidad hacia atrás. Esto significa que una secuencia de vídeo MPEG-1 también puede ser “empaquetada” como vídeo


MPEG-2 o MPEG-4. Del mismo modo, MPEG-2 puede ser “empaquetada” como una secuencia de vídeo MPEG-4. La diferencia entre un vídeo MPEG-4 real y una secuencia MPEG-1 “empaquetada” como MPEG-4 es que los estándares más antiguos no hacen uso de las mejoras y nuevas características de los más actuales. Dado que tanto MPEG-2 como MPEG-4 cubren una amplia variedad de tamaños de imágenes, ratios de imágenes y uso de ancho de banda, el MPEG-2 introdujo un concepto denominado Profile@Level. Fue creado para hacer posible las capacidades de comunicación entre aplicaciones. Por ejemplo, el profile Studio de MPEG-4 no se adapta a un PDA y viceversa. La comparación de los MPEGs aparece en la tabla siguiente, contiene el MPEG-1 con su limitación más utilizada (Constrained Paramenters Bitstream, CPB), MPEG-2 con su Main Profile at Main Level (MP@ML), y MPEG-4 con Main Profile at Level 3.

MPEG 1 2 3 Máx. ratio de bits

(Mbps) 1.86 15 15 Ancho de imagen

(píxeles) 352 720 720 Alto de imagen (píxeles) 288 576 576 Ratio de imágenes (fps) 30 30 30

Tabla 13. Comparación de MPEGs

En resumen, MPEG-1 puede ser más efectivo que MJPEG, sin embargo por un precio ligeramente superior, MPEG-2 proporciona algunas ventajas y mayor calidad de imagen, comprimiendo el ratio de imágenes y la resolución, aunque tiene un mayor consumo de ancho de banda y es una técnica mucho más compleja. MPEG-4 está desarrollado para ofrecer una técnica de compresión para aplicaciones que necesitan menor calidad de imagen y ancho de banda. También permite compresión de vídeo similar a MPEG-1 y MPEG-2, mayor calidad de imagen con un mayor consumo de ancho de banda.

1.7. ESTÁNDARES DE VIDEO VceG (h.26X) En videoconferencia los algoritmos de compresión de vídeo son similares a los utilizados en MPEG, es decir se aprovecha la redundancia espacial y temporal de la información. Para simplificar el proceso de compresión y descompresión y reducir la latencia en algunos casos (H.261) no se utilizan fotogramas B, únicamente I y P. Dado que la movilidad de la imagen se espera que sea menor que en MPEG los vectores de movimiento que se permiten son más reducidos, lo cual permite obtener más calidad para un mismo ancho de banda, o bien ocupar un menor ancho de banda para una misma calidad. Se realiza submuestreo 4:2:0 para reducir la información de crominancia. Los estándares existentes (fijados por la ITU-T) son el H.261 y el H.263. El H.261 es más antiguo y menos eficiente. El H.263 fue estandarizado en 1997 y es más eficiente a costa de emplear algoritmos más complejos y es por tanto más intensivo en el uso de CPU. Muchos sistemas de videoconferencia actuales utilizan el H.261 con un códec software, mientras que el soporte de H.263 es bastante más limitado y en muchos casos no es viable si el equipo no incluye un códec por hardware. Productos como el Netmeeting de Microsoft utilizan el H.261. Otros sistemas más


avanzados (como los denominados equipos de videoconferencia de sala) incluyen tanto el H.261 como el H.263. A continuación se profundizará un poco más en ellos.

1.7.1. H.261. H.261 fue el primer estándar de codificación de vídeo, originalmente diseñado para la transmisión sobre líneas RDSI en las cuales los bitrates (ratio de bits) son múltiplos de 64 Kbits/s. Se pueden usar entre 1 y 30 canales ISDN (64 Kbit/s a 1920 Kbit/s). Aplicaciones que motivaron el diseño de este tipo de estándar son: videoconferencia, vigilancia y monitoreo, telemedicina, y otros servicios audiovisuales. Es parte del grupo de estándares H.320 para comunicaciones audiovisuales. El diseño de H.261 fue un esfuerzo pionero, y todos los subsiguientes estándares de codificación de vídeo internacionales (MPEG-1, MPEG-2/H.262, H.263, e incluso H.264 están basados en su diseño). El algoritmo de codificación utiliza un híbrido de predicción inter-imagen compensada por el movimiento y codificación de transformaciones espaciales con cuantización escalar, escaneado en zig-zag16 y codificación entrópica17 La unidad de procesamiento básica del diseño se llama macrobloque, y H.261 fue el primer estándar donde apareció el concepto de macrobloque. Cada macrobloque consiste en un array de 16x16 con samples luma y dos arrays correspondientes de 8x8 con samples chroma, utilizando un sampleado 4:1:1 con un espacio de color YCbCr.

1.7.2. H.263: H.263 es un códec de vídeo diseñado por la ITU-T como solución de codificación de bajo bitrate para videoconferencia. Se diseñó primero para ser utilizado en sistemas basados en H.324 (RTC y otras redes conmutadas de videoconferencia y videotelefonía) pero desde entonces se encontraron también usos en soluciones H.323 (videoconferencia basada en IP/RTP), H.320 (videoconferencia basada en RDSI), RTSP (streaming de medios) y SIP (conferencia en Internet). H.263 fue desarrollado como una revolucionaria mejora basada en la experiencia de H.261, el estándar ITU-T previo para compresión de vídeo, y los estándares MPEG-1 y MPEG-2. La primera versión se completó en 1995 y proporcionó un conveniente reemplazo para H.261 en todos sus bitrates. El H.263 original especificaba los siguientes anexos:

� Anexo A - Especificación de precisión de transformación inversa � Anexo B - Decodificador de referencias hipotéticas � Anexo C - Consideraciones para multipunto � Anexo D - Modo vector de movimiento sin restricciones � Anexo E - Modo de codificación aritmética basado en sintaxis

16 (Huffman) Este proceso se realiza de tal forma que las combinaciones con una alta probabilidad consiguen un código con pocos bits, mientras que los poco habituales obtienen un código mayor. Adoptando esta codificación sin pérdidas, el número total de bits disminuye. Sin embargo, ya que la redundancia espacial es limitada, las imágenes I sólo proporcionan una compresión moderada. Estas imágenes son muy importantes para acceso aleatorio utilizado para fines de edición. La frecuencia de imágenes I es normalmente de una cada 12 o 15 cuadros o frames. Un GOP está delimitado por dos cuadros I. Va leyendo en diagonal en lugar de por filas o columnas como sería habitual. 17 Codificación entrópica es un método de codificación sin pérdidas. Este método de codificación se basa en un conocimiento previo sobre los símbolos que surgirán en una trama binaria. La entropía es un factor para evaluar los codificadores. Se calcula con el número de bits por símbolo usados.


� Anexo F - Modo de predicción avanzado � Anexo G - Modo PB-frames � Anexo H - Correción del "Forward Error" para la señal de vídeo codificada

1.7.3. H.263p: También conocido como H.263+/h263p o H.263v2 es básicamente una mejora de H.263 soportada por el Eyebeam de Xten proporcionando una mejora de la calidad de vídeo. Fue diseñado reteniendo completamente el contenido técnico de la primera versión (H.263) del estándar, pero mejorando las capacidades de H.263 añadiendo varios anexos que pueden mejorar substancialmente la eficiencia de la codificación y proporcionar otras capacidades (tales como una robustez mejorada frente la pérdida de datos en el canal de transmisión). El proyecto H.263+ fue ratificado por la ITU en Febrero de 1998. Añadió los siguientes anexos:

� Anexo I - Modo de codificación avanzado INTRA � Anexo J - Modo filtro desbloqueante � Anexo K - Modo estructurado en partes � Anexo L - Especificación de información de mejoras suplementarias � Anexo M - Modo PB-frames mejorado � Anexo N - Modo selección de imagen de referencia � Anexo O - Modo de escalabilidad temporal, SNR, y espacial � Anexo P - Resampling de imagen de referencia � Anexo Q - Modo actualización de resolución reducida � Anexo R - Modo de decodificación de segmentos independiente � Anexo S - Modo alternativo INTER VLC � Anexo T - Modo de cuantización modificada � Anexo X - Definición de perfiles y niveles.

H.263v2 también añadió soporte para formatos flexibles de imágenes personalizadas y con frecuencias de reloj de imagen personalizadas. Previamente los únicos formatos de imagen soportados en H.263 habían sido Sub-QCIF, QCIF, CIF, 4CIF, y 16CIF, y la única frecuencia de reloj de imagen había sido 30000/1001 (aproximadamente 29.97) tics de reloj por segundo.

1.7.4. H.264: H.264 es un estándar para compresión de vídeo también conocido como MPEG-4 Part 10, o MPEG-4 AVC (para Advanced Video Coding). La finalidad del proyecto H.264/AVC era crear un estándar capaz de proporcionar buena calidad de vídeo a bitrates sustancialmente inferiores que los estándares previos (por ejemplo menos de la mitad del bitrate de MPEG-2, H.263, o MPEG-4 Part 2), sin incrementar demasiado la complejidad del diseño para que no fuera impracticable o excesivamente caro de implementar. Un objetivo adicional era proporcionar suficiente flexibilidad para permitir aplicar el estándar en una amplia variedad de aplicaciones y una amplia variedad de redes y sistemas, incluyendo bajos y altos bitrates, vídeo de alta y baja resolución, multidifusión, almacenamiento en DVD, redes de paquetes RTP/IP y sistemas de telefonía multimedia ITU-T.

Documents

Anexo I. VoIPbibing.us.es/proyectos/abreproy/11969/fichero/Memoria... · que no se permita la transmisión de datos si no pueden ser gestionados por el receptor. H.323 es un estándar