Actividad 5. SIP

 Actividad 5. SIP

1) Según el libro de la asignatura: Señala y describe las principales fechas en el desarrollo de SIP.

• Partimos en febrero de 1996: Fue cuando se presentó el protocolo SCIP (Simple Conference Invitation protocol) y que tenía objetivos parecidos a los tendría SIP.

• Diciembre de 1996: Es presentado el protocolo SIPv2 (Sesion Initation Protocol) que combinaría lo mejor del protocolo SCIP y SIP.

• Febrero de 1999: El protocolo SIPv2 se publicara como estándar por el IETF      

  Internet Engineering Task Force

  ,  en el documento que se conocería como RFC 2543 podemos echarle un vistazo en el siguiente enlace (89N3PDyZzakoH7W6n8ZrjGDDktjh8iWFG6eKRvi3kvpQ)

• Junio 2002: La organización IETF reemplazará la versión de SIP mediante un nuevo estandar que se publicó en la RFC 3261 (89N3PDyZzakoH7W6n8ZrjGDDktjh8iWFG6eKRvi3kvpQ) y esta versión es la que utilizamos hoy en día, ha sido complementada por otros fabricantes y desarrolladores a lo largo del tiempo que estandarizan algunos aspectos particulares de SIP en otras RFC´s como 2976, 3262, 3265, 3311, 3323, 3326, etc...

2) Describe en qué consisten las arquitecturas Cliente-servidor y p2p. Pon ejemplos reales y añade una imagen explicativa de cada una de ellas (puede ser un esquema creado por ti)

• Arquitectura cliente servidor:

        En una arquitectura cliente servidor nosotros, como cliente, enviaremos una petición al servidor para establecer contacto con otro usuario, es decir, que en SIP para poder establecer una comunicación con otro usuario o entre un usuaria A y un usuario B, se necesitará un servidor proxy que gestione el establecimiento de la comunicación.

Las peticiones que se envían se llaman métodos SIP y las respuestas que recibiremos siempre serán códigos numéricos que tendrán diferentes significados.

La imagen de la izquierda es una transacción SIP que es un método SIP con el conjunto de sus respuestas.

El usuario A quiere establecer una sesión SIP con B mediante una llamada de VOIP.

Para poder llevarlo a cabo se requiere una secuencia ordenada de métodos y respuestas SIP.

Esta sólo es una explicación, a grandes rasgos, de como se establece una transacción SIP, más abajo veremos un esquema de como es la arquitectura cliente servidor.

Como apunte final decir que una vez establecida la conexión entre A y B la información viajará de un usuario a otro sin pasar por el proxy.

La arquitectura cliente servidor la podríamos esquematizar de la siguiente forma:

• Arquitectura P2P (peer to peer)

Es un sistema muy complejo de usar, por ello en SIP no suele usarse. Es una arquitectura completamente opuesta a la de cliente servidor ya que en P2P no hay dos roles como en SIP, sino que hay uno y se le conoce como pear. Podemos decir que un Pear es un nodo que a la vez es cliente y servidor, dependiendo del contexto.

Un esquema de P2P podría ser el siguiente:

3) Encontrar y describir los siguientes mensajes de error SIP según su código de respuesta.

Podemos dividirlos en dos bloques, los errores 400 son errores de solicitud y los errores 500 son errores de servidor

Errores de solicitud:

a) 401: NO AUTORIZADO ya que la solicitud que enviamos requiere de una autenticación de usuario.

b) 402: PAGO REQUERIDO.

c) 404: SERVIDOR NO ENCONTRADO, el servidor tiene info definitiva de que el no existe.

Errores de Servidor:

d) 504: EXPIRACIÓN DE SERVIDOR, el servidor intentó acceder a otro servidor mientras mientras intentaba procesar un solicitud, sin éxito por no obtener respuesta a tiempo.

e) 505: VERSIÓN NO SOPORTADA, la versión del protocolo SIP en la solicitud que hemos enviado no es soportada por el servidor

4) Diagramas + leyenda

A) Estando en un escenario en el que se utilizan Registrar server + Proxy server. Realizar un diagrama de comunicación con mensajes numerados donde

• A se registra en un Registrar Server

• A Inicia una conversación con B

En la imagen de la derecha podemos ver, con un poco más de detalle, cual es la secuencia de mensajes que A inicia con el proxy y este envía a B, junto con las respuestas de B

A le dice al server que quiere establecer comunicación con B, el Server le envía la petición a B. B le responde al Server con un ACK y este se lo transmite a A y como resultado se establece la comunicación.

• A finaliza una conversación con B

Podemos ver como A inicia el proceso para finalizar la conversación con B enviando un fin directamente a B sin pasar por el proxy, ya que al estar establecida la comunicación entre A y B el envío de datos se hace directamente entre ellos sin pasar por el proxy.

1º: A le envía a B la petición de fin.

2º: B recibe esa petición de fin.

3º: B envía un ACK a A.

4º: A recibe el ACK de B.

5º: B envía fin a A.

6º: A recibe fin de B.

7º: A envía un ACK a B.

8º: B recibe el ACK de A concluyendo la comunicación entre ambos.

El diagrama debe estar acompañado de una leyenda que explique cada uno de los mensajes.

B)Repite el apartado “a” pero en un escenario con Redirect server + Registrar server.

• A se registra en un Registrar Server

Podemos ver como a través del redirect server A envía la petición de registro al servidor.

• A Inicia una conversación con B

Para poder explicar este escenario partiremos suponiendo que A y B ya están registrados en el Server.

1.- A quiere hablar con B, así que envía su “invite” al redirect server.

2.- El Redirect no conoce la Ip de B, así que se lo pregunta a Registrar Server.

3.- Registrar server le contestará a Redirect server con la dirección IP de B.

4.- Redirect le dirá la IP de B a A

5.- A y B ya podrán empezar una comunicación sin un servidor proxy de por medio, por lo que, el “invite” viajará directamente a B que actuará como UAS (servidor) y manejará la comunicación hasta que se considere “sesión establecida” y entonces B volverá a comportarse como un cliente UAC para transmitir datos.

UAS = Servidor de agente de usuario.

UAC = Control de cuentas de usuario.

• A finaliza una conversación con B

Una vez establecida la comunicación entre A y B sabemos que la información ya no para por el server, así que el proceso para finalizar la conversación será igual que en el del apartado A.

5) Describe al menos otros 2 protocolos de señalización diferentes a SIP.

• MGCP (MEDIA GATEWAY CONTROL PROTOCOL)

• CISCO SCCP (SKINNY CLIENT CONTROL PROTOCOL)

• IAX ( INTER-ASTERISK EXCHANGE)

• H.323 - UNA SUITE DE PROTOCOLOS COMO EL H.225, H.245 Y RAS QUE SE SOPORTAN EN TCP Y UDP

6) Escenario real con tramas SIP: A continuación se muestran 2 tramas que se han enviado 2 usuarios A y B usando el protocolo SIP.

Según la información que se observa:

1. Realiza un diagrama de comunicación especificando los UA y su URI

podemos ver los UA que son los agentes de usuarios y el URI que es el esquema de direccionamiento SIP para llamar a otra persona vía SIP (es el número de tlfn SIP de un usuario).

1. ¿Qué tipo de mensaje es la trama 1? ¿y la 2?

                    

•  La trama 1 es un mensaje de INVITE.

• La trama 2 es un código de respuesta Trying que significa que el invite ha sido recibido correctamente y se está tomando una acción no detallada para tratarlo, con esto se consigue que se paren las retransmisiones de los mensajes invite

1. ¿Cúal es el dominio?

• El dominio para ambas tramas es test.webrtc.es

1. ¿Qué métodos acepta el emisor?

• Los métodos que son aceptados por el emisor son: INVITE, ACK, CANCEL, OPTIONS, BYE, INFO, REFER, NOTIFY, UPDATE.

1. ¿Cuántos Bytes ocupa el cuerpo del mensaje de la Trama 1?

• Para saber los Bytes que ocupa el cuerpo del mensaje de la trama 1 hemos de fijarnos en el Content-lenght, es decir, 270 bytes.

NOTA: Todos los diagramas han sido deseñado en app.diargrams