p5.txt

Práctica 5 - Sesión SIP
Protocolos para la Transmisión de Audio y Vı́deo en Internet
Versión 8.0.1 - 6.11.2017

Ejercicios

Creación de repositorio para la práctica

1. Con el navegador, dirı́gete al repositorio ptavi-p5 en la cuenta del
profesor en GitHub1 y realiza un fork, de manera que consigas tener
una copia del repositorio en tu cuenta de GitHub. Clona el repositorio
que acabas de crear a local para poder editar los archivos. Trabaja a
partir de ahora en ese repositorio, sincronizando los cambios que vayas
realizando.

Como tarde al final de la práctica, deberás realizar un push para subir
tus cambios a tu repositorio en GitHub. En esta práctica, al contrario
que con las demás, se recomienda hacer frecuentes commits, pero el
push al final.

Análisis de una sesión SIP

Se ha capturado una sesión SIP con Ekiga (archivo sip.cap.gz), que
se puede abrir con Wireshark2 . Se pide rellenar las cuestiones que se
plantean en este guión en el fichero p5.txt que encontrarás también
en el repositorio.

2. Observa que las tramas capturadas corresponden a una sesión SIP
con Ekiga, un cliente de VoIP para GNOME. Responde a las siguientes
cuestiones:
* ¿Cuántos paquetes componen la captura?
  La captura lo componen 954 paquetes

* ¿Cuánto tiempo dura la captura?
  La captura dura 56.149345 segundos

* ¿Qué IP tiene la máquina donde se ha efectuado la captura? ¿Se
trata de una IP pública o de una IP privada? ¿Por qué lo sabes?
  La captura se ha realizado a través de la maquina con IP 192.168.1.34, lo sé gracias al descarte y es la ip que siempre se repite.
  La IP corresponde a una IP privada debido a que corresponde a las ips privadas de la versión 4 192.168.0.0 – 192.168.255.255

3. Antes de analizar las tramas, mira las estadı́sticas generales que aparecen en el menú de Statistics. En el apartado de jerarquı́a de protocolos (Protocol Hierarchy) se puede ver el porcentaje del tráfico
correspondiente al protocolo TCP y UDP.
* ¿Cuál de los dos es mayor? ¿Tiene esto sentido si estamos hablando
de una aplicación que transmite en tiempo real?
  Es mayor el protocolo UDP con un 96.2% de los paquetes frente a un 2.1% de TCP.
  Esto tiene sentido debido a que en UDP no se utilizan asentimientos ni se vuelven a reenviar los paquetes perdidos causando una gran latencia que no seria buena en comunicaciones a tiempo real.

* ¿Qué otros protocolos podemos ver en la jerarquı́a de protocolos?
¿Cuales crees que son señal y cuales ruido?
 Protocolo Ethernet, IPv4, SIP, RTP, RTCP, DNS, HTTP, ICMP, ARP y H.261
 La señal que nos interesa será los protocolos SIP, RTP, H.261, lo demás podriamos considerarlo ruido

4. Observa por encima el flujo de tramas en el menú de Statistics en IO
Graphs. La captura que estamos viendo incluye desde la inicialización
(registro) de la aplicación hasta su finalización, con una llamada entremedias.
* Filtra por sip para conocer cuándo se envı́an paquetes SIP. ¿En
qué segundos tienen lugar esos envı́os?
  tienen lugar en el intervalo 7s-8s se han enviado 6 paquetes, en el 14s-15s otros 3 paquetes, en el 16s-17s 4 paquetes, 38s-39s segundo 4 paquetes, en el segundo 39s-40s otros 4 paquetes y en el 55s-56s 4 paquetes
* Y los paquetes con RTP, ¿cuándo se envı́an?
  39 paquetes en el intervalo 17s-18s, 51 paquetes en 18s-19s, 46 paquetes 19s-20s,  20 paquetes 20s-21s, 30 paquetes 21s-22s,60 paquetes 23s-24s,70 paquetes 24s-25s, 90 paquetes 25s-26s, 49 paquetes 27s-28s,
  40 paquetes 28s-29s, 67 paquetes 29s-30s, 20 paquetes 30s-31s, 10 paquetes 31s-32s, 30 paquetes en 33s-34s, 20 paquetes en 34s-35s, 30 paquetes en 34s-36s, 10 paquetes 37s-38s y 5 paquetes en 38s-39s.

[Al terminar el ejercicio es recomendable hacer commit de los ficheros modificados]

5. Analiza las dos primeras tramas de la captura.
* ¿Qué servicio es el utilizado en estas tramas?
 Se esta utilizando DNS

* ¿Cuál es la dirección IP del servidor de nombres del ordenador
que ha lanzado Ekiga?
  La dirreción IP es 80.58.61.250

* ¿Qué dirección IP (de ekiga.net) devuelve el servicio de nombres?
  Devuelve la dirección 86.64.162.35

6. A continuación, hay más de una docena de tramas TCP/HTTP.
* ¿Podrı́as decir la URL que se está pidiendo?
  En el primer paquete HTTP con GET se pide: http://ekiga.net/ip/

* ¿Qué user agent (UA) la está pidiendo?
  Lo esta pidiendo Ekiga

* ¿Qué devuelve el servidor?
  La respuesta es 200 OK en el paquete 10 y el contenido es text/html que tiene la dirección IP 83.36.48.212

* Si lanzamos el navegador web, por ejemplo, Mozilla Firefox, y
vamos a la misma URL, ¿qué recibimos? ¿Qué es, entonces, lo
que está respondiendo el servidor?
  Recibimos 212.128.254.158 que es la IP del ordenador donde estoy trabajando, para comprobar si estoy ante mi ip privada o pública.

7. Hasta la trama 45 se puede observar una secuencia de tramas del
protocolo STUN.
* ¿Por qué se hace uso de este protocolo?
  Debido a que el servidor STUN permite a los clientes encontrar sus direcciones públicas,
  el tipo de NAT del cual ellos están atrás y el puerto Internet asociado por el NAT con el puerto local específico.
  Esta información es usada para configurar comunicación UDP entre el cliente y el proveedor VOIP para así establecer una llamada.

* ¿Podrı́as decir si estamos tras un NAT o no?
  Sí porque estamos utilizando STUN

8. La trama 46 es la primera trama SIP. En un entorno como el de Internet, lo habitual es desconocer la dirección IP de la otra parte al
realizar una llamada. Por eso, todo usuario registra su localización en
un servidor Registrar. El Registrar guarda información sobre los
usuarios en un servidor de localización que puede ser utilizado para
localizar usuarios.
* ¿Qué dirección IP tiene el servidor Registrar?
  Tiene la IP 86.64.162.35

* ¿A qué puerto (del servidor Registrar) se envı́an los paquetes
SIP?
  Se envían al puerto 5060 el puerto por defecto de SIP

* ¿Qué método SIP utiliza el UA para registrarse?
  Utiliza Method: REGISTER

* Además de REGISTER, ¿podrı́as decir qué instrucciones SIP entiende el UA?
  Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE

[Al terminar el ejercicio es recomendable hacer commit de los ficheros modificados]

9. Fijémonos en las tramas siguientes a la número 46:
* ¿Se registra con éxito en el primer intento?
  No se registra con exito ya que no esta autorizado.

* ¿Cómo sabemos si el registro se ha realizado correctamente o no?
  Lo sabemos cuando el registrar manda un 200 Ok de confirmaión

* ¿Podrı́as identificar las diferencias entre el primer intento y el
segundo de registro? (fı́jate en el tamaño de los paquetes y mira
a qué se debe el cambio)
  El segundo paquete tiene mayor tamaño debido a que manda la peticion con una cabecera de autorización

* ¿Cuánto es el valor del tiempo de expiración de la sesión? Indica
las unidades.
    Expiará a los 3600 segundos

10. Una vez registrados, podemos efectuar una llamada. Vamos a probar
con el servicio de eco de Ekiga que nos permite comprobar si nos
hemos conectado correctamente. El servicio de eco tiene la dirección
sip:500@ekiga.net. Veamos el INVITE de cerca.
* ¿Puede verse el nombre del que efectúa la llamada, ası́ como su
dirección SIP?
  Sí, From: "Gregorio Robles" <sip:grex@ekiga.net>

* ¿Qué es lo que contiene el cuerpo de la trama? ¿En qué formato/protocolo está?
  Contiene la descripción de la sesión, esta con el formato SDP

* ¿Tiene éxito el primer intento? ¿Cómo lo sabes?
  No debido a que el registrar le manda: Status-Line: SIP/2.0 407 Proxy Authentication Required
* ¿En qué se diferencia el segundo INVITE más abajo del primero?
  ¿A qué crees que se debe esto?
  La difernecia es que el tamaño del segundo INVITE es mayor debido a que manda Proxy-Authorization
  que le pedía en el primer INVITE

11. Una vez conectado, estudia el intercambio de tramas.
* ¿Qué protocolo(s) se utiliza(n)? ¿Para qué sirven estos protocolos?
  H.261, que es un estándar de compresión de vídeo, RTP,que nos permite la
 transmisión de información en tiempo real y RTCP para el envío de datos de control
  y datos de mediciones realizadas durante la transmisión

* ¿Cuál es el tamaño de paquete de los mismos?
  RTP tiene 214 bytes
  RTCP tiene 43 bytes
  H.261 varían entre 200-1080 bytes

* ¿Se utilizan bits de padding?
  no se utilizan cabecera Padding: False

* ¿Cuál es la periodicidad de los paquetes (en origen; nota que la
captura es en destino)?
  La periocidad son 20ms, debido a que sabemos que en G.711 se mandan 8000 mestras y sabemos que en cada paquete se mandan 160 bytes
  al dividirlo encontramos que mandamos 50 paquetes por segundo, entonces cada paquete se enviaran cada 20 ms.

* ¿Cuántos bits/segundo se envı́an?
  El codificador G.711 proporciona un flujo de datos de 64 Kbit/s.

[Al terminar el ejercicio es recomendable hacer commit de los ficheros modificados]

12. Vamos a ver más a fondo el intercambio RTP. En Telephony hay una
opción RTP. Empecemos mirando los flujos RTP.
* ¿Cuántos flujos hay? ¿por qué?
  Hay dos flujos debido a que se manda audio(puerto 510) y video(puerto 5014)

* ¿Cuántos paquetes se pierden?
  No se pierde nigún paquete.

* ¿Cuál es el valor máximo del delta? ¿Y qué es lo que significa el
valor de delta?
   Para el audio 1290.444ms y para el video 1290.479ms
   Es la latencia el tiempo que tarda en enviarse un paquete

* ¿Cuáles son los valores de jitter (medio y máximo)? ¿Qué
quiere decir eso? ¿Crees que estamos ante una conversación de
calidad?
  Audio(G.711) max jitter: 119.635, mean jitter:42.5
  Video(H.261) max jitter: 183.096, mean jitter:153.240
  El jitter es la variación de la latencia.
  No estanos ante una conversación de calidad debido a que no se mandan periódicamente.

13. Elige un paquete RTP de audio. Analiza el flujo de audio en Telephony
-> RTP -> Stream Analysis.
* ¿Cuánto valen el delta y el jitter para el primer paquete que
ha llegado?
 valen 0ms

* ¿Podemos saber si éste es el primer paquete que nos han enviado?
  si comprobando que su numero de secuencia que es el mas pequeño de todos o el jitter que como no tiene nada que comparar es 0.

* Los valores de jitter son menores de 10ms hasta un paquete
dado. ¿Cuál?
  Hasta el paquete 247

* ¿A qué se debe el cambio tan brusco del jitter?
  Debido a que el delta del paquete siguiente aumenta considerablemente provocando
  que la latencia varíe bastante

* ¿Es comparable el cambio en el valor de jitter con el del delta?
¿Cual es más grande?
    El jitter depende de la delta por lo tanto es comparable que los dos aumenten
    Es mas grande el cambio del delta

14. En Telephony selecciona el menú VoIP calls. Verás que se lista la
llamada de voz IP capturada en una ventana emergente. Selecciona
esa llamada y pulsa el botón Graph.
* ¿Cuánto dura la conversación?
  Dura 24.803 segundos

* ¿Cuáles son sus SSRC? ¿Por qué hay varios SSRCs? ¿Hay CSRCs?
  Video: 0x43306582
  Audio: 0xBF4AFD37
  Porque se utilizan para los dos flujos, no hay CSRCs ya que no estan mezclados los flujos

15. Identifica la trama donde se finaliza la conversación.
* ¿Qué método SIP se utiliza?
  Method: BYE

* ¿En qué trama(s)?
  En las tramas 924, 925, 927 y 933

* ¿Por qué crees que se envı́a varias veces?
  Porque al utilizar UDP no sabemos si se pierde algún paquete así que enviando varios nos aseguramos.

16. Finalmente, se cierra la aplicación de VozIP.
* ¿Por qué aparece una instrucción SIP del tipo REGISTER?
  Porque quiere eliminar su cuenta del registrar y para eso pone el expires a 0

* ¿En qué trama sucede esto?
  Sucede en el trama 950

* ¿En qué se diferencia con la instrucción que se utilizó con anterioridad (al principio de la sesión)?
  Como he dicho en el apartado anterior cambia el valor de expires a 0

[Al terminar el ejercicio es recomendable hacer commit de los ficheros modificados]

Captura de una sesión SIP

17. Dirı́gete a la web http://www.ekiga.net con el navegador y créate
una cuenta. Lanza Ekiga, y configúralo con los datos de la cuenta
que te acabas de crear. Comprueba que estás conectado (En la barra
al final de la ventana podrás ver “Connected”). Al terminar, cierra
completamente Ekiga.

18. Captura una sesión SIP de una conversación con el número SIP sip:500@ekigan.net.
Recuerda que has de comenzar a capturar tramas antes de arrancar
Ekiga para ver todo el proceso3 .

19. Observa las diferencias en el inicio de la conversación entre el entorno
del laboratorio y el del ejercicio anterior4 :
* ¿Se utilizan DNS y STUN? ¿Por qué?
  Sólo se utiliza DNS para saber el nombre de la máquina, no se utiliza el
  STUN debido a que ya nos encontramos en una ip pública.

* ¿Son diferentes el registro y la descripción de la sesión?
  No son diferentes, cambia el nombre sip unicamente.

20. Identifica las diferencias existentes entre esta conversación y la conversación anterior:
* ¿Cuántos flujos tenemos?
  Tenemos dos flujos de audio(speex)

* ¿Cuál es su periodicidad?
  Observando la I/O Graph vemos que de los flujos se estan enviando 50 paquetes por segundo por lo tanto cada paquete se enviara cada 20ms

* ¿Cuánto es el valor máximo del delta y los valores medios y
máximo del jitter?
  Flujo enviado por 212.79.111.155 Max Delta: 28.049ms, Max Jitter: 1.825ms y Mean Jitter: 0.855ms
  Flujo enviado por 212.128.255.18 Max Delta: 41.993ms, Max Jitter: 13.065ms y Mean Jitter: 12.413ms

* ¿Podrı́as reproducir la conversación desde Wireshark? ¿Cómo?
Comprueba que poniendo un valor demasiado pequeño para el
buffer de jitter, la conversación puede no tener la calidad necesaria.
  Si se podría reproducir en Telephony, luego en VoIP calls y pulsando la conversación que queremos y en Play Streams.

* ¿Sabrı́as decir qué tipo de servicio ofrece sip:500@ekiga.net?
  Prueba de eco, admite video (H261, H263-1998, H264 solamente, en este orden), así como audio (solo PCMA) - el sonido y el video son de baja calidad

[Al terminar el ejercicio es recomendable hacer commit de los ficheros modificados]


21. Filtra por los paquetes SIP de la captura y guarda únicamente los
paquetes SIP como p5.pcapng. Abre el fichero guardado para cerciorarte de que lo has hecho bien. Deberás añadirlo al repositorio.
[Al terminar el ejercicio es recomendable hacer commit de los ficheros modificados]
[Al terminar la práctica, realiza un push para sincronizar tu repositorio GitHub]