LABORATORIO TCP/IP

LUIS ALFONSO PEREZ AMAYA VICTOR HUGO DE LA FUENTE

MAESTRIA EN INGENERIA DE TELECOMUNICACIONES UNIVERSIDAD DE BUENOS AIRES - EGRIET

2008

TABLA DE CONTENIDO

1. Introduccin 2. Suite H.323 3. Protocolos 3.1. Sealizacin RAS H.225 3.2. Sealizacin de llamada H.225 3.3. Control Multimedia H.245 3.4. Transporte Multimedia (RTP/RTCP) 4. Objetivos 5. Maqueta 6. Planificacin 7. Ejecucin 7.1. Primer Escenario ( Llamada Completada) 7.1.1. Establecimiento de la llamada (Fase 1) 7.1.2. Intercambio de Capacidades (Fase 2) 7.1.3. Establecimiento Comunicacin de Audio (Fase 3) 7.1.4. Finalizacin llamada (Fase 4) 7.2.Segundo Escenario (Llamada No Contestada) 7.3.Tercer Escenario (Destino Ocupado) 7.4.Cuarto Escenario (Llamada Rechazada) 8. Conclusiones

3 3 4 4 4 5 7 8 8 8 9 10 10 12 14 16 17 20 22 24

1. Introduccin Sustentado sobre la implantacin definitiva del protocolo IP, la utilizacin del estndar VOIP tiene un rol ms que importante al momento de definir el medio de transporte recomendado para el trfico 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 conexin y recomendado para aplicaciones en tiempo real. Para la transmisin 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 nmeros 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 conexin y realizar las correcciones necesarias. Para establecer una llamada VOIP, es necesario intercambiar informacin adicional entre los terminales, en este aspecto uno de los suites de protocolo de control ms utilizado es el H.323. 2. Suite H.323 H.323 es un protocolo estndar recomendado por la ITU-T (ITU Telecommunication Standarization Sector) que especifica los componentes, protocolos y procedimientos para la transmisin de audio, video y datos sobre redes de conmutacin de paquetes, incluyendo IP. El estndar H.323 esta formado por los siguientes componentes y protocolos: Sealizacin de llamada Control Multimedia Codecs de Audio Codecs de Video Compartir Datos Transporte Multimedia (H.225) (H.245) (G.711, G.722, G.723, G729, etc) (H.261, H.263) (T.120) (RTP/RTCP)

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

CALL H.261 H.263 T.120

SIGNALIN G

H.225 Q.931

RAS CONTROL H.245

H.245 CONTROL

RTP / RTCP UDP IP L2 (VARIOS) L1 (VARIOS)

UDP o TCP

3. Protocolos 3.1. Sealizacin RAS (H.225) La sealizacin 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 Admisin - Informacin de Estado - Control de Ancho de Banda La funcin de sealizacin RAS usa un canal separado (canal RAS). Este conjunto de mensajes recibe el nombre de Registro, Admisin y Estado (Registration, Admission y Status - RAS). 3.2. Sealizacin de Llamada (H.225) Este protocolo de sealizacin de llamada esta basado sobre mensajes pertenecientes a la norma Q.931 (ITU-T). Un canal de control de llamada es creado a travs de ambos extremos utilizando TCP como protocolo de transporte, y que esta asociado al puerto destino 1720. Este canal tiene el propsito de conectar, mantener y desconectar las llamadas. Estos son los mensajes Q.931 mas comnmente utilizados:

SETUP: mensaje enviado por la parte llamante para el intento de conexin, 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 conexin fue iniciado. ALERTING: mensaje enviado por el destino de la llamada hacia el origen para indicar que en el destino fue iniciada la seal 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 direccin IP para el control de sealizacin H.245. RELEASE COMPLETE: enviado por el extremo que termina la conexin. FACILITY: mensaje Q.932 utilizado para solicitar o responder el pedido de servicios suplementarios. Es tambin utilizado para indicar el modo de la llamada (directo o a travs de un Gatekeeper).

TERMINAL LLAMANTE SETUP

TERMINAL DESTINO

CALL PROCEEDING ALERTING CONNECT

Es importante remarcar que los mensajes de sealizacin de llamada pueden ser manejados de dos maneras. El primer mtodo es Sealizacin de llamada en Modo Directo, en el cual los mensajes de sealizacin de llamada son intercambiados directamente entre los Endpoints. El segundo mtodo es Sealizacin de llamada mediante Gatekeeper. En este mtodo, los mensajes de sealizacin de llamada son enrutados a travs 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 lgicos, uno para la transmisin multimedia (audio, video y datos) y el otro para control. Cada Endpoint estable un canal contra cada Endpoint remoto con el cual tiene conexin. Para el canal de control se utiliza el protocolo de transporte TCP asignado en el ltimo mensaje de sealizacin de la llamada (CONNECT). El canal de control permite el intercambio de capacidades, la apertura y el cierre de canales lgicos, modo de preferencia y control de mensajes. Tambin cumple funciones de negociacin, por ejemplo maneja en forma separada las capacidades de transmisin y recepcin, como tambin determinara que codec utilizar. 5

El canal de Control H.245 puede estar establecido directamente entre los dos Endpoints o a travs 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 codificacin de audio, video y protocolos de datos tienen disponibles los terminales, tanto en transmisin como en recepcin DETERMINACION MAESTRO / ESCLAVO: Procedimiento para determinar que Endpoint va a actuar como maestro y cual como esclavo para una llamada en particular. Esta relacin 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 tambin para verificar el estado del otro extremo. LOGICAL CHANNEL SIGNALING: Abre y cierra los canales lgicos que llevan audio, video y datos. El canal se abre nicamente cuando ambos extremos estn listos y capaces de recibir y decodificar la informacin entre ellos, Una vez establecido el canal lgico en forma bi-direccional, el puerto UDP para la transmisin RTP es informado para ambos extremos en el mensaje ACK asociado al Logical Channel.

En cuento a la terminacin de llamada, cualquiera de los Endpoints puede iniciar los procedimientos de terminacin respectiva. Como primer paso se debe dejar de transmitir informacin multimedia (audio, video) y luego cerrar todos los canales lgicos. Seguidamente se debe finalizar la sesin H.245 y enviar un RELEASE COMPLETE en el canal de sealizacin 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 conexin: 3.4. Transporte Multimedia (RTP/RTCP) El protocolo RTP esta diseado para el transporte de trfico en tiempo real, como audio y video (multimedia) a travs de redes IP con calidad y confiabilidad sin precedentes. Entre sus principales servicios se distinguen la identificacin del payload, numero de secuencia, timestamp y monitoreo. Para mayor informacin a continuacin se detalla la estructura de header asociado:

0 1 2 3 V=2 P E

4a7 CC

8 9 10 a 14 15 16 M PT Timestamp

17 a 30 Sequence Number

31

Synchronization Source (SSRC) Identifier Contributing Source (CSRC) Identifier (Opcional) Data (Variable)

VERSION (V): Indica la versin 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 extensin CONTRIBUTOR COUNT (CC): Contiene el nmero de CRSC que le sigue al encabezado MAKER (M): Especifico a la Aplicacin PAYLOAD TYPE (PT): Tipo de trfico 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 nmero 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 nmero de secuencia y la etiqueta de tiempo se usan entre las partes que se comunican para colocar el trfico en el orden secuencial correcto, detectar trfico pedido y sincronizar el flujo de trfico.

RTCP se encarga del monitoreo del envi de los datos como tambin en el control e identificacin de los servicios, de esta manera provee una realimentacin sobre la calidad de servicio. El canal multimedia se crea utilizando el protocolo UDP donde las rfagas RTP operan en el puerto par y el flujo RTCP asociado en el prximo 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 sealizacin y control asociados son intercambiados directamente entre los Endpoints o Terminales, sin la participacin 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. Planificacin El esquema de la practica presente se basa en la disponibilidad de dos PCs que se hallan interconectadas a travs de un router inalmbrico y utilizan el rango de red privada 192.168.1.0 /24. Las PCs trabajaran como Terminales de VOIP/H.323 para lo cual tendrn instalado una aplicacin Softphone, que para el presente caso es el TalkEZ (Versin 1.7.2) Para un adecuado desarrollo de las llamadas en Modo Directo H.323, se supone que los Terminales debern estar On line, es decir activos y que la aplicacin 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 (Versin 1.0.2) que estar instalado en las PCs respectivas para la captura de los paquetes. 8

7. Ejecucin 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 aplicacin Softphone (TalkEZ) se procedi a deshabilitar las opciones especiales de Fast Start, H.245 Tunneling y H.245 in Setup ya que el inters 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)

Finalmente para la ejecucin 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 aplicacin 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 prcticamente 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 anlisis de esta fase utilizaremos el siguiente esquema de mensajes:

10

TERMINAL LLAMANTE TCP SYN

TCP Port
P H245 - O

TERMINAL DESTINO

TCP- SYN-ACK TCP - ACK

TCP Port 1720

Fase 1 H.225 SETUP

OVER THE TCP CONNECTION

H.225 ALERTING
OVER THE TCP CONNETION

H.225 CONNECT
OVER THE TCP CONNECTION

Se apertura una conexin 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 ms con el ACK activado.

Seguidamente se manda un mensaje SETUP sobre la conexin 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 enva directamente el Terminal destino. Una vez que se atiende la llamada se recibe el CONNECT. La conexin TCP anteriormente mencionada (Sealizacin H.225) utiliza como port destino el 1720 (Reservado) y como origen uno efmero (aquel que se encuentre libre)

11

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

Se abre otra conexin TCP, ya que se usa otro port para la sealizacin 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 sealizacin H.245. En cuento al Terminal llamante, el mismo utiliza un port efmero.

12

Posteriormente Se enva 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.

13

Si bien en esta fase se efectiviza el intercambio de capacidades de los terminales, la definicin del codec a utilizar queda a cargo de la fase siguiente. 7.1.3. Establecimiento de Comunicacin de Audio (Fase 3) Para el anlisis de esta fase utilizaremos el siguiente esquema de mensajes:

Esta asociado al establecimiento de la comunicacin de audio. Entonces sobre la misma conexin TCP que se haba abierto en la fase 2 para el protocolo H.245. Se enva el mensaje OPEN LOGICAL CHANNEL, mensaje utilizado para abrir un canal lgico. Los canales lgicos 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 envan parmetros de multiplexacin donde se informa la direccin de transporte del Media Control Channel (RTCP).

14

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.

15

7.1.4. Finalizacin de la Llamada (Fase 4) Para el anlisis 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 lgicos aperturados en la fase anterior. Luego se enva el comando de finalizacin de sesin (END SESSION COMMAND) no quedando ms sealizacin 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.

16

Seguidamente se vuelve a retomar aquella conexin TCP abierta para la sealizacin H.225 asociada con el port 1720. Para finalizar se enva el mensaje RELEASE COMPLETE y luego del mismo se cierra la conexin 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 finalizacin respectiva (Escenario de No Answer) A continuacin se observa la pantalla de informacin recibida por la aplicacin Softphone utilizada y vinculada al presente escenario:

17

De manera similar al caso anterior se levanta una conexin TCP para la sealizacin 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 sealizacin H.225 mediante el envi del RELEASE COMPLETE. Seguidamente se libera la conexin TCP levantada con el port destino 1720 y el proceso queda finalizado.

18

A continuacin detallamos el intercambio de mensajes para el presente escenario. Se identifican los mensajes estndar Q.931 salvo el CONNECT

Confirmando la finalizacin de la llamada y como se menciono anteriormente el Terminal Originante enva el mensaje RELEASE COMPLETE con un Normal Call Clearing reportado por el campo Cause Value asociado.

19

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 situacin de Ocupado (Busy) establecemos en paralelo un proceso de llamada de este ltimo a un potencial tercer Terminal. A continuacin se presente la pantalla de informacin recibida por parte de la aplicacin Softphone vinculada a este escenario:

La llamada asociada al presente escenario establece como primer paso, la conexin TCP al port destino 1720 vinculado con H.225. Seguidamente se enva 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 sesin TCP mediante el envi de un segmento con la bandera de RST y ACK activa.

20

A continuacin detallamos el intercambio de mensajes para el presente escenario. Se identifican los mensajes estndar 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)

21

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 continuacin rechazamos la llamada eligiendo la opcin respectiva dentro la aplicacin Softphone levantada en el Terminal destino y que activa esta funcionalidad.

22

De manera similar a los escenarios precedentes se confirma la apertura inicial de la conexin TCP vinculada al port destino 1720. Posteriormente se establece la sealizacin H.225, bajo la norma Q.931 con el envi de los mensajes SETUP, CALL PROCEEDING y ALERTING. Sin embargo una vez activada la opcin 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 conexin TCP levantada.

Detallamos a continuacin el intercambio de mensajes para el presente escenario:

23

Para finalizar y asociado al presente escenario se identifica la Causa de Liberacin reportada dentro el mensaje RELEASE COMPLETE enviado por el Terminal destino rechazando la opcin 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 comunicacin, utilizando el protocolo Suite H.323 en modo directo. En cada escenario en particular se pudo confirmar el intercambio de informacin prevista segn los distintos protocolos involucrados

24