PRÁCTICA DE LABORATORIO VOZ SOBRE IP (VoIP) 1. Objetivo
El objetivo de esta práctica es observar y verificar los procedimientos en el establecimiento de una llamada en los protocolos H.323 y SIP.
2. Voz sobre IP (VoIP)
Voz sobre IP (VoIP) es la tecnología que permite la transmisión de fragmentos auditivos a través de redes basadas en el Protocolo de Internet (IP).
Su funcionamiento consiste en convertir la señal voz en una señal digital. Luego esta señal digital es colocada dentro de paquetes IP para ser transmitido en la red hacia el destino. De forma inversa, cuando estos paquetes llegan al destino, se les extrae esta señal digital y se convierte en una señal analógica. Sin embargo, más allá de transmitir la voz, es necesario el intercambio de una serie de mensajes de señalización para establecer, controlar y finalizar la llamada. Actualmente existen varios estándares que describen estos mensajes y procedimientos de señalización.
El crecimiento y la fuerte implantación de las redes IP unido con el desarrollo de técnicas avanzadas de digitalización de voz, mecanismos de control, mecanismos asignación de prioridad al tráfico y protocolos de transmisión en tiempo real han creado un entorno donde es posible transmitir telefonía sobre IP. En sólo unos pocos años VoIP pasó a ser la principal alternativa al servicio de telefonía convencional. En tal sentido, tanto la ITU (Unión Internacional de Telecomunicaciones) como el IETF (Grupo de Trabajo en Ingeniería de Internet) han estado desarrollando arquitecturas y protocolos para sistemas multimedia sobre IP. Dentro de estos se encuentran la recomendación H.323 desarrollado por la ITU y el estándar SIP (RFC 3261) creado por al IETF, los cuales son los más usados hoy en día en VoIP.
3. Recomendación UIT-T H.323
La recomendación H.323 es una recomendación del UIT-T (Sector de Normalización de las Telecomunicaciones de la UIT) que tiene como título “Sistemas de comunicaciones multimedia basados en paquetes”. H.323 expone los requisitos técnicos de los sistemas de comunicaciones multimedios en aquellas situaciones en las que la red de transporte subyacente es una red por paquetes que puede no garantizar la calidad de servicio. Esta Recomendación describe los componentes de un sistema H.323, lo que incluye terminales, pasarelas, controladores de acceso, controladores multipunto, procesadores multipunto y unidades de control multipunto. También describe los mensajes y procedimientos de control para comunicar estos componentes. H.323 no puede considerarse como un protocolo completo en sí mismo, sino más bien se trata de una especificación que define el modo de interactuar de varios protocolos entre sí.
3.1 Componentes
Dentro de los componentes que se definen en H.323 se encuentran:
• Terminal: Es un punto extremo de la red que facilita las comunicaciones en tiempo real y en los dos sentidos con otro terminal, pasarela o unidad de control multipunto H.323. Esta comunicación consta de control, indicaciones, audio, imágenes de vídeo en color y en movimiento y/o datos entre los dos terminales.
• Guardián de puerta (Gatekeeper): Es una entidad H.323 de la red que facilita la traducción de direcciones y controla el acceso a la red para terminales, pasarelas y MCU H.323. El guardián de puerta puede prestar también otros servicios a los terminales, las pasarelas y las MCU, tales como la gestión de anchura de banda y la localización de pasarelas. Es opcional en un sistema H.323.
3.2 Protocolos
H.323 no puede considerarse como un protocolo completo en sí mismo, sino más bien se trata de una especificación que define el modo de interactuar de varios protocolos entre sí. En la siguiente figura se muestra la pila de los protocolos más relevantes en H.323.
Figura 1. Pila de protocolos de H.323.
• H.225: Es un protocolo de señalización de llamada y empaquetamiento de trenes de medios para sistemas de comunicación multimedios por paquetes. Sus funciones pueden dividirse en tres partes:
o Registro, admisiones y situación (RAS): Utiliza mensajes H.225.0 para llevar a cabo los procedimientos de registro, admisiones, cambios de anchura de banda, situación y desligamiento entre puntos extremos y controladores de acceso. La recomendación H.225 define una sintaxis de
mensajes a través de un árbol ASN.1. Estos mensajes son codificados según la regla PER de ASN.1.
o Señalización de la llamada: La función de señalización de llamada consiste en los mensajes y procedimientos utilizados para establecer una llamada, pedir cambios de anchura de banda de la llamada, obtener el estado de los puntos extremos de la llamada y desconectar la llamada. Para ello se utilizan mensajes codificados según la recomendación Q.931 y bajo las restricciones y modificaciones establecidas por la recomendación H.225. La recomendación H.225 indica cuales de los tipos de mensajes y elementos de información definidos en Q.931 serán usados en H.323, además de imponer algunas modificaciones en la estructura de ciertos elementos de información. o Empaquetamiento: Esta función de H.225 formatea los trenes de vídeo,
audio, datos y control transmitidos en mensajes de salida hacia la interfaz de la red y recupera los trenes de vídeo, audio, datos y control recibidos de los mensajes que han sido introducidos desde la interfaz de la red. Además, lleva a cabo la alineación de trama lógica, la numeración secuencial, la detección de errores y la corrección de los mismos según conviene a cada tipo de medio. H.225 hace uso del protocolo en tiempo real/protocolo de control en tiempo real (RTP/RTCP, real-time transport protocol/real-time transport control protocol) para la empaquetamiento y sincronización de medios.
• H.245: Esta recomendación es un protocolo de control para comunicaciones multimedios. Se definen procedimientos para llevar los mensajes de control de extremo a extremo que rigen el funcionamiento de la entidad H.323, incluyendo el intercambio de capacidades, apertura y cierre de canales lógicos, peticiones de modo preferido, mensajes de control de flujo e instrucciones e indicaciones generales. Esta recomendación define una sintaxis de mensajes a través de un árbol ASN.1. Estos mensajes son codificados según la regla PER de ASN.1.
3.3 Procedimientos para establecer y finalizar una llamada
A continuación se describen los procedimientos para establecer una llamada H.323 en un caso típico. Este caso el terminal A desea llamar al terminal B, y estos dos terminales están dentro del entorno de un guardián de puerta (gatekeeper) quien decide encaminar la señalización de la llamada.
En el establecimiento de una llamada H.323 están involucrados tres canales: RAS, señalización y control (figura 2).
Guardiá de Puerta T erminal B T erminal A
Establecimient o (3)
Aviso (8)
ARQ (6)
Cierre de canal de control (16)
Cierre de canal de cont rol (15) Llamada en curso (5)
Conexión (9) Aviso (8) Llamada en curso (5)
Conexión (10)
Cierre de canales de vídeo, datos o audio (14)
Establecimient o (4)
ACF (7) ARQ (1)
ACF (2)
RAS H.225 (Canal no fiable)
Control H.245 (Canal fiable) Señalización H.225 (Canal fiable)
Canales de audio, vídeo o dat os (13) Canal de control (12) Canal de control (11) Liberación completa (17) Liberación completa (17) XXXXXXXXX XXXXXXXXX XXXXX XXXXX XXXXX XXXXX DRQ (18) DCF (19) DRQ (18) DCF (19)
El canal de señalización RAS se abre antes de que se establezca cualquier otro canal. A través de este canal, el terminal A debe solicitar acceso a la red de paquetes por el guardián de puerta. Esto se hace por medio de un mensaje de petición de admisión (ARQ, Admision Request) (1). El guardián de puerta concede la petición con un mensaje de confirmación de admisión (ACF, Admision Confirm) (2). Estos mensajes son definidos en la sintaxis ASN.1 de H.225 y codificados en PER (Packed Encoding Rules). El guardián de puerta indica en el mensaje ACF (2) si la señalización de llamada se envía directamente al otro punto extremo o si se encamina a través del guardián de puerta. En este caso, la señalización se encaminará a través del guardián de puerta. En el mensaje ACF el guardián de puerta también indica una dirección de transporte para la señalización de la llamada.
El terminal A comienza el envío de mensajes de señalización utilizando la dirección de transporte indicada por el mensaje ACF. El terminal A envía un mensaje “Establecimiento” (3) para indicar su deseo de establecer una conexión hacia el terminal B. Luego el guardián de puerta reenvía este mensaje hacia el terminal B (4), el cual responde con un mensaje “Llamada en curso” (5) para indicar al guardián de puerta que se ha iniciado el establecimiento de la llamada solicitado y que no se aceptará más ninguna información de establecimiento de llamada. De la misma forma, el guardián de puerta envía un mensaje “Llamada en curso” (5) al terminal A. El terminal B debe responder a este mensaje al terminal A y por consiguiente, solicita el acceso al guardián de puerta por medio de un mensaje ARQ (6). Esta solicitud es confirmada con un mensaje ACF (7). A partir de este momento el terminal B puede enviar mensajes de señalización hacia el terminal A a través del guardián de puerta. Seguidamente, el mensaje “Aviso” (8) es enviado por el terminal B y encaminado por el guardián de puerta hacia el terminal A, para indicar que se ha iniciado el aviso al usuario B, en términos de hoy día, "el teléfono está sonando". Finalmente, una vez que el usuario B responde la llamada, el terminal B envía al guardián de puerta el mensaje “Conexión” (9) para indicar aceptación de la llamada. Este mensaje contiene una dirección de transporte del terminal B para su utilización en el canal de control H.245 entre el guardián de puerta y el terminal B. El guardián de puerta reenvía al terminal A el mensaje “Conexión” (10), pero con una dirección de transporte de él para su utilización en el canal de control H.245 entre el terminal A y el guardián de puerta.
Una vez que ambos lados han intercambiado los mensajes de establecimiento de llamada de la fase A, los puntos extremos, si proyectan emplear H.245, establecerán el canal de control H.245 (11 y 12). Se utilizan los procedimientos de la Rec. UIT-T H.245 en el canal de control H.245 para el intercambio de capacidad y la apertura de canales de medios. En este canal se intercambian mensajes de la sintaxis ASN.1 definida en H.245 y codificados en PER (Packed Encoding Rules). Después del intercambio de capacidades y la determinación de principal-subordinado, se utilizarán los procedimientos de la recomendación H.245 para abrir canales lógicos para los diversos trenes de información (13). Los trenes de audio y vídeo, que se transmiten por los canales lógicos establecidos en H.245, utilizarán un protocolo no fiable. Las comunicaciones de datos, que se transmiten por los canales lógicos establecidos en H.245, se transportan utilizando un protocolo fiable.
Al finalizar la llamada, lo primero que se debe hacer es interrumpir las transmisiones de vídeo, datos y audio (14). Luego se deben cerrar los canales de control H.245 (15 y 16). En la figura 2 se supone que el terminal B es quien finaliza la llamada y
por consiguiente, es quien cierra primero el canal de control. Después se enviarán mensajes “Liberación completa” (17) y se cerrarán los canales de señalización. Finalmente, cada punto extremo transmitirá en el canal RAS un mensaje de petición de desligamiento (DRQ, Disengage Request) al guardián de puerta (18). El guardián de puerta responderá con un mensaje de confirmación de desligamiento (DCF, Disengage Confirm) (19).
3.4 Estructura de los mensajes de señalización
Los mensajes Q.931 son utilizados en la señalización de una llamada H.323. El protocolo Q.931 describe el formato general de estos mensajes y la codificación de los elementos de información que están contenidos dentro de estos mensajes. El protocolo Q.931 fue creado para redes ISDN y su título es “Especificación de la capa 3 de la interfaz usuario-red de la red digital de servicios integrados para el control de la llamada básica”. Por lo tanto, el protocolo H.225 impone restricciones a estos mensajes y a los elementos de información para ser usados en H.323. En la siguiente tabla se muestra el formato de un mensaje Q.931.
8 7 6 5 4 3 2 1 Bit/Octeto
Discriminador de protocolo 1
0 0 0 0 Longitud del valor de la referencia de
llamada (en octetos) 2 Valor de la referencia de llamada 3
0 Tipo de mensaje 4
Otros elementos de información, según se requieran etc.
Tabla 1. Formato de un mensaje Q.931.
Los elementos de información discriminador de protocolo, longitud del valor de la referencia de llamada, valor de la referencia de llamada y tipo de mensaje son comunes a todos los mensajes y están siempre presentes, mientras que los otros elementos de información son específicos de cada mensaje.
3.4.1 Discriminador de protocolo
El discriminador de protocolo es la primera parte de cada mensaje. La finalidad del discriminador de protocolo es distinguir mensajes para el control de la llamada usuario-red de otros mensajes. En mensajes Q.931 debe contener la secuencia de bits “00001000” (8 en base 10).
3.4.2 Valor de la referencia de llamada
La finalidad de la referencia de llamada es identificar a qué llamada se aplica un mensaje particular. Se codifica como muestra la tabla 2. La longitud del valor de la referencia de llamada se indica en el octeto 1, bits 1 a 4.
8 7 6 5 4 3 2 1 Bit/Octeto 0 0 0 0 Longitud del valor de la referencia
de llamada (en octetos) 1
Bandera 2
Valor de la referencia de llamada etc.
Tabla 2. Elemento de información Referencia de Llamada [10].
El elemento de información referencia de llamada incluye el valor y la bandera de la referencia de llamada. Los valores de la referencia de llamada se asignan, para una llamada, en el punto extremo que origina la llamada. Estos valores son únicos solamente para el lado origen en una llamada determinada. El valor de la referencia de llamada se asigna al comienzo de una llamada y permanece fijo mientras dura la llamada. Cuando termina una llamada, el valor de la referencia de llamada asociado puede reasignarse a otra llamada. La bandera de la referencia de llamada se utiliza para identificar el extremo del enlace lógico que ha originado la llamada. El lado de origen pone siempre la bandera de la referencia de llamada a “0”. El lado de destino pone siempre la bandera de la referencia de llamada a “1”. Por consiguiente, la bandera de la referencia de llamada identifica quien asignó el valor de la referencia de llamada para esta llamada, y su única finalidad es resolver las tentativas simultáneas de asignar un mismo valor de referencia de llamada.
3.4.3 Tipo de mensaje
La finalidad del tipo de mensaje es identificar la función del mensaje que se envía. Es la tercera parte de cada mensaje y se codifica como se muestra en la tabla 3. El bit 8 se reserva para un posible uso futuro como bit de ampliación.
8 7 6 5 4 3 2 1 Bit/Octeto
0 Tipo de mensaje 1
Tabla 3. Elemento de información Tipo de mensaje. [10]
No todos los tipos de mensajes definidos en Q.931 son usados en H.323. El protocolo H.225 indica cuales tipos de mensajes se usan en H.323. Algunos de estos tipos de mensaje se muestran en la siguiente tabla.
Bits Tipo de mensaje
8 7 6 5 4 3 2 1
0 0 0 - - - Mensaje de establecimiento de la llamada: 0 0 0 0 1 – AVISO
0 0 0 1 0 – LLAMADA EN CURSO 0 0 1 1 1 – CONEXIÓN
0 0 1 0 1 – ESTABLECIMIENTO
0 1 1 0 1 – ACUSE DE ESTABLECIMIENTO 0 1 0 - - - Mensajes de liberación de llamada:
1 1 0 1 0 – LIBERACIÓN COMPLETA
3.4.4 Otros elementos de información
A parte de los elementos de información comunes, Q.931 define otros que, dependiendo del tipo de mensaje, pueden aparecer o no. Los elementos de información se clasifican de la siguiente forma:
• Elementos de información de un solo octeto: Son elementos de información con una longitud de un Octeto (tablas 5). El bit más significativo es igual a 1.
• Elementos de información de longitud variable: Son elementos de información cuyo contenido puede contener más de un octeto. Por lo general su estructura es igual a la que se muestra en la tabla 6. El bit más significativo del primer octeto es igual a 0.
8 7 6 5 4 3 2 1 Bit/Octeto
1 Identificador del elemento de información 1
Tabla 5. Elemento de información de un solo octeto.
8 7 6 5 4 3 2 1 Bit/Octeto 0 Identificador del elemento de información 1
Longitud del contenido del elemento de información (octetos) 2 Contenido del elemento de información 3 etc.
Tabla 6. Elemento de información de longitud variable [10]
.
No todos los elementos de información definidos en el protocolo Q.931 son usados en H.323. El protocolo H.225 enumera cuales elementos de información deben ser usados en H.323. En la tabla 7 se muestran algunos de ellos con sus respectivos identificadores. Los elementos de información de un solo octeto pueden aparecer en cualquier posición del mensaje. Sin embargo, existe un orden particular de aparición de cada elemento de información de longitud variable. Los valores de código del identificador de elemento de información para los formatos de longitud variable se asignan en orden numérico ascendente, de acuerdo con el orden real de aparición de cada elemento de información en un mensaje. Por ejemplo, un elemento de información visualización siempre debe aparecer después del elemento de información capacidad de portador. Esto permite al equipo receptor detectar la presencia o ausencia de un elemento de información particular sin explorar todo el mensaje.
Identificador Elemento de Información
Bits
8 7 6 5 4 3 2 1
1 : : : - - - - Elementos de información de un solo octeto: 0 1 0 0 0 0 1 Envío completo
0 : : : : : : : Elementos de información de longitud variable: 0 0 0 0 1 0 0 Capacidad portadora
0 0 0 1 0 0 0 Causa 0 1 0 1 0 0 0 Visualización 1 1 1 1 1 1 0 Usuario a usuario
Tabla 7. Elementos de información.
El segundo octeto de un elemento de información de longitud variable indica la longitud total del contenido de ese elemento de información empezando en el octeto 3, es
decir, no toma en cuenta el identificador ni el propio octeto longitud. En el elemento de información usuario a usuario, el protocolo H.225 impone la restricción de utilizar dos octetos para la longitud en vez de uno. La estructura del contenido depende del propio elemento de información.
En algunos casos se aplica un mecanismo de agrupación y ampliación en el contenido de los elementos de información de longitud variable. En este mecanismo la primera cifra del número de octeto identifica a un octeto o a un grupo de octetos (ver tabla 8). Cada grupo de octetos es una entidad autocontenida. Un grupo de octetos se forma utilizando un mecanismo de ampliación. El mecanismo de ampliación consiste en ampliar un octeto (N) en el octeto o los octetos siguientes (Na, Nb, etc.) utilizando el bit 8 de cada octeto como bit de ampliación. El valor "0" de este bit indica que el grupo continúa en el octeto siguiente. El valor "1" de este bit indica que ese octeto es el último del grupo.
8 7 6 5 4 3 2 1 Bit/Octeto ext. 0 N ext. 0 Na ext. 0 Nb ext. 0 Nc ext. 1 Nd ext. 1 N+1 ext. 1 N+2
Tabla 8. Mecanismo de agrupación y ampliación.
3.4.5 Mensajes Establecimiento, Llamada en curso, Aviso, Conexión y Liberación completa
Los siguientes cuadro indican los elementos de información que pueden o deben estar presentes en los mensajes Establecimiento, Llamada en curso, Aviso, Conexión y Liberación completa. La letra M significa obligatorio (mandatory), O opcional, CM condicionalmente obligatorio (conditionally mandatory).
Elemento de información Situación H.225.0
Discriminador de protocolo M Referencia de llamada M Tipo de mensaje M Envío completo O Capacidad portadora M Facilidad ampliada O Facilidad O Indicador de notificación O Visualización O Facilidad de teclado O Señal O
Número de la parte llamante O
Subdirección de la parte llamante CM (llamadas con una red de conmutación de circuitos)
Número de la parte llamada O
Subdirección de la parte llamada CM (llamadas con una red de conmutación de circuitos)
Usuario a usuario M
Elemento de información Situación H.225.0 Discriminador de protocolo M Referencia de llamada M Tipo de mensaje M Capacidad portadora O Facilidad ampliada O Facilidad O Indicador de progresión O Indicador de notificación O Visualización O Usuario a usuario M
Tabla 10. Mensaje llamada en curso.
Elemento de información Situación H.225.0
Discriminador de protocolo M Referencia de llamada M Tipo de mensaje M Capacidad portadora O Facilidad ampliada O Facilidad O Indicador de progresión O Indicador de notificación O Visualización O Señal O Usuario a usuario M
Tabla 11. Mensaje Aviso.
Elemento de información Situación H.225.0
Discriminador de protocolo M Referencia de llamada M Tipo de mensaje M Capacidad portadora O Facilidad ampliada O Facilidad O Indicador de progresión O Indicador de notificación O Visualización O Fecha/hora O Usuario a usuario M
Tabla 12. Mensaje Conexión.
Elemento de información Situación H.225.0
Discriminador de protocolo M
Referencia de llamada M
Tipo de mensaje M
Causa CM (si no se envía el elemento
ReleaseCompleteReason dentro del elemento de información usuario a
usuario Facilidad O Indicador de notificación O Visualización O Señal O Usuario a usuario M
3.4.6 Elemento de información capacidad portadora
El elemento de información capacidad portadora tiene por objeto especificar el servicio solicitado. Se codifica como muestra la siguiente tabla.
8 7 6 5 4 3 2 1 Bit/Octeto
Identificador del elemento de información capacidad portadora
0 0 0 0 0 1 0 0 1
Longitud del contenido de capacidad portadora 2 ext.
1
Norma de codificación Capacidad de transferencia de información 3
ext. 1
Modo de transferencia Velocidad de transferencia de información 4
ext. 1
Multiplicador de velocidad 4.1*
ext. Identificador de capa 1 Protocolo de capa 1 de información del usuario 5*
0/1 0 1
ext. 0/1
Sinc./ asínc
Negoc. Velocidad de usuario 5a*
ext. 0/1
Velocidad intermedia NIC en Tx NIC en Rx Control flujo en Tx Control flujo en Rx Reserva 0 5b* ext. 0/1 Encabeza- miento/no encabeza- miento Soporte de multitrama Modo Negoc. LLI Asignador/ asignado Negoc. dentro/ fuera de banda Reserva 0 5b* ext. 0/1
Número de bits de parada Número de bits de datos Paridad 5c*
ext. 1
Modo dúplex
Tipo de módem 5d*
ext. Identificador de capa 2 Protocolo de capa 2 de información del usuario 6* 1 1 0
ext. Identificador de capa 3 Protocolo de capa 3 de información del usuario 7* 0 1 1
ext. Reserva Información adicional de protocolo de capa 3 7a*
0 0 0 0 (bits más significativos)
ext. Reserva Información adicional de protocolo de capa 3 7b*
1 0 0 0 (bits más significativos)
Tabla 14. Elemento de información capacidad portadora [10].
El protocolo H.225 impone las siguientes restricciones:
• Capacidad de transferencia de información (octeto N.º 3): o El bit de extensión (bit 8) se pondrá a '1'.
o La norma de codificación (bits 6, 7) se pondrá a '00' indicando 'UIT-T'.
o Capacidad de transferencia de información (bits 0-5): Las llamadas que se originan en un punto extremo H.323 utilizarán este campo para indicar su deseo de efectuar una llamada audiovisual. Por tanto, el campo se pondrá a 'información digital sin restricciones', es decir, '01000' o a 'información digital restringida' es decir '01001'. Si ha de efectuarse una llamada sólo vocal, el terminal H.323 pondrá la capacidad de transferencia de información a 'conversación' (es decir '00000') o a 'audio a 3,1 kHz' (es decir '10000').
• Bit de extensión para el octeto N.º 4 (bit 8): Se pondrá a '0' si la velocidad de
transferencia de información se pone a 'multivelocidad'; se pondrá a '1' en otro caso.
• Modo de transferencia – octeto abreviado N.º 4 (bits 6, 7): Especificará 'modo circuito', valor '00'.
• Velocidad de transferencia de información (bits 5 a 1): No se permite el valor '00000' (para el modo paquete) a menos que una pasarela se conecte a una red de paquetes. Las opciones son las siguientes:
Bits 5 4 3 2 1
0 0 0 0 0 Este código se utilizará para llamadas en modo paquete. 1 0 0 0 0 64 kbit/s 1 0 0 0 1 2 × 64 kbit/s 1 0 0 1 1 384 kbit/s 1 0 1 0 1 1536 kbit/s 1 0 1 1 1 1920 kbit/s
1 1 0 0 0 Multivelocidad (velocidad básica de 64 kbit/s) Los demás valores están reservados.
• Multiplicador de velocidad – octeto N.º 4.1: Estará presente si la velocidad de transferencia de información se pone a multivelocidad.
• Protocolo de capa 1(capa 1 de ISDN) – octeto N.º 5 o El bit de extensión (bit 8) se pondrá a '1'.
o Los bits 6 y 7 indicarán el identificador de capa 1 (capa 1 de ISDN), es decir, '01'. o Los bits 1 a 5 indicarán el protocolo de capa 1.
o Los valores permitidos son G.711 (ley A '00011' y ley µ '00010') para indicar una llamada de sólo voz y H.221 y H.242 ('00101') para indicar una llamada videotelefónica H.323.
o Los octetos N.º 5a, 5b, 5c, 5d no estarán presentes.
• Identificador de protocolo de capa 2 (capa 2 de ISDN) – octeto N.º 6: No estará presente.
• Identificador de protocolo de capa 3 (capa 3 de ISDN) – octeto N.º 7: No estará presente.
3.4.7 Elemento de información Causa
Indica la razón por la cual una llamada fue rechazada o desconectada. El contenido y el uso del elemento de información causa se definen en la Recomendación Q.850. La siguiente tabla muestra su codificación.
8 7 6 5 4 3 2 1 Bit/Octeto Identificador del elemento de información usuario a usuario
0 0 0 0 1 0 0 0 1
Longitud del contenido de usuario a usuario 2 0/1 ext Norma de codificación 0 Reservado Ubicación 3 1 ext Recomendación 3a 1
ext Valor Causa 4
Diagnostico (si existe) 5
Tabla 15. Elemento de información Causa.
• Norma de Codificación - octeto N° 3 (bits 7,6) Bits
7 6
0 0 Codificación estandarizada CCITT 0 1 ISO/IEC
1 0 Estándar Nacional
1 1 Norma específica de la ubicación identificada
• Ubicación - octeto N° 3 (bits 4 a 1) Bits
4 3 2 1
0 0 0 0 Usuario
0 0 0 1 Red privada que da servicio al usuario local 0 0 1 0 Red pública que da servicio al usuario local 0 0 1 1 Red de tránsito
0 1 0 0 Red pública que da servicio al usuario distante 0 1 0 1 Red privada que da servicio al usuario distante 0 1 1 1 Red internacional
1 0 1 0 Red que se extiende más allá del punto de interfuncionamiento Los demás valores están reservados
• Recomendación - octeto N° 3a Bits 7 6 5 4 3 2 1 0 0 0 0 0 0 0 Q.931 0 0 0 0 0 1 1 X.21 0 0 0 0 1 0 0 X.25
0 0 0 0 1 0 1 Redes públicas móviles terrestres Q.1031/Q.1051 Si este octeto es omitido se asume la recomendación Q.931.
• Valor Causa - octeto N° 4: Este valor indica la causa de la terminación de la llamada. Estos son algunos de sus posibles valores: Liberación normal de la llamada, Usuario ocupado, No hay respuesta del usuario, No hay respuesta del usuario, Abonado ausente Llamada rechazada, Red fuera de servicio, Fallo temporal, Capacidad portadora no implementada, Contenido de elemento de información no válido.
• Diagnostico - octeto N° 5: Dependiendo de la causa, se puede incluir un octeto de diagnostico en donde se proporcionan detalles de la causa de la terminación de la llamada.
3.4.8 Elemento de información Visualización
La finalidad del elemento de información visualización es suministrar información que puede ser visualizada por el usuario. La información contenida en este elemento se codifica en caracteres del Alfabeto Internacional N.° 5. El elemento de información visualización se codifica como se muestra en la tabla 16.
8 7 6 5 4 3 2 1 Bit/Octeto Identificador del elemento de información visualización
0 0 1 0 1 0 0 0 1
Longitud del contenido de visualización 2 0 Información de visualización (caracteres del IA5) 3 etc.
Tabla 16. Elemento de información Visualización.
3.4.9 Elemento de información Usuario a usuario
El elemento de información usuario a usuario será utilizado por todas las entidades H.323 para transportar información relacionada con H.323 y decodificada en PER de la sintaxis ASN.1. El elemento de información usuario a usuario se codifica como se muestra en la tabla 17.
8 7 6 5 4 3 2 1 Bit/Octeto Identificador del elemento de información usuario a usuario
0 1 1 1 1 1 1 0 1
Longitud del contenido de usuario a usuario 2
Discriminador de protocolo 3
Información de usuario 4
etc.
Tabla 17. Elemento de información Usuario a usuario.
El protocolo H.225 impone las siguientes restricciones:
• Longitud de contenido de usuario a usuario: Serán 2 octetos en vez de 1.
• Discriminador de protocolo: Indicará información de usuario codificada ('00000101') X.208 y X.209 (ASN.1). (Esto se toma de la revisión 1993 de la Recomendación Q.931, que hace referencia a las anteriores revisiones de ASN.1. Las referencias correctas a ASN.1 son la Recomendación X.680 (sintaxis) y la Recomendación X.691 (PER)).
• Información de usuario: Contendrá una estructura ASN.1 que contiene información pertinente H.323.
4. Protocolo de Iniciación de Sesiones (SIP)
El Protocolo de Iniciación de Sesiones es un protocolo de control a nivel de aplicación que permite la creación, modificación y terminación de sesiones multimedia con uno o más participantes. Estas sesiones incluyen llamadas telefónicas por Internet, distribuciones multimedia y conferencias multimedia.
Fue desarrollado por el Grupo de Trabajo en Ingeniería de Internet (IETF). Por lo tanto, SIP se caracteriza porque sus promotores tienen sus raíces en la comunidad IP y no en la industria de las telecomunicaciones. La primera versión SIP propuesta como estándar fue definida en la recomendación RFC2543 (SIP/1.0) y fue publicada en febrero de 1999. En Junio de 2002 surgió la segunda versión RFC3261 (SIP/2.0). SIP no es un sistema de comunicaciones integrado verticalmente. SIP es más bien un componente que puede ser usado con otros protocolos para construir una arquitectura multimedia completa. Sin embargo, la funcionalidad básica y operación de SIP no depende de ninguno de estos protocolos. SIP no proporciona servicios, más bien SIP provee bases que pueden ser usadas para implementar diferentes servicios.
4.1 Definiciones
A continuación se mencionan algunos términos que se definen en SIP.
• Sesión: Una sesión multimedia es un conjunto de emisores y receptores multimedia y los flujos de datos que fluyen de emisores a receptores.
• Mensaje: Es la data enviada entre elementos SIP como parte del protocolo. Los mensajes SIP son solicitudes o respuestas.
• Solicitud: Es un mensaje SIP enviado desde un cliente a un servidor con el propósito de invocar una operación particular.
• Método: Es la función principal que una solicitud desea invocar en un servidor. El método es transportado en el propio mensaje de solicitud. Ejemplos de método son “INVITE” y “BYE”.
• Respuesta: Es un mensaje SIP enviado desde un servidor hacia un cliente para indicar el estado de una solicitud enviada desde el cliente hacia el servidor.
• Cliente: Es un elemento de red que envía solicitudes SIP y recibe respuestas SIP. Los clientes pueden o no interactuar directamente con un usuario humano. Los agentes de usuario clientes y servidores proxy son ejemplos de clientes.
• Servidor: Es un elemento de red que recibe solicitudes para prestar algún servicio y envía de vuelta respuestas a esas solicitudes. Ejemplos de servidores son servidores proxy, agente de usuarios servidores, servidores de redirección y servidores de registro.
• Agente de usuario cliente (UAC): Es una entidad lógica que crea y envía una nueva solicitud. El papel de UAC permanece sólo en la duración de la transacción. En otras palabras, si un componente de software inicia una solicitud, actúa como UAC en la duración de la transacción. Si más tarde recibe una solicitud, asume el rol de agente de usuario servidor.
• Agente de usuario servidor: Es una entidad lógica que genera una respuesta a una solicitud SIP. La respuesta acepta, rechaza, o redirecciona la solicitud. Este rol permanece sólo en la duración de la transacción. En otras palabras, si un componente de software responde una solicitud, actúa como un UAS mientras dure la transacción. Si más tarde genera una solicitud, asume el rol de agente usuario cliente.
• Agente de usuario (UA): Es una entidad lógica que puede actuar tanto como un agente de usuario cliente y como un agente de usuario servidor.
• Transacción: Una transacción ocurre entre un cliente y un servidor y comprende todos los mensajes desde la primera solicitud enviada desde el cliente al servidor, hasta una respuesta final enviada del servidor al cliente. Si la solicitud es “INVITE” y la respuesta final no es una respuesta 2xx, la transacción también incluye una solicitud “ACK” a esa respuesta. La solicitud ACK para una respuesta 2xx a una solicitud INVITE es una transacción separada.
• Respuesta final: Es una respuesta que termina una transacción al contrario de las respuestas provisionales. Todas las respuestas 2xx, 3xx, 4xx, 5xx y 6xx son respuestas finales.
• Respuesta provisional: Es una respuesta usada por el servidor para indicar progreso, pero que no termina la transacción. Las respuestas 1xx son provisionales, las otras son consideradas finales.
• Diálogo: Es una relación entre dos agentes de usuario que persiste por algún tiempo. Un diálogo es establecido por un mensaje SIP, tal como una respuesta 2xx a una solicitud “INVITE”. Un diálogo es identificado por un identificador de llamada, una etiqueta local y una etiqueta remota.
• Servidor proxy: Es una entidad intermedia que actúa tanto como servidor como cliente con el propósito de hacer solicitudes en nombre de otros clientes. Un servidor proxy principalmente juega el papel de enrutador, lo cual significa que su trabajo es asegurar que una solicitud sea enviada a una entidad más cercana al usuario destino. Los servidores proxy también son útiles para imponer políticas (por ejemplo, asegurar que un usuario tenga permitido hacer llamadas). Un servidor proxy interpreta, y, si es necesario, rescribe partes específicas de un mensaje de solicitud antes de pasarlo.
• Identificador uniforme de recursos (URI): Es una cadena compacta de caracteres usada para identificar un recurso abstracto o físico.
4.2 Indicador uniforme de recursos (URI)
Un URI SIP identifica un recurso de comunicación. El esquema “sip:” se rige por el estándar RFC 2396. Este esquema usa una forma similar al “mailto” URL. La forma general de un URI SIP es:
sip:usuario:contraseña@host:puerto;parámetros-uri?cabeceras
El uso de los componentes de un URI depende del contexto. Estos elementos tienen los siguientes significados:
• usuario: Es el identificador de un recurso particular en el host que está siendo direccionado. En este contexto el término “host” frecuentemente se refiere a un dominio. La información de usuario de un URI consiste de este campo usuario, el campo contraseña y el símbolo @. La información de usuario de un URI es opcional y puede estar ausente cuando el host destino no tiene una noción de usuario o cuando el host en sí mismo es el recurso que está siendo identificado.
• contraseña: Es una contraseña asociada con el usuario. Su uso dentro de un URI no es recomendado por razones de seguridad.
• host: Es el host que provee el recurso SIP. Contiene un nombre de dominio o una dirección numérica IPv4 o IPv6.
• puerto: Es el número del puerto donde la solicitud será enviada. El valor por defecto para un URI SIP es 5060 y para un URI SIPS es 5061.
• parámetros-uri: Son parámetros que afectan una solicitud construida desde el URI. Estos parámetros son separados por punto y coma. Los parámetros URI toman la forma nombre-de-parámetro = valor-del-parámetro.
• cabeceras: Campos de cabecera que serán incluidos en una solicitud construida desde el URI.
4.3 Mensajes SIP
SIP es un protocolo basado en texto y usa el conjunto de caracteres UTF-8 (8-bit Unicode Transformation Format). Excepto por la diferencia en el conjunto de caracteres, la sintaxis de muchos de los mensajes y campos de cabeceras SIP es idéntica a HTTP/1.1 (RFC 2616). Sin embargo, SIP no es una extensión de HTTP. Un mensaje SIP es una solicitud desde un cliente a un servidor o una respuesta desde un servidor a un cliente. Tanto las solicitudes como las respuestas usan el formato básico RFC 2822 (Formato de Mensaje de Internet). Ambos poseen la siguiente estructura:
Línea de inicio Cabecera del mensaje
Línea Vacía Cuerpo del mensaje
(opcional)
Tabla 18. Estructura de un mensaje SIP.
La línea vacía debe estar presente incluso si no existe el cuerpo de mensaje. La línea de inicio puede ser una línea de solicitud o una línea de estado dependiendo de si el mensaje es una solicitud o una respuesta, respectivamente.
4.3.1 Solicitudes
Las solicitudes SIP se distinguen por tener una Línea-de-Solicitud en la línea de inicio. Una Línea-de-Solicitud contiene un nombre de método, un URI-de-solicitud, y la versión del protocolo separados por un espacio simple:
Línea-de-Solicitud = Método URI-de-Solicitud Versión-SIP
• Método: Es la función principal que una solicitud desea invocar en un servidor. La especificación RFC 3261 define seis métodos:
o “REGISTER” para registro de información de contacto. o “INVITE” para iniciar una sesión.
o “ACK” para indicar el reconocimiento de recepción de una respuesta. o “CANCEL” para cancelar sesiones.
o “BYE” para terminar sesiones.
o “OPTIONS” para servicios de indagación de capacidades.
• URI-de-Solicitud: Indica el usuario o servicio al cual esta solicitud esta siendo dirigida.
• Versión-SIP: Tanto los mensajes de solicitud como los de respuesta incluyen la versión de SIP en uso. Para ser consistente con el estándar RFC 3261, las aplicaciones que envíen mensajes deben incluir “SIP/2.0” en Versión-SIP.
4.3.2 Respuestas
Las respuestas SIP se diferencian de solicitudes por tener una Línea-de-Estado como su línea de inicio. Una Línea-de-Estado consiste de la versión del protocolo seguido por un número Código-de-Estado y su frase textual asociada, con cada elemento separado por un espacio simple:
Línea-de-Estado = Versión-SIP Código-de-Estado Frase
• Código-de-Estado: Es un código entero de 3 dígitos que indica el resultado de un intento de entender y satisfacer una solicitud. El primer dígito del Código-de-Estado define la clase de respuesta. Cualquier respuesta con un código de estado entre 100 y 199 es calificada como una respuesta 1xx, una respuesta con código de estado entre 200 y 299 como una respuesta 2xx, y así sucesivamente. SIP/2.0 permite seis valores para el primer dígito:
o 1xx – Provisional: Solicitud recibida, se continúa a procesar la solicitud. o 2xx – Satisfactorio: La acción fue recibida, entendida y aceptada
satisfactoriamente.
o 3xx – Redirección: Otras acciones deben ser tomadas para completar la solicitud.
o 4xx – Error del cliente: La solicitud contiene mala sintaxis o no puede ser ejecutada en este servidor.
o 5xx – Error del servidor: El servidor falló en ejecutar una solicitud aparentemente válida.
o 6xx – Falla general: La solicitud no puede ser ejecutada por ningún servidor.
• Frase: Tiene la intención de dar una breve descripción textual al Código-de-Estado. La Frase está destinada para el usuario humano. Un cliente no está obligado a examinar o mostrarla. A pesar de que SIP sugiere valores específicos de Frase, las implementaciones pueden escoger otros textos, por ejemplo, en el algún idioma en particular.
En la siguiente tabla se muestran algunas respuestas SIP con sus códigos y descripciones correspondientes.
Clase Código Descripción
100 Intentando
1xx
(Provisional) 180 Repicando
2xx
(Satisfactorio) 200 Satisfactorio (OK)
301 Movido permanentemente
3xx
(Redirección) 302 Movido temporalmente
400 Mala solicitud
401 Desautorizado
404 No encontrado
405 Método no permitido
407 Autenticación requerida por el servidor proxy
483 Demasiados saltos
4xx (Error del
cliente)
486 Ocupado aquí
500 Error interno del servidor
501 No implementado
5xx (Error del
servidor) 505 Versión no soportada
600 Ocupado en todas partes
6xx
(Falla global) 604 No existe en ninguna parte
Tabla 19. Respuestas SIP
4.3.3 Cabecera
La cabecera del mensaje está compuesta de una serie de campos. La presencia de un campo en particular depende del tipo de mensaje. Cada campo de cabecera consiste de un nombre del campo seguido por dos puntos (“:”) y el valor del campo:
Nombre-del-campo: valor-del-campo
El orden relativo de los campos de cabecera con diferentes nombres de campo no es significativo. Sin embargo, es recomendado que los campos de cabecera que son necesitados en el procesamiento de los servidores proxy (por ejemplo: Via, Route, Record-Route, Proxy-Require, Max-Forwards y Proxy-Authorization) aparezcan en el tope superior del mensaje facilitando su rápido análisis. El orden relativo de las filas de campos de cabecera con el mismo nombre de campo si es importante.
El formato de valor-del-campo es definido por nombre-del-campo. Muchos campos de cabecera existentes adherirán a la forma general un valor seguido por una secuencia de parámetros. Un parámetro consiste en un nombre y un valor separados por punto y coma:
nombre-del-campo: valor-del-campo *(;nombre-del-parámetro=valor-del-parámetro)
Aunque se puede adjuntar un número arbitrario de parámetros, un nombre de parámetro no debe aparecer más de una vez
4.3.4 Cuerpo del mensaje
Los mensajes pueden contener cuerpos de mensaje. La interpretación del cuerpo depende del método solicitado. El tipo de medio Internet del cuerpo del mensaje puede ser especificado por el campo de cabecera “Content-Type”. Si el cuerpo está sujeto a alguna codificación, tal como alguna compresión, entonces esto debe ser indicado por el campo de cabecera “Content-Encoding”, en otro caso, “Content-Encoding” debe ser omitido. La longitud del cuerpo en Octetos es provista por el campo de cabecera Content-Length.
4.4 Establecimiento y finalización de una llamada SIP
La siguiente figura muestra los procesos de establecimiento y finalización de una llamada en SIP. Se trata de un caso típico que consiste en una llamada entre dos usuarios del mismo dominio a través de un servidor proxy que presta servicio en ese dominio. Las flechas azules indican solicitudes mientras que las rojas indican respuestas.
La solicitud “INVITE” (1) es una solicitud que puede originar la creación de un diálogo (de hecho en RFC 3261, es la única que lo puede hacer). Sin embargo, puesto que no se ha establecido uno, esta es una solicitud fuera de diálogo y su construcción se explica en 4.5.1.1 (Generación de solicitudes). También es una solicitud que inicia una sesión y por lo tanto, también se siguen las indicaciones en 4.7 (Inicio de sesiones). En este caso, el servidor proxy solicita información de autenticación por medio de la respuesta 407 (2), la cual se construye como se indica en 4.5.2.1 (Generación de respuestas). Luego el usuario A envía una solicitud “ACK” (3) para indicar el reconocimiento de esta respuesta. Esta solicitud también es una solicitud fuera de diálogo y se construye según 4.5.1.1. Seguidamente el usuario A procede a enviar nuevamente la solicitud “INVITE” (4), pero esta vez con la información de autenticación solicitada. Una vez más, esta es una solicitud fuera de diálogo y por lo tanto, se construye como indica la sección 4.5.1.1. El servidor proxy recibe esta solicitud, la maneja tal como se explica en 4.9 (Comportamiento de los servidores proxy) y la encamina hacia el usuario B (5). El usuario B responde con una respuesta 100 (Intentando) (6) para indicar al servidor proxy que se están tomando acciones para establecer la sesión. Esta respuesta se diferencia de otras respuestas provisionales en que nunca es reenviada por un servidor proxy. Esta respuesta se construye como se explica en 4.5.2.1. Luego el usuario B envía una respuesta 180 (Repicando) (7) para indicar al usuario A que se está alertando al usuario B. Esta repuesta también se construyen como se explica en 4.5.2.1 y como se indica en la sección 4.6 (Diálogos), porque es una respuesta que crea un diálogo temprano y se debe almacenar el estado de este diálogo. Esta respuesta
es encaminada por el servidor proxy según lo especificado en 4.9 (8). Al llegar esta respuesta al usuario A, se almacena el estado del diálogo según 4.6.
Servidor Proxy Usuario B
Usuario A
INVIT E (1)
407 Autenticación requerida por el servidor proxy (2)
ACK (3) INVIT E (4) INVIT E (5) 100 Intent ando (6) 180 Repicando (7) 200 OK (9) 180 Repicando (8) 200 OK (10) ACK (11) Conversación (12) 200 OK (14) BYE (13)
Figura 3. Establecimiento y finalización de una llamada SIP.
Una vez que el usuario B decide aceptar la sesión, envía una respuesta 200 (“OK”) (9) al usuario A. Esta respuesta debe ser construida según se explica en 4.5.2.1, en 4.6 (ya que convierte el diálogo temprano en un diálogo confirmado) y en 4.7 (Inicio de Sesiones, porque inicia una sesión). Esta respuesta es encaminada por el servidor proxy hacia el usuario A según 4.9. Al llegar esta respuesta al usuario A, el diálogo queda completamente establecido. Por consiguiente, cualquier solicitud que se envíe a partir de este momento es una solicitud dentro de diálogo. Esto incluye a la solicitud “ACK” (11), la cual es enviada para indicar que se reconoce la respuesta 200, y se debe construir como indica 4.6. Después que se envía esta solicitud se establece la sesión (12). Para finalizar la sesión y el diálogo, se envía una solicitud BYE. Esta solicitud también está dentro del diálogo y se construye según 4.6.
4.5 Comportamiento general de los agentes de usuario
Cuando un agente de usuario envía una solicitud, inicia una transacción y se comportará como un agente de usuario cliente mientras dure esta transacción. El agente de usuario que responda a esta solicitud se comportará como un agente de usuario servidor. Los procedimientos de los UAC (agentes de usuario clientes) y los UAS (agentes de usuario servidores) dependen principalmente de dos factores. Primero, depende de si la solicitud o respuesta está o no dentro del diálogo, y segundo, depende del método de la solicitud. En esta sección se describe las reglas independientes del método que rigen el procesamiento por parte de los UAC y UAS de las solicitudes que están fuera del diálogo. Esto incluye, por supuesto, las solicitudes que establecen el diálogo. En RFC 3261 la única solicitud que puede originar la creación de un dialogo es la solicitud “INVITE”.
4.5.1 Comportamiento de los agentes de usuario clientes 4.5.1.1 Generación de solicitudes
Una solicitud SIP válida formulada por un UAC debe, como mínimo, contener los siguientes campos de cabecera: “To”, “From”, “CSeq”, “Call-ID”, “Max-Forwards”, y “Via”. Todos estos campos de cabecera son obligatorios en todas las solicitudes SIP y son los bloques fundamentales de un mensaje SIP. A continuación se describen estos campos de cabecera junto al URI-de-Solicitud de la línea de solicitud.
• URI-de-Solicitud: La URI-de-Solicitud inicial debería ser el valor de URI en el campo To.
• “To”: El campo de cabecera “To” específica el recipiente lógico deseado de la solicitud, o la dirección de registro del usuario o el recurso destino de la solicitud. El campo de cabecera “To” contiene un URI y permite un nombre para visualización. Una solicitud fuera de diálogo no debe contener un parámetro “tag” (etiqueta) para el campo “To”. El parámetro “tag” en el campo “To” de una solicitud es uno de los identificadores del diálogo. Puesto que un diálogo no ha sido establecido, no existe una etiqueta.
• “From”: Indica la identidad lógica del iniciador de la solicitud. Al igual que el campo “To”, contiene un URI y opcionalmente un nombre para visualización. El campo de cabecera “From” puede contener un nuevo parámetro “tag” (etiqueta) elegido por el UAC.
• “Call-ID”: Actúa como un único identificador para agrupar una serie de mensajes. Debe ser el mismo para todos las solicitudes y respuestas enviadas por cualquier UA en un diálogo. Cuando una solicitud es reenviada después de alguna repuesta de falla, esa solicitud reenviada no es considerada una nueva solicitud, y por lo tanto, no necesita un nuevo “Call-ID”.
• “CSeq”: Sirve para identificar y ordenar transacciones. Contiene un número de secuencia y un método. Para solicitudes fuera de diálogo que no sean de registro, el valor del número de secuencia es arbitrario. El método debe concordar con el de la solicitud. El valor del número de secuencia debe ser expresable como un entero sin signo de 32 bits y debe ser menor que 2 . 31
• “Max-Forwards”: Sirve para limitar el número de saltos que una solicitud puede transitar en el camino a su destino. Consiste en un entero que es disminuido en uno en cada salto. Si el valor de “Max-Forwards” llega a ser 0 antes que la solicitud alcance su destino, la solicitud será rechazada con una respuesta de error 483 (Demasiados Saltos). Un UAC debe insertar un campo “Max-Forwards” en cada solicitud que él origina con un valor que debería ser 70. Este número fue escogido lo suficientemente grande para garantizar que una solicitud no sea borrada en cualquier red SIP sin lazos, pero no tan grande como para consumir los recursos de los servidores proxy cuando ocurre un lazo.
• Via: Indica el transporte usado para la transacción e identifica la ubicación donde la respuesta debe ser enviada. Cuando un UAC crea una solicitud debe insertar un campo “Via”. Contiene el nombre y versión del protocolo que deben ser SIP y 2.0 respectivamente. El campo “Via” también debe contener un parámetro llamado “branch”. Este parámetro es usado para identificar la transacción creada por la solicitud y también es usado por los servidores proxy para detectar lazos. El parámetro “branch” debe ser único para todas las solicitudes enviadas por el UA. La excepción a esta regla son la solicitud “CANCEL” y la solicitud “ACK” para una respuesta no 2xx. Una solicitud “CANCEL” tendrá el mismo valor del parámetro “branch” que el de la solicitud que está cancelando. Una solicitud “ACK” para una respuesta no 2xx también tendrá el mismo parámetro “branch” que la solicitud INVITE cuya respuesta reconoce. El identificador “branch” insertado por un elemento que obedezca la especificación RFC 3261 siempre debe comenzar con los caracteres “z9hG4bK”.
• Contact: Provee un URI que puede ser usado para contactar esa instancia específica del UA para solicitudes subsiguientes. El campo “Contact” debe estar presente en una solicitud que puede resultar en el establecimiento de un diálogo y contener exactamente un URI.
• Componentes de mensaje adicionales: Después que una solicitud ha sido creada y los campos de cabecera descritos anteriormente han sido construidos correctamente, cualquier campo de cabecera opcional puede ser añadidos, como son los campos de cabecera específicos del método.
4.5.1.2 Procesamiento de respuestas
La mayor parte del procesamiento de respuesta es específica del método. Sin embargo, existen algunos comportamientos generales independientes del método que se describen en la especificación RFC 3261. Por ejemplo, si en la respuesta está presente más de un campo “Via”, el UAC debería descartar el mensaje. La presencia de un campo “Via” adicional que precede el creador de la solicitud sugiere que el mensaje fue sacado de su ruta o que posiblemente fue alterado. Si el UAC recibe una respuesta 401 (Desautorizado) o 407 (Autenticación requerida por el servidor proxy), el UAC debería reintentar la solicitud pero ahora con la información de autenticación. Para ello, se debe añadir el campo “Proxy-Authenticate”, el cual contiene información de autenticación. En este caso, la respuesta se envía nuevamente constituyendo una nueva transacción y debería tener el mismo valor de “Call-ID”, “To” y “From” de la solicitud previa, pero el valor de “CSeq” debería contener
un nuevo número de secuencia que igual al valor de la solicitud anterior incrementado en uno.
4.5.2 Comportamiento de los agentes de usuario servidores
Cuando una solicitud fuera de diálogo es recibida por un UAS, hay un conjunto de normas de procedimientos que se deben seguir, independientemente del método. Una vez que una solicitud es autenticada, el UAS debe inspeccionar el método de la solicitud, y revisar si lo soporta o no y, en caso de que no lo soporte, generar una respuesta 405 (Método no permitido). Luego el UAS debe inspeccionar la cabecera. Si el UAS no entiende un campo de cabecera en una solicitud, debe ignorar ese campo de cabecera y continuar procesando el mensaje. Un UAS debe ignorar cualquier campo de cabecera defectuoso que no sea necesario para procesar el mensaje. Seguidamente, el UAS debe examinar el cuerpo del mensaje. Si existe algún cuerpo cuyo tipo o codificación sea desconocido y si el cuerpo del mensaje no es opcional, el UAS debe rechazar la solicitud con una respuesta 415 (Tipo de medio no soportado). Asumiendo que todas las revisiones anteriores fueron satisfactorias, el UAS debe ejecutar el procesamiento específico del método. Una vez procesada la solicitud, el UAS procede a formular la respuesta.
4.5.2.1 Generación de la respuesta
Un UAS no debería enviar una respuesta provisional para una solicitud que no sea “INVITE”. Al contrario, un UAS debería generar lo más pronto posible una respuesta final a una solicitud que no sea “INVITE”. Los campos “From”, “Call-ID” y “Cseq” de la respuesta deben ser iguales a los de la solicitud. Los valores del campo “Via” de la respuesta deben ser iguales a los de la solicitud y mantener el mismo orden.
Si una solicitud contenía una etiqueta (“tag”) en el campo “To”, el campo “To” en la respuesta debe ser igual al de la solicitud. Sin embargo, si el campo “To” en la solicitud no contiene una etiqueta, el URI en el campo “To” en la respuesta debe ser igual al URI en el campo “To” de la solicitud; adicionalmente, el UAS debe añadir una etiqueta al campo “To” en la respuesta (con la excepción de la respuesta 100 (“Trying”), en la cual una etiqueta puede estar presente o no). Esto sirve para identificar el UAS que está respondiendo, resultando posiblemente en un componente de un identificador de diálogo. La misma etiqueta debe ser usada para todas las respuestas a esa solicitud, tanto final como provisional (otra vez exceptuando la respuesta 100 (“Trying”)).
4.6 Diálogos
Un concepto clave para los agentes de usuario es el diálogo. Un diálogo representa una relación SIP punto a punto entre dos agentes de usuario que prevalece por algún tiempo. El diálogo facilita la secuencia de mensajes entre los agentes de usuario y el correcto enrutamiento entre ellos. Representa un contexto para interpretar mensajes SIP. El diálogo es identificado dentro de cada UA con una identificador (ID) de diálogo, el cual consiste de un valor “Call-ID”, una etiqueta local y una etiqueta remota. El identificador de diálogo en cada UA involucrado en el diálogo no es el mismo. Específicamente, la etiqueta
local en un UA es idéntica a la etiqueta remota en el otro UA y viceversa. Las etiquetas facilitan la generación de un identificador de diálogo único.
Las reglas de establecimiento del ID de diálogo de un mensaje dependen de si el elemento SIP es un UAC o un UAS. Para un UAC, el valor “Call-ID” del diálogo es el “Call-ID” del mensaje, la etiqueta remota es la etiqueta (“tag”) en el campo “To” del mensaje y la etiqueta local es la del campo “From”. Para un UAS, el valor “Call-ID” del ID del diálogo es el “Call-ID” del mensaje, la etiqueta remota es la etiqueta (“tag”) del campo “From” del mensaje y la etiqueta local es la etiqueta (“tag”) del campo “To”.
Un diálogo contiene ciertas piezas de estado necesarias para la transmisión dentro del diálogo. Este estado consiste del ID del diálogo, un número de secuencia local (usado para ordenar solicitudes desde el UA al UA opuesto), una número de secuencia remoto (usado para ordenar solicitudes desde el UA opuesto al UA), un URI local, un URI remoto, destino remoto, una bandera booleana llamada “secure” y un conjunto de ruta, el cual es una lista ordenad de URIs. El conjunto de ruta es la lista de servidores que necesitan ser atravesados para enviar una solicitud al UA opuesto. Todos estos parámetros son usados para construir solicitudes y analizar respuestas dentro del diálogo. Un diálogo puede estar también en el estado “temprano”, el cual ocurre cuando es creado con una respuesta provisional, y luego es transformado a un estado “confirmado” cuando una llega respuesta final 2xx. Si en un diálogo temprano, se recibe otras respuestas, o si no se recibe ninguna respuesta, el dialogo temprano termina.
Los diálogos son creados a través de la generación de respuestas que no sean de fallos para solicitudes con métodos específicos. En la especificación RFC 3261, sólo las respuestas 2xx y las respuestas 101-199 con una etiqueta en el campo “To”, donde la solicitud fue “INVITE”, establecerán un diálogo. Una vez que el UAS responde una solicitud con una respuesta que establece un diálogo, el UAS construye el estado del diálogo. En el UAC, el estado se construye cuando se recibe esta respuesta. Este estado debe ser mantenido durante la duración del diálogo. En este estado se almacenan una serie de información que será utilizada en la construcción y manejos de solicitudes y respuestas que pertenezcan al diálogo. Un ejemplo de la información que se almacena es el conjunto de ruta especificado en la cabecera “Record-Route” de la solicitud, la cual es la lista de servidores que necesitan ser atravesados para enviar una solicitud al UA opuesto y que debe ser almacenado en el estado del diálogo.
Cuando un UAS responde a una solicitud con una respuesta que establece un diálogo (tal como una respuesta 2xx a una solicitud “INVITE”), el UAS debe copiar todos los campos Record-Route de la solicitud dentro de la respuesta y manteniendo el mismo orden. Debe añadir una campo “Contact” a la respuesta. El campo “Contact” contiene una dirección donde el UAS le gustaría ser contactado en subsiguientes solicitudes dentro del diálogo (lo cual incluye la solicitud “ACK” para una respuesta 2xx en el caso de la solicitud “INVITE”).
Seguidamente el UAS construye el estado del diálogo. Este estado debe ser mantenido durante la duración del diálogo. El conjunto de ruta es construido con los campos Record-Route manteniendo el mismo orden. El destino remoto es puesto igual al
URI del campo “Contact” de la solicitud. El numero de secuencia remota se coloca igual a al valor del campo “CSeq” de la solicitud. El número de secuencia local debe estar vacío. El valor de “Call-ID” de la solicitud será el identificador de llamada del ID del diálogo. La etiqueta local del ID del diálogo debe ser igual a la etiqueta “tag” del campo “To” en la solicitud, y la etiqueta remota debe ser igual a la etiqueta “tag” del campo “From”. El URI remoto debe ser puesto igual al URI del campo “From”, y el URI local igual al URI en el campo “To”.
Por otra parte, cuando el UAC recibe una respuesta que establece un diálogo (tal como una respuesta 2xx a una solicitud “INVITE”), construye el estado del diálogo, el cual debe ser mantenido mientras dure el diálogo. El conjunto de ruta debe ser construido a partir de los campos Record-Route de la respuesta pero en orden inverso. El destino remoto es puesto igual al URI del campo “Contact” de la solicitud. El número de secuencia local debe ser puesto igual al valor de “CSeq” de la solicitud. El número de secuencia remota debe estar vacío (éste es establecido cuando el UA remoto envíe una solicitud dentro del diálogo). El componente identificador de llamada del ID del diálogo es colocado igual al valor “Call-ID” de la solicitud. La etiqueta local debe ser igual a la etiqueta “tag” del campo “From” en la solicitud, mientras que la etiqueta remota debe ser igual a la etiqueta “tag” del campo “To” en la respuesta. El URI remoto debe ser puesto igual al URI del campo “To” y el URI local igual al URI del campo “From”.
Una solicitud dentro de un diálogo es construida usando mucho de los componentes del estado del diálogo almacenado. El URI en el campo “To” de la solicitud debe ser el URI remoto del diálogo. La etiqueta “tag” en el campo “To” debe ser la etiqueta remota del diálogo. El URI del campo “From” debe ser el URI local del estado del diálogo. La etiqueta “tag” en el campo “From” debe ser la etiqueta local del diálogo. El valor “Call-ID” de la solicitud debe ser el “Call-ID” del diálogo. Las solicitudes dentro del diálogo contienen números “CSeq” que deben ser incrementados en uno (excepto en las solicitudes “ACK” y “CANCEL”, que contienen un “CSeq” igual a la solicitud siendo reconocida o cancelada). Por lo tanto, si el número de secuencia local no está vacío, debe ser incrementado en uno y este valor debe ser colocado en el campo “CSeq” de la solicitud. Si está vacío, el valor inicial de “CSeq” debe ser creado usando las indicaciones de la especificación RFC 3261. El método del campo “Cseq” debe ser el mismo método de la solicitud. El UAC usa el destino remoto y el conjunto de ruta para construir el URI-de-la-Solicitud y los campos “Route” de la solicitud, respectivamente. Un AUC debería incluir el mismo campo “Contact” usado en las solicitudes anteriores. El resto de la solicitud es construido como indica la sección 4.5.1.1 (como una solicitud fuera de diálogo, para los campos “Via” y “Max-Forwards”).
La construcción de repuestas en el diálogo se guía por el procedimiento en 4.5.2.1.
El mecanismo para terminar diálogos confirmados es específico del método. En la especificación RFC 3261, la solicitud con el método “BYE” termina una sesión y el diálogo asociada con ella. Esta solicitud es una solicitud dentro del diálogo y debe ser construida como tal.
4.7 Inicio de sesiones
Cuando un agente de usuario cliente decide iniciar una sesión (por ejemplo, audio, video o un juego), formula una solicitud “INVITE”. La solicitud INVITE pide a un servidor establecer una sesión. Esta solicitud puede ser reenviada por servidores proxy, eventualmente llegando a uno o más UAS que pueden aceptar la invitación. Estos UAS frecuentemente necesitarán preguntar al usuario humano si acepta la invitación. Después de algún tiempo, estos UAS pueden aceptar la invitación (lo que significa que la sesión es establecida) enviando una respuesta 2xx. Si la invitación no es aceptada, se envía una respuesta 3xx, 4xx, 5xx o 6xx, dependiendo de la razón del rechazo. Antes de enviar una respuesta final, el UAS también puede enviar respuestas provisionales (1xx) para avisar al UAC del progreso de contactar al usuario llamado, por ejemplo una respuesta 100 (Intentando) para indicar que la solicitud ha sido recibida y que se están tomando acciones o una respuesta 180 (Repicando) para indicar que el teléfono esta sonando.
Después de recibir una o más repuestas provisionales, el UAC esperará por una o más respuesta. Debido a la prolongada cantidad de tiempo que puede tomar recibir una respuesta final a la solicitud “INVITE” (ya que depende de cuando el usuario llamado ejecuta una acción), el mecanismo de fiabilidad para una transacción “INVITE” difiere de otras solicitudes. Esto quiere decir que el tiempo de expiración de una solicitud “INVITE” es mucho mayor que los de las demás solicitudes. Una vez que recibe una respuesta final, el UAC necesita enviar una solicitud “ACK” por cada respuesta final que recibe.
El procedimiento para enviar esta solicitud “ACK” depende del tipo de respuesta. En el caso de respuestas 2xx, el UAC debe generar una solicitud “ACK” por cada respuesta 2xx recibida. Los campos de esta solicitud ACK son construidos en la misma forma que se hace para una solicitud dentro de un diálogo con la excepción del campo “CSeq”. El número de secuencia del campo “CSeq” debe ser el mismo que el de la solicitud “INVITE” que se reconoce, pero el método de “CSeq” debe ser “ACK”.
Una respuesta 2xx para una solicitud “INVITE” establece una sesión, y también crea un diálogo entre el UA que envió la solicitud “INVITE” y el UA que genera la respuesta 2xx. Puesto que la solicitud “INVITE” inicial representa una solicitud fuera de diálogo, su construcción sigue los procedimientos de la Sección 4.5.1.1. Un UAC también puede añadir otros campos de cabecera, como por ejemplo, “User-Agent” el cual provee el nombre y versión del agente de usuario cliente.
El UAC puede decidir añadir un cuerpo de mensaje a la solicitud “INVITE”. Si este cuerpo es usado para describir sesiones, se debe hacer uso de la especificación RFC 2327 (Protocolo de Descripción de Sesiones (SDP)). SIP usa un modelo oferta/respuesta descrito en RFC 3264, donde un UA envía una descripción de sesión, llamada oferta, que contiene una descripción propuesta de la sesión. La oferta indica los medios de comunicación deseados (audio, video, juegos), parámetros de esos medios (por ejemplo tipos de CODEC) y direcciones para recibir medios. El otro UA responde con otra descripción de la sesión, llamada respuesta, la cual indica cuales medios de comunicación son aceptados, los parámetros que aplican para esos medios y direcciones para recibir medios. En la especificación RFC 3261, las ofertas y las respuestas sólo pueden aparecer en solicitudes
“INVITE”, en sus respuestas y en las solicitudes “ACK”. Hay dos posibilidades para este modelo oferta/respuesta: la oferta esta en la solicitud “INVITE” y la respuesta en el mensaje 2xx, o la oferta está en la respuesta 2xx y la respuesta en la solicitud “ACK”. Si la solicitud “INVITE” no contiene una descripción de sesión, entonces el UAC ha solicitado que el UAS provea la oferta de la sesión en la respuesta 2xx.
4.8 Finalización de sesiones
La solicitud “BYE” es usada para terminar una sesión específica o un intento de sesión. Cuando una solicitud “BYE” es recibida sobre un diálogo, cualquier sesión asociada con ese diálogo debería terminar.
Una solicitud “BYE” es construida como se haría con cualquier otra solicitud dentro de diálogo. El UAS que recibe la solicitud “BYE” verifica si concuerda con algún diálogo existente. Si no concuerda con ningún diálogo existente, el UAS debería generar una respuesta 481 (Llamada/Transacción no existe). Si existe el diálogo, el UAS debería terminar la sesión siempre que no se trate de sesiones multicast. Si se trata de una sesión multicast, el UAS puede decidir si terminar o no su participación. Independientemente de si termina su participación o no, el UAS debe generar una respuesta 2xx para la solicitud BYE.
4.9 Comportamiento de los servidores proxy
Los servidores proxy son elementos que encaminan las solicitudes SIP hacia los agentes de usuarios servidores y las respuestas SIP hacia los agentes de usuario clientes. Una solicitud puede atravesar varios servidores proxy en su camino hacia un UAS. Cada uno de ellos va a tomar una decisión de enrutamiento, modificando la solicitud antes de enviarla al siguiente elemento. Las respuestas a esa solicitud serán encaminadas a través del mismo conjunto de servidores proxy que atravesó la solicitud en orden inverso.
Cuando un servidor proxy recibe una solicitud, debe inspeccionar el URI-de-la-Solicitud en la línea de inicio. Si este URI indica un dominio que no es responsabilidad de este servidor proxy, éste no debe cambiar el URI-de-la-Solicitud y debe proceder a pasar la solicitud al siguiente elemento. Si el dominio sí es responsabilidad del servidor proxy, éste remplaza el URI-de-la-Solicitud con el resultado obtenido de algún servicio de localización.
Si este servidor proxy desea permanecer en el camino de futuras solicitudes (asumiendo que la solicitud actual creará un diálogo), debe insertar un campo “Record-Route” dentro de la solicitud antes de cualquier campo “Record-“Record-Route” existente. Cuando el UAS devuelva una respuesta a esta solicitud, ésta debe contener una réplica de estos campos “Record-Route”. Los campos “Record-Route” van a servir en el UAC y el UAS para construir el estado del diálogo. Dentro de estos estados se almacenará esta lista de campos “Record-Route” para así establecer una ruta dentro del diálogo.
Cuando se envíen futuras solicitudes dentro del diálogo, estás podrán contener una lista de campos “Route” que contienen los mismos valores de los campos “Record-Route” almacenados anteriormente. Si están presentes, estos campos “Route” son utilizados por los
servidores proxy para encaminar una solicitud. El servidor proxy inspeccionará el campo “Route” que se encuentra en la parte superior. Si este campo “Route” indica este servidor proxy, éste remueve este campo. Luego el servidor proxy reenvía la solicitud al punto indicado en el nuevo campo “Route” en la parte superior o al URI-de-la-solicitud si no hay campos “Route” presentes.
Por otra parte, el servidor proxy debe insertar un campo Via dentro de la solicitud antes de cualquier campo Via existente. Este campo Via indica la ubicación del servidor proxy y debe tener un parámetro branch. Las respuestas se encaminan por el mismo trayecto recorrido por las solicitudes gracias a los campos Via. Cuando un servidor proxy recibe una respuesta, remueve el campo Via que se encuentra en la parte superior y reenvía la respuesta al punto indicado por el siguiente campo Via.
5. Aplicación Analizador de Protocolos
Es una aplicación que sirve para capturar, decodificar y visualizar las tramas que contienen los mensajes de señalización H.323 y los mensajes SIP. La siguiente figura muestra los diversos controles que posee esta aplicación.
Figura 4. Barra de herramientas.
A continuación se explica cada una de estas funciones:
Este botón borra todas las tramas capturadas para comenzar una nueva captura.
Guarda la captura en un archivo de texto.
Comienza captura de tramas.