“LABORATORIO TCP/IP”

LUIS ALFONSO PEREZ AMAYA VICTOR HUGO DE LA FUENTE

MAESTRIA EN INGENERIA DE TELECOMUNICACIONES UNIVERSIDAD DE BUENOS AIRES - EGRIET

2008

2

TABLA DE CONTENIDO 1. Introducción 3

2. Suite H.323 3

3. Protocolos 4

3.1. Señalización RAS H.225 4

3.2. Señalización de llamada H.225 4

3.3. Control Multimedia H.245 5

3.4. Transporte Multimedia (RTP/RTCP) 7

4. Objetivos 8

5. Maqueta 8

6. Planificación 8

7. Ejecución 9

7.1. Primer Escenario ( Llamada Completada) 10

7.1.1. Establecimiento de la llamada (Fase 1) 10

7.1.2. Intercambio de Capacidades (Fase 2) 12

7.1.3. Establecimiento Comunicación de Audio (Fase 3) 14

7.1.4. Finalización llamada (Fase 4) 16

7.2. Segundo Escenario (Llamada No Contestada) 17

7.3. Tercer Escenario (Destino Ocupado) 20

7.4. Cuarto Escenario (Llamada Rechazada) 22

8. Conclusiones 24

3

1. Introducción Sustentado sobre la implantación definitiva del protocolo IP, la utilización del estándar VOIP tiene un rol más que importante al momento de definir el medio de transporte recomendado para el tráfico de voz. Sabemos que IP basa su performance en el mejor esfuerzo para entregar paquetes. Esto significa que cuando un paquete es enviado no necesariamente llega a destino y por otro lado en caso de tener una secuencia de paquetes, estos no necesariamente llegan ordenados. Existen dos protocolos dentro el stack TCP/IP, TCP y UDP siendo este último no orientado a la conexión y recomendado para aplicaciones en tiempo real. Para la transmisión de voz se hace necesario lograr un cierto nivel de calidad de servicio sobre IP, lo cual se logra a partir de distintos esquemas o modelos de QoS. Como protocolo de transporte definido tenemos a UDP por su naturaleza de tiempo real y RTP para suplir las carencias de UDP en cuento a los números de secuencia para el ordenamiento de los paquetes. Por otro lado RTP cuenta con su propio protocolo de control RTCP con el objetivo de monitorear la calidad de conexión y realizar las correcciones necesarias. Para establecer una llamada VOIP, es necesario intercambiar información adicional entre los terminales, en este aspecto uno de los suites de protocolo de control más utilizado es el H.323. 2. Suite H.323 H.323 es un protocolo estándar recomendado por la ITU-T (ITU – Telecommunication Standarization Sector) que especifica los componentes, protocolos y procedimientos para la transmisión de audio, video y datos sobre redes de conmutación de paquetes, incluyendo IP. El estándar H.323 esta formado por los siguientes componentes y protocolos: Señalización de llamada (H.225) Control Multimedia (H.245) Codecs de Audio (G.711, G.722, G.723, G729, etc) Codecs de Video (H.261, H.263) Compartir Datos (T.120) Transporte Multimedia (RTP/RTCP)

4

CALL

SIGNALING

H.225

G.711 G.722 G.723 G.728 G.729

H.261 H.263

T.120

Q.931

RAS CONTROL

H.245

H.245 CONTROL

RTP / RTCP UDP

UDP o TCP

IP

L2 (VARIOS) L1 (VARIOS)

3. Protocolos

3.1. Señalización RAS (H.225) La señalización RAS provee el control previo al establecimiento de llamadas en aquellas redes H.323 donde existe un Gatekeeper y una zona asociada. El H.225 RAS es utilizado entre Gatekeeper y terminales o endpoints con el objetivo de: - Encontrar el Gatekeeper - Registrar el Terminal o Endpoint - Localizar el Terminal o Endpoint - Control de Admisión - Información de Estado - Control de Ancho de Banda La función de señalización RAS usa un canal separado (canal RAS). Este conjunto de mensajes recibe el nombre de Registro, Admisión y Estado (Registration, Admission y Status - RAS).

3.2. Señalización de Llamada (H.225) Este protocolo de señalización de llamada esta basado sobre mensajes pertenecientes a la norma Q.931 (ITU-T). Un canal de control de llamada es creado a través de ambos extremos utilizando TCP como protocolo de transporte, y que esta asociado al puerto destino 1720. Este canal tiene el propósito de conectar, mantener y desconectar las llamadas. Estos son los mensajes Q.931 mas comúnmente utilizados:

5

SETUP: mensaje enviado por la parte llamante para el intento de conexión, Este mensaje es enviado al puerto TCP 1720. CALL PRECEEDING: mensaje enviado por el destino de la llamada hacia el origen para notificar que el procedimiento de conexión fue iniciado. ALERTING: mensaje enviado por el destino de la llamada hacia el origen para indicar que en el destino fue iniciada la señal de llamada (Ring Tone). CONNECT: mensaje enviado por el destino de la llamada hacia el origen para notificar que el destino contesto la llamada. Este mensaje contiene el protocolo TCP/UDP, el puerto y la dirección IP para el control de señalización H.245. RELEASE COMPLETE: enviado por el extremo que termina la conexión. FACILITY: mensaje Q.932 utilizado para solicitar o responder el pedido de servicios suplementarios. Es también utilizado para indicar el modo de la llamada (directo o a través de un Gatekeeper).

SETUP

TERMINAL DESTINO

TERMINAL LLAMANTE

ALERTING

CONNECT

CALL PROCEEDING

Es importante remarcar que los mensajes de señalización de llamada pueden ser manejados de dos maneras. El primer método es Señalización de llamada en Modo Directo, en el cual los mensajes de señalización de llamada son intercambiados directamente entre los Endpoints. El segundo método es Señalización de llamada mediante Gatekeeper. En este método, los mensajes de señalización de llamada son enrutados a través del Gatekeeper entre los Endpoints.

3.3. Control de Multimedia ( H.245) El Protocolo H.245 maneja los mensajes de control entre ambos extremos de la llamada. Se establecen dos canales lógicos, uno para la transmisión multimedia (audio, video y datos) y el otro para control. Cada Endpoint estable un canal contra cada Endpoint remoto con el cual tiene conexión. Para el canal de control se utiliza el protocolo de transporte TCP asignado en el último mensaje de señalización de la llamada (CONNECT). El canal de control permite el intercambio de capacidades, la apertura y el cierre de canales lógicos, modo de preferencia y control de mensajes. También cumple funciones de negociación, por ejemplo maneja en forma separada las capacidades de transmisión y recepción, como también determinara que codec utilizar.

6

El canal de Control H.245 puede estar establecido directamente entre los dos Endpoints o a través del Gatekeeper. Se puede utilizar los siguientes mensajes y procedimientos para H.245:

INTERCAMBIO DE CAPACIDADES: Consiste en los mensajes que intercambian las capacidades de dos Endpoints o Terminales. Estos mensajes indican que tipo de codificación de audio, video y protocolos de datos tienen disponibles los terminales, tanto en transmisión como en recepción DETERMINACION MAESTRO / ESCLAVO: Procedimiento para determinar que Endpoint va a actuar como maestro y cual como esclavo para una llamada en particular. Esta relación persiste durante el transcurso de la llamada y sirve para resolver posibles conflictos entre ambos extremos. ROUND TRIP DELAY: Procedimiento para determinar el retardo entre ambos extremos. El mensaje RoundTripDelayRequest sirve para medir el retardo entre ambos terminales y también para verificar el estado del otro extremo. LOGICAL CHANNEL SIGNALING: Abre y cierra los canales lógicos que llevan audio, video y datos. El canal se abre únicamente cuando ambos extremos están listos y capaces de recibir y decodificar la información entre ellos, Una vez establecido el canal lógico en forma bi-direccional, el puerto UDP para la transmisión RTP es informado para ambos extremos en el mensaje ACK asociado al Logical Channel.

7

En cuento a la terminación de llamada, cualquiera de los Endpoints puede iniciar los procedimientos de terminación respectiva. Como primer paso se debe dejar de transmitir información multimedia (audio, video) y luego cerrar todos los canales lógicos. Seguidamente se debe finalizar la sesión H.245 y enviar un RELEASE COMPLETE en el canal de señalización H.225 asociado a la llamada. En caso de contar con un Gatekeeper se enviaran los mensajes respectivos utilizados en el canal de RAS para finalizar la conexión:

3.4. Transporte Multimedia (RTP/RTCP) El protocolo RTP esta diseñado para el transporte de tráfico en tiempo real, como audio y video (multimedia) a través de redes IP con calidad y confiabilidad sin precedentes. Entre sus principales servicios se distinguen la identificación del payload, numero de secuencia, timestamp y monitoreo. Para mayor información a continuación se detalla la estructura de header asociado:

0 1 2 3 4 a 7 8 9 10 a 14 15 16 17 a 30 31 V=2 P E CC M PT Sequence Number

Timestamp

Synchronization Source (SSRC) Identifier

Contributing Source (CSRC) Identifier (Opcional)

Data (Variable)

VERSION (V): Indica la versión del protocolo (V=2) PADDING (P): Si P es igual a 1, el paquete contiene bytes adicionales para rellenar y finalizar el último paquete. EXTENSION (E): Si E es igual a 1, el encabezado está seguido de un paquete de extensión CONTRIBUTOR COUNT (CC): Contiene el número de CRSC que le sigue al encabezado MAKER (M): Especifico a la Aplicación PAYLOAD TYPE (PT): Tipo de tráfico en el campo de Datos (G.711, etc). SEQUENCE NUMBER (SN): se incrementa en uno para cada paquete enviado. TIME STAMP: Refleja el instante de muestreo del primer octeto de datos del paquete RTP. SSRC: Identifica las fuentes contribuyentes al payload de este paquete. El número de identificador es dado por el campo CC. Estos identificadores son insertados por mezcladores, usando los identificadores SSRC de las fuentes contribuyentes CSRC: Identifica las fuentes contribuyentes

El número de secuencia y la etiqueta de tiempo se usan entre las partes que se comunican para colocar el tráfico en el orden secuencial correcto, detectar tráfico pedido y sincronizar el flujo de tráfico.

8

RTCP se encarga del monitoreo del envió de los datos como también en el control e identificación de los servicios, de esta manera provee una realimentación sobre la calidad de servicio. El canal multimedia se crea utilizando el protocolo UDP donde las ráfagas RTP operan en el puerto par y el flujo RTCP asociado en el próximo puerto impar.

4. Objetivo

El objetivo del presente trabajo es establecer diferentes escenarios de llamadas VOIP/H.323 efectivizados bajo el esquema de Modo Directo, dentro el cual los mensajes de señalización y control asociados son intercambiados directamente entre los Endpoints o Terminales, sin la participación de un Gatekeeper. Identificaremos los distintos mensajes y paquetes intercambiados durante el proceso y analizaremos especialmente las fases asociadas para el caso de una llamada completada exitosamente. 5. Maqueta

6. Planificación El esquema de la practica presente se basa en la disponibilidad de dos PCs que se hallan interconectadas a través de un router inalámbrico y utilizan el rango de red privada 192.168.1.0 /24. Las PCs trabajaran como Terminales de VOIP/H.323 para lo cual tendrán instalado una aplicación Softphone, que para el presente caso es el TalkEZ (Versión 1.7.2) Para un adecuado desarrollo de las llamadas en Modo Directo H.323, se supone que los Terminales deberán estar On line, es decir activos y que la aplicación Softphone este levantada en cada uno de ellos. Se analizara el funcionamiento del protocolo Suite H.323 dentro sus diferentes fases y escenarios utilizando el analizador de paquetes WireShark (Versión 1.0.2) que estará instalado en las PCs respectivas para la captura de los paquetes.

9

7. Ejecución Para el desarrollo de las pruebas y seguimiento correspondiente se asigno al Terminal Llamante la IP 192.168.1.3 y al Terminal Destino la 192.168.1.5. Adicionalmente dentro la aplicación Softphone (TalkEZ) se procedió a deshabilitar las opciones especiales de Fast Start, H.245 Tunneling y H.245 in Setup ya que el interés del trabajo es abarcar de manera detallada todas las fases de intercambio de paquetes asociados a los diferentes escenarios.

Por otro lado para las diferentes llamadas se eligió con prioridad alta el Codec de audio G.711 Ley A (30 frames)

10

Finalmente para la ejecución del trabajo se definieron los siguientes escenarios en el contexto de una llamada Punto a Punto VOIP:

Llamada Completada (Completed ) Llamada no Contestada ( No Answer) Destino Ocupado (Busy) Llamada Rechazada ( Rejected)

7.1. Primer Escenario ( Llamada Completada ) Nos aseguramos de generar una llamada desde el Terminal 192.168.1.3 utilizando la aplicación Softphone y que la misma sea atendida por el Terminal destino, en el presente caso la 192.168.1.5

Tomando en cuenta que el presente escenario genera prácticamente la mayor cantidad de mensajes, vinculados a los diferentes protocolos pertenecientes al Suite H.323, procederemos a analizar en detalle las diferentes fases involucradas

7.1.1. Establecimiento de la Llamada (Fase 1)

Para el análisis de esta fase utilizaremos el siguiente esquema de mensajes:

11

H.225 SETUPOVER THE TCP CONNECTION

TCP - ACK

TCP- SYN-ACK

TCP SYN

TERMINAL DESTINO

TCP Port 1720

TERMINAL LLAMANTE

H.225 ALERTINGOVER THE TCP CONNETION

H.225 CONNECTOVER THE TCP CONNECTION

TCP PortP H245 - O

Fase 1

Se apertura una conexión TCP enviando un segmento con la bandera de SYN activada. A esto retorna un segmento con los flags de SYN y ACK seteados y vuelve a enviarse un segmento más con el ACK activado.

Seguidamente se manda un mensaje SETUP sobre la conexión TCP, en el que va el tipo de llamada e identificador asociado (CRV) recibiendo posteriormente el ALERTING (aparece un mensaje de llamada entrante en el Softphone) que lo envía directamente el Terminal destino. Una vez que se atiende la llamada se recibe el CONNECT. La conexión TCP anteriormente mencionada (Señalización H.225) utiliza como port destino el 1720 (Reservado) y como origen uno efímero (aquel que se encuentre libre)

12

7.1.2. Intercambio de Capacidades (Fase 2) Para el análisis de esta fase utilizaremos el siguiente esquema de mensajes:

Se abre otra conexión TCP, ya que se usa otro port para la señalización H.245, entonces se tiene que informar en que port se quiere recibir, por regla general el ultimo mensaje de la fase anterior indica en que port se recibe. En el presente caso el CONNECT informa el port TCP donde el Terminal destino desea recibir la señalización H.245. En cuento al Terminal llamante, el mismo utiliza un port efímero.

13

Posteriormente Se envía el mensaje TERMINAL CAPABILITY SET en los dos sentidos. Estos mensajes llevan los codecs soportados en orden de prioridad. Adicionalmente se aprovecha el envió del pedido para determinar quien queda como master o slave ante un posible conflicto. Estos mensajes se validan con el TERMINAL CAPABILITY SET ACK.

14

Si bien en esta fase se efectiviza el intercambio de capacidades de los terminales, la definición del codec a utilizar queda a cargo de la fase siguiente.

7.1.3. Establecimiento de Comunicación de Audio (Fase 3)

Para el análisis de esta fase utilizaremos el siguiente esquema de mensajes:

Esta asociado al establecimiento de la comunicación de audio. Entonces sobre la misma conexión TCP que se había abierto en la fase 2 para el protocolo H.245. Se envía el mensaje OPEN LOGICAL CHANNEL, mensaje utilizado para abrir un canal lógico. Los canales lógicos son unidireccionales, ósea que en una llamada de voz se aperturan 2 canales. Los mensajes de OPEN LOGICAL CHANNEL llevan un campo de Data Type que contiene el Codec que se va usar. Adicionalmente se envían parámetros de multiplexación donde se informa la dirección de transporte del Media Control Channel (RTCP).

15

Los mensajes de OPEN LOGICAL CHANNEL ACK vuelven a informar las direcciones de transporte para el Media Control Channel (Ports asociados) e incluyen finalmente el correspondiente al Media Channel (RTP) en ambos extremos. Estos son ports UDP, los mismos que en general tienen valores altos no reservados.

16

7.1.4. Finalización de la Llamada (Fase 4)

Para el análisis de esta última fase utilizaremos el siguiente esquema de mensajes:

Cualquiera de las dos partes puede terminar la llamada. Lo primero que se hace es cerrar los canales lógicos aperturados en la fase anterior. Luego se envía el comando de finalización de sesión (END SESSION COMMAND) no quedando más señalización H.245. Posteriormente se cierra el segmento TCP aperturado para el H.245 que permaneció levantado durante toda la llamada y se manda el segmento de TCP con flag de FIN.

17

Seguidamente se vuelve a retomar aquella conexión TCP abierta para la señalización H.225 asociada con el port 1720. Para finalizar se envía el mensaje RELEASE COMPLETE y luego del mismo se cierra la conexión TCP para el protocolo H.225, quedando completado de esta manera todo el proceso asociado a la llamada. Cabe mencionar que la llamada luego de ser completada satisfactoriamente es liberada con un Normal Call Clearing reportado dentro el campo Cause Value.

7.2. Segundo Escenario (Llamada No Contestada)

Generamos una llamada desde el Terminal con IP 192.168.1.3 al destino elegido, en el presente caso La PC con la IP 192.168.1.5. Nos aseguramos que la llamada no sea contestada y que del lado llamante se proceda con la finalización respectiva (Escenario de No Answer) A continuación se observa la pantalla de información recibida por la aplicación Softphone utilizada y vinculada al presente escenario:

18

De manera similar al caso anterior se levanta una conexión TCP para la señalización H.225 y envió de mensajes Q.931. Como la llamada no es contestada por el Terminal destino, no se genera el mensaje CONNECT y el Terminal Originante finaliza la señalización H.225 mediante el envió del RELEASE COMPLETE. Seguidamente se libera la conexión TCP levantada con el port destino 1720 y el proceso queda finalizado.

19

A continuación detallamos el intercambio de mensajes para el presente escenario. Se identifican los mensajes estándar Q.931 salvo el CONNECT

Confirmando la finalización de la llamada y como se menciono anteriormente el Terminal Originante envía el mensaje RELEASE COMPLETE con un Normal Call Clearing reportado por el campo Cause Value asociado.

20

7.3. Tercer Escenario (Destino Ocupado) Mediante el Softphone generamos una llamada desde el Terminal con IP 192.168.1.3 al destino que cuenta con la IP 192.168.1.5. Para asegurarnos de que el Terminal destino genere una situación de Ocupado (Busy) establecemos en paralelo un proceso de llamada de este último a un potencial tercer Terminal. A continuación se presente la pantalla de información recibida por parte de la aplicación Softphone vinculada a este escenario:

La llamada asociada al presente escenario establece como primer paso, la conexión TCP al port destino 1720 vinculado con H.225. Seguidamente se envía el mensaje SETUP, recibiendo como respuesta los mensajes CALL PROCEEDING y RELEASE COMPLETE, informando en este ultimo la no continuidad de la llamada debido a que el Terminal destino se encuentra ocupado. Finalmente se libera la sesión TCP mediante el envió de un segmento con la bandera de RST y ACK activa.

21

A continuación detallamos el intercambio de mensajes para el presente escenario. Se identifican los mensajes estándar Q.931 menos el ALERTING y CONNECT

Dentro el actual escenario el RELEASE COMPLETE es necesariamente enviado por el Terminal Destino, informando dentro el presente mensaje (campo Cause Value) que el estado actual del Terminal contactado es el de Ocupado (User Busy)

22

7.4. Cuarto Escenario ( Llamada Rechazada) Para este último escenario generamos una llamada desde el Terminal que cuenta con la IP 192.168.1.3 al Terminal con IP 192.168.1.5. Nos asegurarnos de que la llamada ingrese a destino verificando la presencia del Ring Back. A continuación rechazamos la llamada eligiendo la opción respectiva dentro la aplicación Softphone levantada en el Terminal destino y que activa esta funcionalidad.

23

De manera similar a los escenarios precedentes se confirma la apertura inicial de la conexión TCP vinculada al port destino 1720. Posteriormente se establece la señalización H.225, bajo la norma Q.931 con el envió de los mensajes SETUP, CALL PROCEEDING y ALERTING. Sin embargo una vez activada la opción de rechazo de llamada entrante por parte del Terminal destino, este último devuelve el mensaje de RELEASE COMPLETE informando el evento asociado. Para finalizar el proceso respectivo se completa el cierre de la conexión TCP levantada.

Detallamos a continuación el intercambio de mensajes para el presente escenario:

24

Para finalizar y asociado al presente escenario se identifica la Causa de Liberación reportada dentro el mensaje RELEASE COMPLETE enviado por el Terminal destino rechazando la opción de contestar la llamada entrante.

8. Conclusiones Con este laboratorio se logro observar, analizar y entender los diferentes paquetes intercambiados entre dos terminales VoIP, que establecieron una comunicación, utilizando el protocolo Suite H.323 en modo directo. En cada escenario en particular se pudo confirmar el intercambio de información prevista según los distintos protocolos involucrados