<commit_before> 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 (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? -> 954
 ** ¿Cuánto tiempo dura la captura? -> 56.149 s
 ** ¿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? -> Pienso que se ha tenido que hacer en la dirección 192.168.1.34 o en un router NAT que conecte a las tres máquinas o en cualquier maquina que tenga visibilidad del resto de máquinas. (IP pública)


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? ¿Es esto consistente con una aplicación que transmite en tiempo real? UDP(96.23% paquetes) es mayor frente a TCP(2.10% paquetes). Sí.

 ** ¿Qué otros protocolos podemos ver en la jerarquía de protocolos? En IPv4(TCP -> HTTP e ICMP, UDP -> DNS, STUTN, SIP, RTP, RTCP) y ARP

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? 7.34s, 14.42s, 16.23s, 38.11s, 55.69s.
 ** Y los paquetes con RTP, ¿cuándo se envían? 17.16s a 21.8302s y 21.8303s a 38.11s


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

5. Analiza las primeras cuatro tramas de la captura nada más arrancar Ekiga.
 ** ¿Qué servicio es el utilizado en estas tramas? ekiga.net
 ** ¿Cuál es la dirección IP del servidor de nombres del ordenador que ha lanzado Ekiga? 172.16.31.10
 ** ¿Qué dirección IP (de ekiga.net) devuelve el servicio de nombres? 172.16.58.3
 ** ¿Por qué se pide también para 35.162.64.86.in-addr.arpa? Porque quiere saber el dominio por defecto para esa dirección, eso lo vemos con direccion.in-addr.arpa: type PTR


6. A continuación, hay más de una docena de tramas TCP/HTTP.
 ** ¿Podrías decir la URL que se está pidiendo? http://ekiga.net/ip/
 ** ¿Qué user agent (UA) la está pidiendo? Ekiga
 ** ¿Qué devuelve el servidor? 192.168.127.12 (dirección pública)
 ** 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 192.168.3.11. El servidor nos da la dirección ip pública


7. Hasta la trama 45 se puede observar una secuencia de tramas del protocolo STUN. ··············································
 ** ¿Por qué crees que se hace uso de este protocolo en esta captura? Busca en la Wikipedia.
 ** ¿Estamos tras un NAT?


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? 172.16.58.3
 ** ¿A qué puerto (del servidor Registrar) se envían los paquetes SIP? 5060
 ** ¿Qué método SIP utiliza el UA para registrarse? REGISTER
 ** Además de REGISTER, ¿qué instrucciones SIP entiende el UA? 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
 ** ¿Cómo sabemos si el registro se ha realizado correctamente o no? Según la cabecera de la trama "401 Unauthorized"
 ** ¿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) En el primer intento no le deja efectuar el registro y le pide que lo realice mediante "Digest", en el segundo intento lo realiza mediante este método y le responde un "200 OK"
 ** ¿Cuánto es el valor del tiempo de expiración de la sesión? Indica las unidades. 3600s


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:50<EMAIL>. Veamos el INVITE de cerca.
 ** ¿Puede verse el nombre del que efectúa la llamada, así como su dirección SIP? Si, <NAME>, sip: <EMAIL>
 ** ¿Qué es lo que contiene el cuerpo de la trama? ¿En qué formato/protocolo está? Contiene información de propietario, informacion de conexioón, tiempo, media, direccion y atributos. Protocolo: SDP
 ** ¿Tiene éxito el primer intento? ¿Cómo lo sabes? No, ya que nos pide autenticación de proxy, "407 Proxy Authentication Required"
 ** ¿En qué se diferencia el segundo INVITE más abajo del primero? ¿A qué crees que se debe esto? En que añade el campo "Proxy-Authenrization"


11. Una vez conectado, estudia el intercambio de tramas.
 ** ¿Qué protocolo(s) se utiliza(n)? ¿Para qué sirven estos protocolos? Se utilizan RTP (para transmisión multimedia a tiempo real) y H-261 (para el video) 
 ** ¿Cuál es el tamaño de paquete de los mismos? Paquetes RTP -> 214 bytes, Paquetes H-261 -> 1028,1073,1037,1077 bytes
 ** ¿Se utilizan bits de padding? No. Se observa en el campo Padding: False. 
 ** ¿Cuál es la periodicidad de los paquetes que se envían? es de 20 microsegundos aprox.
 ** ¿Cuántos bits/segundo estamos enviando? Enviamos 64000bits/seg



[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é? Existen dos flujos, ya que se transmiten dos tipos de ficheros distintos, audio y video.
 ** ¿Cuántos paquetes se pierden? No se pierde ningún paquete.
 ** ¿Cuál es el valor máximo del delta? ¿Y qué es lo que significa el valor de delta? En ambos flujos tiene un valor de 1290.48 ms aprox. Este valor equivale al retardo de los paquetes.
 ** ¿Cuáles son los valores de jitter (medio y máximo)? ¿Qué quiere decir eso? ¿Estamos ante una conversación de calidad? 
    En flujo de vídeo:                          En flujo de audio:
        -> jitter medio: 153.24 ms                  -> jitter medio: 42.50 ms 
        -> jitter máximo: 183.10 ms                 -> jitter máximo: 119.64 ms
    No es una conversacion de calidad, ya que los valores jitter no son buenos, tiene demasiada variación y la diferencia de retardos es elevada.

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? Ambos tienen valor 0.
 ** ¿Podemos saber si éste es el primer paquete que nos han enviado? Si, ya que el valor que toma el campo Marker.
 ** Los valores de jitter son menores de 10ms hasta un paquete dado. ¿Cuál? El paquete al que se hace referencia es el número 247. Apartir de este paquete los valores de jitter seran superiores a 10ms.
 ** ¿A qué se debe el cambio tan brusco del jitter? Se debe al cambio de retardo, este es muy brusco, lo que hace que cambie el valor de jitter.
 ** ¿Es comparable este cambio con el tiempo desde la recepción del paquete anterior? ¿Por qué? Si, porque hay un cambio brusco en el retardo con respecto al paquete anterior.
 ** ¿Cuál es la dependencia entre el tiempo transcurrido desde el paquete anterior y el valor de jitter?
     La dependencia está en la variabilidad de dicho retardo.

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? Obtenemos este valor restando los campos Stop Time - Start Time = 39.22.9683 - 14.426793 = 24.80289
 ** ¿Cuáles son sus SSRC? ¿Por qué hay varios SSRCs? ¿Hay CSRCs? Tenemos dos valores se SSRC, uno para el flujo de audio y otro para el de video. No encontramos ninún CSRC, lo podemos ver en el campo "Contributing Source Identifiers Count = 0"


15. Identifica la trama donde se finaliza la conversación.
 ** ¿Qué método SIP se utiliza? Uitliza el método Request, "BYE".
 ** ¿En qué trama(s)? 924,925,927 y 933.
 ** ¿Por qué crees que se envía varias veces? Se envia varias veces ya que no se recibe una trama con el método 200 OK.


16. Finalmente, se cierra la aplicación de VozIP.
 ** ¿Por qué aparece una instrucción SIP del tipo REGISTER? Aparece para dar de baja al usuario (Expires = 0), y que el servidor le borre de la lista.
 ** ¿En qué trama sucede esto? En la trama 950 y 952.
 ** ¿En qué se diferencia con la instrucción que se utilizó con anterioridad (al principio de la sesión)? Se diferencia en el valor del campo Expires, al inicio de la sesión tiene un valor de 3600 y al final tiene valor de 0.



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

================================================================================
================================================================================

Captura de una sesión SIP

Captura una sesión SIP de una conversación con el número SIP sip:999<EMAIL>. Tendrás que dar de alta una cuenta en www.ekiga.net con el navegador. Recuerda también que has de comenzar a capturar tramas antes de arrancar Ekiga para ver todo el proceso en el que participa SIP. Para realizar los siguientes ejercicios, deberás crearte una cuenta en ekiga.net y darte de alta la lanzar la aplicación.

17. Observa las diferencias en el inicio de la conversación entre el entorno del laboratorio y el del ejercicio anterior:
 ** ¿Es necesario el uso de DNS y STUN? ¿Por qué? Si es necesario tanto el uso de DNS como el de STUN, DNS para la asignacion de nombres de dominio IP y STUN para conocer nuestra IP pública.
 ** ¿Son diferentes el registro y la descripción de la sesión?
No, son iguales.

18. Identifica las diferencias existentes entre esta conversación y la conversación anterior:
 ** ¿Cuántos flujos tenemos? Tenemos dos flujos ambos de audio, ya que es una conversación.
 ** ¿Cuál es su periodicidad? cada 0.2 segundos
 ** ¿Cuánto es el valor máximo del delta y los valores medios y máximo del jitter?
 En primer flujo (Port: 30984):                          En segundo flujo (Port: 5062):
        -> jitter medio: 19.90 ms                            -> jitter medio: 37.01 ms 
        -> jitter máximo: 19.29 ms                           -> jitter máximo: 48.81 ms
        -> delta máximo: 4.09 ms                             -> delta máximo: 324.26 ms
 ** ¿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.
 Telephony -> RTP -> Show all Streams -> Selecionar un flujo -> Analyze -> Player (Se cierra automaticamente Wireshark, por lo que no llego a reproducirlo)
 ** ¿Sabrías decir qué tipo de servicio ofrece sip:9999@qxip.<EMAIL>? Servicio de audio



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

19. Filtra por los paquetes SIP de la captura y guarda únicamente los paquetes SIP como sip.libpcap. Abre el fichero guardado para cerciorarte de que lo has hecho bien. Deberás guardarlo en un archivo de nombre p5.libpcap y 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]

[Recuerda mirar el guión para ver las instrucciones de entrega]
<commit_msg>Corregido fallo<commit_after> 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 (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? -> 954
 ** ¿Cuánto tiempo dura la captura? -> 56.149 s
 ** ¿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? -> Pienso que se ha tenido que hacer en la dirección 192.168.1.34 o en un router NAT que conecte a las tres máquinas o en cualquier maquina que tenga visibilidad del resto de máquinas. (IP pública)


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? ¿Es esto consistente con una aplicación que transmite en tiempo real? UDP(96.23% paquetes) es mayor frente a TCP(2.10% paquetes). Sí.

 ** ¿Qué otros protocolos podemos ver en la jerarquía de protocolos? En IPv4(TCP -> HTTP e ICMP, UDP -> DNS, STUTN, SIP, RTP, RTCP) y ARP

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? 7.34s, 14.42s, 16.23s, 38.11s, 55.69s.
 ** Y los paquetes con RTP, ¿cuándo se envían? 17.16s a 21.8302s y 21.8303s a 38.11s


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

5. Analiza las primeras cuatro tramas de la captura nada más arrancar Ekiga.
 ** ¿Qué servicio es el utilizado en estas tramas? ekiga.net
 ** ¿Cuál es la dirección IP del servidor de nombres del ordenador que ha lanzado Ekiga? 172.16.31.10
 ** ¿Qué dirección IP (de ekiga.net) devuelve el servicio de nombres? 172.16.58.3
 ** ¿Por qué se pide también para 172.16.31.10.in-addr.arpa? Porque quiere saber el dominio por defecto para esa dirección, eso lo vemos con direccion.in-addr.arpa: type PTR


6. A continuación, hay más de una docena de tramas TCP/HTTP.
 ** ¿Podrías decir la URL que se está pidiendo? http://ekiga.net/ip/
 ** ¿Qué user agent (UA) la está pidiendo? Ekiga
 ** ¿Qué devuelve el servidor? 192.168.127.12 (dirección pública)
 ** 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 192.168.3.11. El servidor nos da la dirección ip pública


7. Hasta la trama 45 se puede observar una secuencia de tramas del protocolo STUN. 
 ** ¿Por qué crees que se hace uso de este protocolo en esta captura? Busca en la Wikipedia.
Es un protocolo de red del tipo cliente/servidor que permite a clientes NAT encontrar su dirección IP pública, el tipo de NAT en el que se encuentra y el puerto de Internet asociado con el puerto local a través de NAT. Esta información es usada para configurar una comunicación UDP entre dos hosts que se encuentren tras enrutadores NAT.
 ** ¿Estamos tras un NAT? Si.


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? 172.16.58.3
 ** ¿A qué puerto (del servidor Registrar) se envían los paquetes SIP? 5060
 ** ¿Qué método SIP utiliza el UA para registrarse? REGISTER
 ** Además de REGISTER, ¿qué instrucciones SIP entiende el UA? 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
 ** ¿Cómo sabemos si el registro se ha realizado correctamente o no? Según la cabecera de la trama "401 Unauthorized"
 ** ¿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) En el primer intento no le deja efectuar el registro y le pide que lo realice mediante "Digest", en el segundo intento lo realiza mediante este método y le responde un "200 OK"
 ** ¿Cuánto es el valor del tiempo de expiración de la sesión? Indica las unidades. 3600s


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:<EMAIL>. Veamos el INVITE de cerca.
 ** ¿Puede verse el nombre del que efectúa la llamada, así como su dirección SIP? Si, <NAME>, sip: <EMAIL>
 ** ¿Qué es lo que contiene el cuerpo de la trama? ¿En qué formato/protocolo está? Contiene información de propietario, informacion de conexioón, tiempo, media, direccion y atributos. Protocolo: SDP
 ** ¿Tiene éxito el primer intento? ¿Cómo lo sabes? No, ya que nos pide autenticación de proxy, "407 Proxy Authentication Required"
 ** ¿En qué se diferencia el segundo INVITE más abajo del primero? ¿A qué crees que se debe esto? En que añade el campo "Proxy-Authenrization"


11. Una vez conectado, estudia el intercambio de tramas.
 ** ¿Qué protocolo(s) se utiliza(n)? ¿Para qué sirven estos protocolos? Se utilizan RTP (para transmisión multimedia a tiempo real) y H-261 (para el video) 
 ** ¿Cuál es el tamaño de paquete de los mismos? Paquetes RTP -> 214 bytes, Paquetes H-261(video) -> 1028,1073,1037,1077 bytes
 ** ¿Se utilizan bits de padding? No. Se observa en el campo Padding: False. 
 ** ¿Cuál es la periodicidad de los paquetes que se envían? es de 20 microsegundos aprox.
 ** ¿Cuántos bits/segundo estamos enviando? Enviamos 64000bits/seg



[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é? Existen dos flujos, ya que se transmiten dos tipos de ficheros distintos, audio y video.
 ** ¿Cuántos paquetes se pierden? No se pierde ningún paquete.
 ** ¿Cuál es el valor máximo del delta? ¿Y qué es lo que significa el valor de delta? En ambos flujos tiene un valor de 1290.48 ms aprox. Este valor equivale al retardo de los paquetes.
 ** ¿Cuáles son los valores de jitter (medio y máximo)? ¿Qué quiere decir eso? ¿Estamos ante una conversación de calidad? 
    En flujo de vídeo:                          En flujo de audio:
        -> jitter medio: 153.24 ms                  -> jitter medio: 42.50 ms 
        -> jitter máximo: 183.10 ms                 -> jitter máximo: 119.64 ms
    No es una conversacion de calidad, ya que los valores jitter no son buenos, tiene demasiada variación y la diferencia de retardos es elevada.

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? Ambos tienen valor 0.
 ** ¿Podemos saber si éste es el primer paquete que nos han enviado? Si, ya que el valor que toma el campo Marker.
 ** Los valores de jitter son menores de 10ms hasta un paquete dado. ¿Cuál? El paquete al que se hace referencia es el número 247. Apartir de este paquete los valores de jitter seran superiores a 10ms.
 ** ¿A qué se debe el cambio tan brusco del jitter? Se debe al cambio de retardo, este es muy brusco, lo que hace que cambie el valor de jitter.
 ** ¿Es comparable este cambio con el tiempo desde la recepción del paquete anterior? ¿Por qué? Si, porque hay un cambio brusco en el retardo con respecto al paquete anterior.
 ** ¿Cuál es la dependencia entre el tiempo transcurrido desde el paquete anterior y el valor de jitter?
     La dependencia está en la variabilidad de dicho retardo.

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? Obtenemos este valor restando los campos Stop Time - Start Time = 39.22.9683 - 14.426793 = 24.80289
 ** ¿Cuáles son sus SSRC? ¿Por qué hay varios SSRCs? ¿Hay CSRCs? Tenemos dos valores se SSRC, uno para el flujo de audio y otro para el de video. No encontramos ninún CSRC, lo podemos ver en el campo "Contributing Source Identifiers Count = 0"


15. Identifica la trama donde se finaliza la conversación.
 ** ¿Qué método SIP se utiliza? Uitliza el método Request, "BYE".
 ** ¿En qué trama(s)? 924,925,927 y 933.
 ** ¿Por qué crees que se envía varias veces? Se envia varias veces ya que no se recibe una trama con el método 200 OK.


16. Finalmente, se cierra la aplicación de VozIP.
 ** ¿Por qué aparece una instrucción SIP del tipo REGISTER? Aparece para dar de baja al usuario (Expires = 0), y que el servidor le borre de la lista.
 ** ¿En qué trama sucede esto? En la trama 950 y 952.
 ** ¿En qué se diferencia con la instrucción que se utilizó con anterioridad (al principio de la sesión)? Se diferencia en el valor del campo Expires, al inicio de la sesión tiene un valor de 3600 y al final tiene valor de 0.



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

================================================================================
================================================================================

Captura de una sesión SIP

Captura una sesión SIP de una conversación con el número SIP sip:9999@qx<EMAIL>. Tendrás que dar de alta una cuenta en www.ekiga.net con el navegador. Recuerda también que has de comenzar a capturar tramas antes de arrancar Ekiga para ver todo el proceso en el que participa SIP. Para realizar los siguientes ejercicios, deberás crearte una cuenta en ekiga.net y darte de alta la lanzar la aplicación.

17. Observa las diferencias en el inicio de la conversación entre el entorno del laboratorio y el del ejercicio anterior:
 ** ¿Es necesario el uso de DNS y STUN? ¿Por qué? Si es necesario tanto el uso de DNS como el de STUN, DNS para la asignacion de nombres de dominio IP y STUN para conocer nuestra IP pública.
 ** ¿Son diferentes el registro y la descripción de la sesión?
No, son iguales.

18. Identifica las diferencias existentes entre esta conversación y la conversación anterior:
 ** ¿Cuántos flujos tenemos? Tenemos dos flujos ambos de audio, ya que es una conversación.
 ** ¿Cuál es su periodicidad? cada 0.2 segundos
 ** ¿Cuánto es el valor máximo del delta y los valores medios y máximo del jitter?
 En primer flujo (Port: 30984):                          En segundo flujo (Port: 5062):
        -> jitter medio: 19.90 ms                            -> jitter medio: 37.01 ms 
        -> jitter máximo: 19.29 ms                           -> jitter máximo: 48.81 ms
        -> delta máximo: 4.09 ms                             -> delta máximo: 324.26 ms
 ** ¿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.
 Telephony -> RTP -> Show all Streams -> Selecionar un flujo -> Analyze -> Player (Se cierra automaticamente Wireshark, por lo que no llego a reproducirlo)
 ** ¿Sabrías decir qué tipo de servicio ofrece sip:999<EMAIL>? Servicio de audio



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

19. Filtra por los paquetes SIP de la captura y guarda únicamente los paquetes SIP como sip.libpcap. Abre el fichero guardado para cerciorarte de que lo has hecho bien. Deberás guardarlo en un archivo de nombre p5.libpcap y 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]

[Recuerda mirar el guión para ver las instrucciones de entrega]

{'fraction_non_alphanumeric': 0.07980717728976969, 'fraction_numerical': 0.02555666080036728, 'mean_word_length': 3.9328175127382523, 'pattern_counts': {'":': 0, '<': 13, '<?xml version=': 0, '>': 61, 'https://': 0, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 14, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2777090', 'n_tokens_mistral': 8865, 'n_tokens_neox': 8219, 'n_words': 4036}