Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Telefonía IP (SIP, Diameter, RTP/RTPC)

5.946 visualizaciones

Publicado el

Diapositivas del curso "Sistemas de Conmutación" del programa de Ingeniería en Electrónica y Telecomunicaciones de la FIET de la Universidad del Cauca, República de Colombia.
Tema: Telefonía IP

Publicado en: Ingeniería

Telefonía IP (SIP, Diameter, RTP/RTPC)

  1. 1. Ing. Fernando Mendioroz, MSc. (c.) Dr. Ing. Álvaro Rendón Gallón Popayán, 2014 Universidad del Cauca Facultad de Ingeniería Electrónica y Telecomunicaciones Departamento de Telemática
  2. 2.  Voz sobre IP (VoIP)  Introducción.  Principales componentes.  Códecs y protocolos.  Funcionamiento y arquitecturas.  Factores que afectan la calidad de voz.  Telefonía e Internet.  Protocolo de Inicio de Sesión: SIP  Definiciones y Arquitectura.  Métodos/Mensajes/Transacciones SIP.  Internetworking con redes legadas de circuitos conmutados.  Plano de Usuario en Telefonía IP: RTP/RTCP.  Descripción General.  Formato del paquete RTP.  Protocolo de Control RTP: RTCP.  Formato del paquete RTCP.  Protocolo AAA: Diameter.  Generalidades del protocolo.  Arquitectura Diameter.  Sesiones Diameter.  Comandos básicos.  Funciones AAA.
  3. 3. Introducción
  4. 4. Introducción  VoIP viene de las palabras en inglés Voice over Internet Protocol (voz sobre IP).  VoIP permite que la voz sea transportada en paquetes IP y, consecuentemente, a través de redes de paquetes conmutados, como por ejemplo: Internet (y como se verá más adelante en el curso, por redes de telefonía móvil de 2.5G, 3G y 4G –GPRS/EDGE, IMS, VoLTE, etc.-)  Constituye la base del paradigma de Telefonía IP, conjugando dos mundos históricamente separados: la transmisión de voz y la transmisión de datos.
  5. 5. Introducción  VoIP entonces, no constituye de por sí un servicio sino una tecnología, compuesta por:  múltiples protocolos tanto para el plano de control (señalización) como el de usuario (audio/vídeo);  múltiples topologías de red (e.g.: IMS);  múltiples dispositivos (Códecs, terminales).  Esta tecnología permite encapsular la voz en paquetes para ser transportados sobre redes de datos, sin necesidad de disponer de los circuitos conmutados convencionales de la redes de telefonía pública conmutada fija y móviles de segunda generación (PSTN / PLMN – GSM/IS41/IS-95-), que fueron desplegadas a lo largo de décadas para transmitir las señales de voz con una excelente calidad de servicio.
  6. 6. Introducción  Las redes de telefonía pública conmutadas fijas y móviles de segunda generación (PSTN / PLMN –GSM/IS41/IS-95-), se basan en conmutación de circuitos:  Una comunicación requiere el establecimiento de un circuito físico durante el tiempo que dura ésta. Esto significa que los recursos que intervienen en la realización de una llamada no pueden ser utilizados en otra hasta que la establecida previamente finalice (liberación).  La telefonía IP se basa en conmutación de paquetes:  Transmite múltiples conversaciones a través del mismo canal físico, codificadas en paquetes y en flujos independientes.
  7. 7. Introducción  Integración de voz, video y datos.  Consolidación del ancho de banda. • Aprovechamiento de los intervalos entre tramas haciendo un uso más efectivo de canales costosos.  Costos de las comunicaciones. • Ventaja de 4:1 a favor de la voz empaquetada (y aumentando).  Presencia universal de Internet. • El conjunto de protocolos TCP/IP reside hasta en la PC del usuario.  Maduración de tecnologías. • Desarrollo de DSP (procesadores digitales de señales) para Códecs y Módems de alta velocidad.  Desplazamiento de los servicios hacia las redes de datos: • 80% conmutación de paquetes y 20% conmutación de circuitos. • Se observa mayor influencia en comunicaciones de larga distancia. ¿Por qué telefonía vía Internet?
  8. 8. Introducción Estadísticas de VoIP  Algunos enlaces al respecto: http://www.itu.int/ITU- D/ict/newslog/CategoryView,category,VoIP.aspx http://www.wirelessweek.com/articles/2011/03/analyst-corner-rise- mobile-voip-means-evolving-core-product-set http://www.telecomasia.net/content/more-adding-capacity http://www.cisco.com/c/en/us/td/docs/cable/serv_exch/serv_contr ol/broadband_app/rel40x/usage_analysis/usage_analysis.html
  9. 9. Introducción Estadísticas de VoIP
  10. 10. Introducción Estadísticas de VoIP
  11. 11. Introducción Estadísticas de VoIP
  12. 12. Introducción Estadísticas de VoIP
  13. 13. Introducción Estadísticas de VoIP
  14. 14.  Voz sobre IP (VoIP)  Introducción.  Principales componentes.  Códecs y protocolos.  Funcionamiento y arquitecturas.  Factores que afectan la calidad de voz.  Telefonía e Internet.  Protocolo de Inicio de Sesión: SIP  Definiciones y Arquitectura.  Métodos/Mensajes/Transacciones SIP.  Internetworking con redes legadas de circuitos conmutados.  Plano de Usuario en Telefonía IP: RTP/RTPC.  Descripción General.  Formato del paquete RTP.  Protocolo de Control RTP: RTCP.  Formato del paquete RTCP.  Protocolo AAA: Diameter.  Generalidades del protocolo.  Arquitectura Diameter.  Sesiones Diameter.  Comandos básicos.  Funciones AAA.
  15. 15. Componentes Básicos de Red VoIP
  16. 16. Componentes Básicos de Red VoIP  Cliente. Establece y termina las llamadas de voz. Codifica, empaqueta y transmite la información de salida generada por el micrófono del usuario. Asimismo, recibe, decodifica y reproduce la información de voz de entrada a través de los altavoces o audífonos del usuario.  Servidor. Realiza operaciones de validación de usuarios, tasación, contabilidad, tarificación, recolección, distribución de utilidades, enrutamiento, administración general del servicio, carga de clientes, control del servicio, registro de usuarios y servicios de directorio, entre otros.  Gateway. Provee las interfaces con la telefonía tradicional de circuitos conmutados, funcionando como una plataforma para clientes virtuales. Estos equipos también juegan un papel importante en la seguridad de acceso, la contabilidad, el control de calidad del servicio (QoS: Quality of Service) y en el mejoramiento del mismo.
  17. 17.  Voz sobre IP (VoIP)  Introducción.  Principales componentes.  Códecs y protocolos.  Funcionamiento y arquitecturas.  Factores que afectan la calidad de voz.  Telefonía e Internet.  Protocolo de Inicio de Sesión: SIP  Definiciones y Arquitectura.  Métodos/Mensajes/Transacciones SIP.  Internetworking con redes legadas de circuitos conmutados.  Plano de Usuario en Telefonía IP: RTP/RTCP.  Descripción General.  Formato del paquete RTP.  Protocolo de Control RTP: RTCP.  Formato del paquete RTCP.  Protocolo AAA: Diameter.  Generalidades del protocolo.  Arquitectura Diameter.  Sesiones Diameter.  Comandos básicos.  Funciones AAA.
  18. 18. Códecs para VoIP  G.711:  Codificación PCM.  BW=64 Kbps, fm =8 KHz (PSTN).  G.723.1: ◦ Codificación predictiva, comprime la voz en tramas de 30 ms. ◦ BW =5,3 y 6,3 Kbps, fm =8 KHz.  G.726: ◦ Codificación ADPCM. ◦ BW=16/24/32/40 Kbps, fm =8 KHz.  G.729: ◦ Codificación predictiva. ◦ BW = 8 Kbps, fm = 8 KHz. ◦ Muy usado en VoIP. Versiones a 6,4 y 11,8 Kbps. ◦ Versión G729B con supresión de silencios.
  19. 19. Códecs para VoIP  GSM 06.10 ◦ BW=13 Kbps, fm =8 KHz. ◦ Desarrollado para telefonía móvil celular.  iLBC (Internet Low Bit rate Codec) ◦ Códec libre, usa tramas de 30 ms. ◦ BW=8 Kbps, fm =13,3 KHz.  Speex: ◦ Códec libre, usa un algoritmo VBR (Variable Bit Rate) con tramas de 30/40 ms. ◦ BW=8, 16, 32 Kbps, fm =2,15 a 44,2 KHz.
  20. 20. Códecs para VoIP http://blog.tmcnet.com/voice-of-ip/hd_voice/
  21. 21. Códecs para VoIP http://www.cisco.com/c/en/us/support/docs/voice/h323/14 069-codec-complexity.html
  22. 22. Códecs para VoIP http://www.cisco.com/c/en/us/support/docs/voice/h323/14 069-codec-complexity.html
  23. 23. Códecs para VoIP
  24. 24. Protocolos de VoIP TCP / SCTP UDP / DCCP IP RTP: Real-time Transport Protocol RTCP: RTP Control Protocol SCTP: Stream Control Transmission Protocol (SIP over SCTP: IETF RFC 4168) SIP: Session Initiation Protocol BICC: Bearer Independent Call Control DCCP: Datagram Congestion Control Protocol (IETF RFC 4340) RTPH.323 SIPH.248 RTCP Plano de Control: Señalización Plano de Usuario: Medios (Audio, Vídeo) BICC
  25. 25. Protocolos del Plano de Usuario/Medios de VoIP  RTP (Real-time Transport Protocol): Transmisión de flujos de audio y video en tiempo real. Suministra servicios de: ◦ Secuenciación de paquetes. ◦ Sincronización intra-medios. ◦ Sincronización inter-medios. ◦ Identificación del tipo de carga. ◦ Indicación de trama.  RTCP (RTP Control Protocol): Control y gestión de sesiones RTP. IETF RFC 3550 http://tools.ietf.org/pdf/rfc3550.pdf
  26. 26. Protocolos del Plano de Control/Señalización de VoIP: Existen diferentes protocolos de control de llamadas y señalización para VoIP:  BICC (Bearer Independent Call Control): Especificado por ITU-T Q.1901, constituye una evolución de ISUP, pues separa el plano de medios del de control (señalización), por lo tanto, la información de señalización puede atravesar nodos diferentes de la información del plano de medios o usuario. Además, puede ser transportada además de por redes SS7, por redes basadas en IP.  H.323: Sistema de comunicación multimedios basados en paquetes, también definido por ITU-T (ITU-T Recommendation H.323). A diferencia de BICC, fue especificado desde el inicio para redes IP. En H.323, la información de ambos planos (usuario/medios & control/señalización) no necesitan atravesar los mismos nodos.
  27. 27. Protocolos del Plano de Control/Señalización de VoIP:  SIP (Session Initiation Protocol): Especificado en IETF RFC 3261 para establecimiento y gestión de sesiones multimedia a través de redes IP. Elegido por 3GPP como el protocolo de control de sesión para el IMS y LTE (VoLTE). Hereda características de HTTP y SMTP. Ventajas respecto a BICC y H.323: ◦ Por ser basado en texto, es más simple de depurar, extender y utilizar para crear servicios. ◦ No diferencia la interfaz usuario-red (UNI, «User-to-Network Interface») de la interfaz red-red (NNI, Network-to-Network Interface).
  28. 28. Protocolos del Plano de Control/Señalización de VoIP:  MGCP (Media Gateway Control Protocol): Protocolo de control de la pasarela de medios (IETF RFC 2805). Resulta de la combinación de SGCP (Simple Gateway Control Protocol) e IDPC (Internet Device Control Protocol).  MEGACO (ITU-T H.248): Protocolo de control de pasarela (Gateway Control Protocol, ITU-T H.248). Combina MGCP y MDCP (Media Device Control Protocol). Especificación inicial de la IETF (RFC 3525) ya considerada obsoleta (por la misma IETF RFC 5125. Constituye un protocolo del tipo maestro/esclavo. Separa las lógicas de control de llamada y procesamiento de medios en un Gateway.
  29. 29. Protocolos de Autenticación, Autorización y Contabilidad AAA (Authentication, Authorization, and Accounting)  RADIUS (Remote Authentication Dial In User Service): Protocolo de capa de aplicación para AAA especificado en IETF RFC 2865. De tipo cliente/servidor utiliza UDP como transporte. Utilizado originalmente por ISP para gestionar el acceso a Internet cuando el usuario efectúa el dial-up (conexión a través del módem vía la línea telefónica) o por empresas para acceso a redes fijas/inalámbricas o servicios de correo integrados.  Diameter: Evolución de RADIUS para AAA especificado en IETF RFC 6733. Diameter consiste de un protocolo base complementado por autodenominadas “aplicaciones Diameter”, las cuales constituyen adaptaciones o extensiones a Diameter de modo encajar en un determinado ambiente para una aplicación en particular. Redes basadas en IP para telefonía como el IMS y LTE utilizan Diameter en un número amplio de interfaces, a pesar de que no todas ellas utilizan la misma aplicación Diameter. Por ejemplo, el IMS define una aplicación Diameter conjuntamente con SIP durante el establecimiento de la sesión, y otra de forma de realizar gestión de contabilidad (control de crédito de suscriptor).
  30. 30.  Voz sobre IP (VoIP)  Introducción.  Principales componentes.  Códecs y protocolos.  Funcionamiento y arquitecturas.  Factores que afectan la calidad de voz.  Telefonía e Internet.  Protocolo de Inicio de Sesión: SIP  Definiciones y Arquitectura.  Métodos/Mensajes/Transacciones SIP.  Internetworking con redes legadas de circuitos conmutados.  Plano de Usuario en Telefonía IP: RTP/RTCP.  Descripción General.  Formato del paquete RTP.  Protocolo de Control RTP: RTCP.  Formato del paquete RTCP.  Protocolo AAA: Diameter.  Generalidades del protocolo.  Arquitectura Diameter.  Sesiones Diameter.  Comandos básicos.  Funciones AAA.
  31. 31. Funcionamiento de una red VoIP http://www3.sangoma.com/products/media_processing/voice_tran scoding_boards/d150.html VoIP funciona:  Digitalizando la voz en paquetes de datos:  Conversión A/D vía Códec;  Algoritmo de compresión;  Entramado digital.  Transmitiéndola a través de la red IP;  Reconvirtiéndola a voz en el destino (procesos inversos de origen: de- entramado, de- compresión y decodificación vía Códec).
  32. 32. Funcionamiento de una red VoIP Pasos de una comunicación: i. Los dos comunicantes se registran en el servidor VoIP con sus dispositivos. ii. El equipo emisor investiga vía el servidor VoIP por el equipo receptor con un protocolo de señalización (H.323, H.248, SIP). iii. El servidor VoIP devuelve los datos de contacto al emisor (e.g.: dirección IP). iv. Los teléfonos establecen comunicación y acuerdan un tipo de Códec (G.711, G.729, GSM, etc.). v. Los datos de voz se comprimen y se transmiten vía el protocolo RTP. vi. El receptor recibe los paquetes RTP y decodifica los datos de voz. vii. Transmisión/Escucha de voz.
  33. 33. Arquitecturas VoIP Uno de los beneficios de la tecnología VoIP, es que permite a las redes ser construidas usando una arquitectura centralizada o distribuida. Esta flexibilidad permite a las compañías construir redes caracterizadas por una administración simplificada y la innovación de terminales (teléfonos), dependiendo del protocolo usado.  Arquitectura centralizada  Arquitectura distribuida
  34. 34. Arquitecturas Centralizada  En general, está asociada con los protocolos MGCP y MEGACO (H.248). Estos protocolos fueron diseñados para una entidad centralizada denominada Agente de Llamadas o Controladora de la Pasarela de Medios (Media Gateway Controller), que maneja la lógica de conmutación y control de llamadas.  La inteligencia de la red está centralizada y los dispositivos finales de usuario o terminales tienen características limitadas (terminales relativamente «tontos» ).  Los defensores de la arquitectura VoIP centralizada, apoyan este modelo porque centraliza la administración, el aprovisionamiento y el control de llamadas, simplificando el flujo de llamadas repitiendo las características de voz.
  35. 35. Arquitecturas Distribuida  Está asociada con los protocolos H.323 y SIP. Estos protocolos permiten que la inteligencia de la red esté distribuida entre los dispositivos de control de llamadas y los terminales. La inteligencia en esta instancia se refiere a establecer llamadas, características de llamadas, enrutamiento de llamadas, aprovisionamiento, facturación, o cualquier otro aspecto del manejo de llamadas.  Los terminales pueden ser pasarelas VoIP, teléfonos IP, servidores de medios, o cualquier dispositivo que pueda iniciar y terminar una llamada VoIP.  Los dispositivos de control de llamadas son llamados controladores de acceso o Gatekeepers en una red H.323, o Proxy/Redirect Servers en una red SIP.
  36. 36. Arquitectura VoIP
  37. 37. Interworking con Redes Legadas
  38. 38.  Voz sobre IP (VoIP)  Introducción.  Principales componentes.  Códecs y protocolos.  Funcionamiento y arquitecturas.  Factores que afectan la calidad de voz.  Telefonía e Internet.  Protocolo de Inicio de Sesión: SIP  Definiciones y Arquitectura.  Métodos/Mensajes/Transacciones SIP.  Internetworking con redes legadas de circuitos conmutados.  Plano de Usuario en Telefonía IP: RTP/RTCP.  Descripción General.  Formato del paquete RTP.  Protocolo de Control RTP: RTCP.  Formato del paquete RTCP.  Protocolo AAA: Diameter.  Generalidades del protocolo.  Arquitectura Diameter.  Sesiones Diameter.  Comandos básicos.  Funciones AAA.
  39. 39. Factores que afectan la calidad de la voz
  40. 40. Factores que afectan la calidad de la voz Desventajas de VoIP  Calidad de la comunicación: ecos, interferencias, interrupciones, sonidos de fondo, distorsiones de sonido. Estos pueden variar según la conexión a Internet y la velocidad de conexión del proveedor de servicios de Internet o ISP.  Actualmente es imposible garantizar la calidad de servicio sobre una red IP, debido a los retardos que se presentan tanto en el tránsito de los paquetes y como en el procesamiento de la conversación.  El ancho de banda no siempre está garantizado, lo que desmejora el servicio. Pérdida de paquetes y falta de garantía sobre el tiempo que estos tardarán en llegar de un extremo al otro de la comunicación.
  41. 41. Factores que afectan la calidad de la voz a) Códecs b) Pérdida de tramas (Loss of Frame) c) Retardo (Delay): • Fuentes de retardo • Eco • Superposición de la conversación d) Variación del retardo (Jitter)
  42. 42. Factores que afectan la calidad de la voz Códecs Antes de que la voz sea transmitida sobre una red IP, primero debe ser digitalizada. Muestreo: 8.000 muestras/s; Cuantificación: a cada nivel de cuantificación se le asigna un código binario distinto (Codificación). PCM no comprime BW, ADPCM si.
  43. 43. Factores que afectan la calidad de la voz Códecs
  44. 44. Factores que afectan la calidad de la voz Pérdida de Tramas  Las tramas VoIP se pueden perder como resultado de una congestión de red o corrupción de datos.  En tiempo real no es práctico retransmitir las tramas, luego los terminales de voz tienen que tratar con la pérdida de tramas (Frame Erasure).  El efecto de la pérdida de tramas en la calidad de voz depende del manejo que le den los terminales. • En el caso más simple, el terminal deja un intervalo en silencio en el flujo de voz: sonido entrecortado. • Packet Loss Concealment (PLC): Compensación de las tramas perdidas con base en las muestras de voz previas. • PLC es incluido en Códecs tales como: PLC+G.711, PLC+CELP: G.723.1, G.728 y G.729.
  45. 45. Factores que afectan la calidad de la voz Retardo (Delay) – Fuentes de Retardo  Retardo Algorítmico: es el retardo introducido por el Códec y es inherente al algoritmo de codificación.  Retardo de Paquetización: es el tiempo para llenar un paquete de información (carga útil) de la conversación ya codificada y comprimida. Este retardo es función del tamaño de bloque requerido por el codificador de voz y el número de bloques de una sola trama.  Retardo de Serialización: es el tiempo requerido para transmitir un paquete IP, es decir, está relacionado directamente con la tasa del reloj de transmisión. Se presenta cuando los paquetes pasan a través de un dispositivo de almacenamiento y retransmisión tales como un enrutador o un conmutador.
  46. 46. Factores que afectan la calidad de la voz Retardo (Delay) – Fuentes de Retardo  Retardo de Propagación: es el tiempo requerido por la señal óptica o eléctrica para viajar a través de un medio de transmisión y depende de la distancia geográfica.  Retardo de Componente: son causados por los componentes dentro del sistema de transmisión. Por ejemplo, una trama que pasa a través de un enrutador tiene que ser trasladada desde el puerto de entrada al puerto de salida a través del panel trasero.
  47. 47. Factores que afectan la calidad de la voz Retardo (Delay) – Retardo de Paquetización
  48. 48. Factores que afectan la calidad de la voz Retardo (Delay) – Eco  El primer deterioro causado por el retardo es el eco.  El eco puede presentarse en una red de voz debido a un inadecuado acoplamiento entre el dispositivo de escucha y el dispositivo de habla en el micro-teléfono. Este es conocido como eco acústico.  También puede presentarse cuando parte de la energía eléctrica es reflejada al abonado llamante por el circuito híbrido en la PSTN. Este es conocido como eco del híbrido.  La cancelación de eco no es necesaria si el retardo de una vía es menor de 25 ms. Sin embargo, la cancelación de eco siempre es requerida pues el retardo de una vía en una red VoIP casi siempre excederá los 25 ms.
  49. 49. Factores que afectan la calidad de la voz Retardo (Delay) – Superposición de la conversación  Aún con un método de cancelación de eco perfecto, una conversación de dos vías llega a ser difícil cuando el retardo es demasiado grande, debido a la superposición de la conversación (talker overlap): la voz de uno de los abonados se superpone a la voz del otro.  ITU-T G.114 provee las siguiente recomendaciones con relación al límite de retardo de una vía.
  50. 50. Factores que afectan la calidad de la voz Variación de Retardo (Jitter) Cuando las tramas son transmitidas a través de una red IP, la cantidad de retardo experimentado por cada trama puede diferir. Esto es causado por la cantidad de retardo de encolamiento y tiempo variable de procesamiento dependiendo del tráfico cargado a la red.  El terminal fuente genera tramas de voz a intervalos regulares (e.g.: cada 50 ms).  El terminal destino típicamente no recibirá las tramas de voz en intervalos regulares debido al problema del jitter.
  51. 51. Factores que afectan la calidad de la voz Variación de Retardo (Jitter)  En general, la estrategia con el problema de jitter es almacenar las tramas recibidas en una memoria temporal o buffer tan grande que permita a las tramas más lentas arribar a tiempo para ser ubicadas en la secuencia correcta.  El jitter puede ser mayor debido a tramas de mayor tamaño que son almacenadas en la memoria, lo cual introduce retardo adicional. Para minimizar el retardo debido al almacenamiento, muchas aplicaciones usan una memoria de jitter adaptativa.
  52. 52. Factores que afectan la calidad de la voz Retardo Total Ejemplo: Memoria
  53. 53.  Voz sobre IP (VoIP)  Introducción.  Principales componentes.  Códecs y protocolos.  Funcionamiento y arquitecturas.  Factores que afectan la calidad de voz.  Telefonía e Internet.  Protocolo de Inicio de Sesión: SIP  Definiciones y Arquitectura.  Métodos/Mensajes/Transacciones SIP.  Internetworking con redes legadas de circuitos conmutados.  Plano de Usuario en Telefonía IP: RTP/RTCP.  Descripción General.  Formato del paquete RTP.  Protocolo de Control RTP: RTCP.  Formato del paquete RTCP.  Protocolo AAA: Diameter.  Generalidades del protocolo.  Arquitectura Diameter.  Sesiones Diameter.  Comandos básicos.  Funciones AAA.
  54. 54. Telefonía e Internet Plataforma de Despliegue de Servicios NGN  Arquitectura Orientada a Servicios (SOA)  Evolución hacia una red “All-IP”  Interfaces estandarizadas (3GPP, OMA, IETF) de Servicios de Red comunes (abstractas)  Basado en protocolos sobre IP (SIP/Diameter)  Definición de IMS (IP Multimedia Subsystem)
  55. 55. Las aplicaciones actuales  Juegos distribuidos  Realidad virtual  Web-IVR  VoIP  Videoconferencia  Mensajería instantánea  Calendario  Mensajería unificada Las nuevas aplicaciones Principalmente integración de las ya existentes, pero también nuevas, e.g.:  SMS to Fixed phone  IP-TV/Follow me TV  Gaming IP  PBX-IP  Multimedia calling  Click to dial Answer Call Send-to- Voice Mail Cancel Call Telefonía e Internet
  56. 56.  Voz sobre IP (VoIP)  Introducción.  Principales componentes.  Códecs y protocolos.  Funcionamiento y arquitecturas.  Factores que afectan la calidad de voz.  Telefonía e Internet.  Protocolo de Inicio de Sesión: SIP  Definiciones y Arquitectura.  Métodos/Mensajes/Transacciones SIP.  Internetworking con redes legadas de circuitos conmutados.  Plano de Usuario en Telefonía IP: RTP/RTCP.  Descripción General.  Formato del paquete RTP.  Protocolo de Control RTP: RTCP.  Formato del paquete RTCP.  Protocolo AAA: Diameter.  Generalidades del protocolo.  Arquitectura Diameter.  Sesiones Diameter.  Comandos básicos.  Funciones AAA.
  57. 57. Definiciones y Arquitectura TCP / SCTP UDP / DCCP IP RTPH.323 SIPH.248 RTCP Plano de Control: Señalización Plano de Usuario: Medios (Audio, Vídeo) BICC
  58. 58. Definiciones y Arquitectura Enrutamiento de Llamada – Convergencia IP Una conexión IP (e.g.: GPRS, ADSL, WLAN, UMTS, VoLTE) Servicios basados en IP posibles entre terminales El IMS enruta la llamada y conecta los terminales vía SIP Vía SIP los terminales que inician la llamada solicitan encontrar y conectar ambos extremos
  59. 59. Definiciones y Arquitectura Definición IETF RFC 3261 «Es un protocolo de señalización de capa de aplicación que define la iniciación, modificación y finalización de sesiones de comunicación interactiva, multimedia entre usuarios.» “Protocolo de señalización de la capa de aplicación para iniciar o establecer sesiones entre terminales para intercambio de contenido.»
  60. 60. Definiciones y Arquitectura Características  Codificación en texto (formato basado en HTTP).  Programación simple.  Usa primitivas (mensajes).  Servicios de autenticación, localización, control de llamada, etc.  Provee presencia y movilidad.  Señalización extremo a extremo.  Protocolo de propósito general: No está limitado a la telefonía IP.  Los mensajes SIP pueden transportar una carga arbitraria (SDP, IM, JPEG, cualquier tipo MIME). SDP: Session Description Protocol IM: Instant Messaging
  61. 61. Definiciones y Arquitectura Capacidades  Soporta 5 facetas del establecimiento y terminación de comunicaciones multimedia  Localización de usuario  Disponibilidad de usuario  Capacidades de usuario  Configuración de sesión  Gestión de sesión  RTP, RTCP, SDP, MEGACO, etc. RTSP: Real Time Streaming Protocol
  62. 62. Definiciones y Arquitectura Arquitectura SIP - IETF RFC 3261
  63. 63. Definiciones y Arquitectura Servidores SIP / Interfaces VoIP
  64. 64. Definiciones y Arquitectura Agentes de Usuario SIP  User Agent (UA): Entidad lógica de origen (Cliente) o terminación (Servidor) de una transacción SIP. Un agente de usuario puede actuar como cliente o servidor, pero sólo puede asumir uno de esos roles durante una transacción SIP. X-Lite Adaptador (ATA: Analog Terminal Adapter) CiscoIP7916 Teléfono SIP: y aplicaciones (Softphones: Linphone, SipPhone, X-Lite, KPhone, SipCommunicator, SipTrex, JPhone, etc.) Disponible en dispositivos
  65. 65. Definiciones y Arquitectura Agentes de Usuario SIP  User Agent Client (UAC): Entidad lógica de una transacción SIP mediante la creación de una solicitud y utilización de la máquina de estados transaccional SIP para su envío. La duración de una transacción SIP determina el intervalo de tiempo del rol de un agente como UAC. En caso de recibir una solicitud tras la finalización de una transacción, el mismo agente cambia de rol a UAS para el procesamiento de la nueva transacción SIP.  User Agent Server (UAS): Entidad lógica generadora de una respuesta a una petición SIP. La respuesta acepta, rechaza o redirige la petición. La duración de una transacción SIP determina el intervalo de tiempo del rol de un agente como UAS. En caso de originar una solicitud tras la finalización de una transacción, el mismo agente cambia de rol a UAC para el procesamiento de la nueva transacción SIP. IETF RFC 3261
  66. 66. Definiciones y Arquitectura Agentes de Usuario SIP  Back to Back User Agent (B2BUA):  Entidad lógica receptora de solicitudes que son procesadas como un UAS.  Para determinar cómo deben responderse las solicitudes, actúa como un UAC y genera solicitudes.  A diferencia de un servidor proxy, mantiene el estado de diálogo y debe participar en todas las solicitudes enviadas en los diálogos que establece.  Desde que consiste de una concatenación de UAC y UAS, no son necesarias definiciones explícitas para su comportamiento. IETF RFC 3261
  67. 67. Definiciones y Arquitectura Servidores SIP  Proxy Server:  Entidad intermedia que actúa tanto como servidor como cliente para el propósito de efectuar solicitudes en nombre de otros clientes. Es decir, actúa como UAC y UAS en nombre de otros clientes.  Su propósito primigenio es el enrutamiento de solicitudes (señalización), de modo que se dirijan a la entidad más cercana al usuario destinatario.  Aseguran políticas (e.g.: autorización de un usuario a establecer una llamada).  Interpreta y en caso de ser necesario, reescribe partes específicas de un mensaje de solicitud antes de reenviarlo. IETF RFC 3261
  68. 68. Definiciones y Arquitectura Servidores SIP  Redirect Server:  Entidad intermedia que actúa como UAS para redireccionar llamadas a servidores de dominios externos.  Genera respuestas de código 3xx a solicitudes entrantes, indicando al cliente originante a contactar un set alternativo de direcciones (URI). IETF RFC 3261  Registrar Server:  Entidad intermedia que actúa como UAS para administración de registro de usuarios.  Alojado en Proxy o en Redirect.  Acepta solicitudes REGISTER y ubica la información allí recibida en el servicio de localización adecuado al dominio que maneja.
  69. 69. Definiciones y Arquitectura Servidores SIP  Location Server:  Entidad intermedia que actúa como UAS para administrar la asociación de direcciones SIP lógicas y físicas.  Usualmente alojado en Registrar.  Un servicio de localización es utilizado para obtener información de la(s) posible(s) ubicación(es) del usuario llamado. Contiene una lista de enlaces de claves de dirección de registro a cero o más direcciones de contacto. Los enlaces o «bindings» pueden crearse y removerse de múltiples formas (RFC 3261 define un método REGISTER para actualización de bindings). IETF RFC 3261
  70. 70. Definiciones y Arquitectura Transacciones SIP y roles de agentes de usuario  El establecimiento de la sesión SIP es llevada adelante entre un conjunto de proxis SIP. El trayecto de comunicación para la sesión multimedia se define durante el establecimiento de la sesión SIP, no obstante la transferencia de datos de usuario multimedia no se lleva a cabo aún.  Una vez la sesión SIP queda establecida, normalmente se mantiene por el resto de la sesión entre un número menor de proxis SIP que durante el establecimiento de la misma. A partir de entonces, la transferencia de información multimedia entre ambos agentes de usuario puede comenzar.
  71. 71. Definiciones y Arquitectura Transacciones SIP y roles de agentes de usuario  La relación entre la sesión SIP y la sesión multimedia permanece durante la totalidad de la sesión en ambos planos.  La sesión multimedia en el plano de usuario permanece bajo el control de la sesión SIP. Cualquier modificación en la definición de la sesión de multimedia, así como la terminación de la misma, es señalizada entre los agentes de usuario vía la sesión SIP.  Una transacción SIP convive en el modelo de estado de transacción cliente-servidor. El agente de usuario iniciador de la transacción adquiere el rol de agente de usuario cliente o «UAC», en tanto el agente de usuario que recibe y ejecuta la misma adquiere el rol de agente de usuario servidor o «UAS».
  72. 72. Trapezoide SIP
  73. 73.  Voz sobre IP (VoIP)  Introducción.  Principales componentes.  Códecs y protocolos.  Funcionamiento y arquitecturas.  Factores que afectan la calidad de voz.  Telefonía e Internet.  Protocolo de Inicio de Sesión: SIP  Definiciones y Arquitectura.  Métodos/Mensajes/Transacciones SIP.  Internetworking con redes legadas de circuitos conmutados.  Plano de Usuario en Telefonía IP: RTP/RTCP.  Descripción General.  Formato del paquete RTP.  Protocolo de Control RTP: RTCP.  Formato del paquete RTCP.  Protocolo AAA: Diameter.  Generalidades del protocolo.  Arquitectura Diameter.  Sesiones Diameter.  Comandos básicos.  Funciones AAA.
  74. 74. Direcciones SIP  Las direcciones SIP se conocen como SIP URI (SIP Uniform Resource Identifier)  Identifican un recurso de comunicación. Ejemplos:  Usuario de un servicio en línea;  La aparición en un teléfono multi-línea;  Una cuenta de correo en un sistema de mensajería.  Un número telefónico de la PSTN en un servicio de pasarela (gateway);  Un grupo dentro de una organización (dpto. de ventas, soporte, etc.).
  75. 75. Direcciones SIP Las SIP URI adoptan la forma general: sip:user:password@host:port;uri-parameters?headers (cuyo ejemplo básico sería: sip:user@host.domain) Ejemplos: sip:user24@sip.mydomain.com sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15 sip:voicemail@iptel.org?subject=callme carol@ws1234.domain2.com;transport=tcp sip:sales@hotel.xy; geo.position:=48.54_-123.84_120 (Se permite otro tipo de URL -http, mailto, etc.-).
  76. 76. Direcciones SIP  Adicionalmente, los usuarios pueden ser identificados mediante SIPS URI (SIP SECURED URI).  Ejemplo: sips:alice.smith@domain.com  Las entidades contactando SIPS URI utilizan TLS (Transport Layer Security) entre el UAC y el dominio al que pertenece la URI. Desde allí, comunicaciones seguras son utilizadas para alcanzar al usuario, donde los mecanismos específicos de seguridad dependen de las políticas del dominio.  Cualquier recurso descripto por una SIP URI puede actualizarse a SIPS URI mediante un simple cambio de esquema, si es el caso que pasa a necesitarse una comunicación segura con ese recurso.
  77. 77. Direcciones SIP  Es posible incluir un número telefónico en una SIP URI utilizando el siguiente formato, por ejemplo: sip:+1-212-555-0293@operator.com;user=phone  Este formato es necesario dado que SIP requiere que la URI bajo registro sea una SIP URI, pues no es posible en SIP registrar una TEL URI –formato de identificación pública usado en el IMS para conectar un terminal IMS con un teléfono de la PSTN-, mas si es posible registrar una SIP URI que contiene un número telefónico como la del ejemplo anterior.
  78. 78. Mensajes SIP  Los mensajes SIP pueden ser transmitidos sobre TCP, SCTP o UDP.  Los mensajes SIP están basados en texto y usan el conjunto de caracteres ISO 10646 en codificación UTF-8.  Utiliza MIME (Multipurpose Internet Mail Extensions, definido por IETF RFC 2045), para codificar sus mensajes. El formato MIME permite enviar correos electrónicos con múltiples archivos adjuntos de diferentes formatos como imágenes JPEG o vídeo MPEG, entre otros.  Las líneas deben estar terminadas con CRLF (CRLF: Caracteres CR (retorno del carro) y LF (avance de línea)).  La mayor parte de la sintaxis de los mensajes y campos de cabecera son similares a HTTP.  Los mensajes pueden ser de tipo request (solicitud) o response (respuesta).
  79. 79. Ejemplo/estructura de mensaje SIP de solicitud: Request
  80. 80. Descripción de sesión SIP SDP (Session Description Protocol)  En sesiones multimedia sobre Internet, la información de establecimiento debe contener suficiente información a entregar al usuario remoto para unirse a la sesión, datos imprescindibles como la dirección IP y puerto ( «socket») por donde debe enviarse el flujo de medios, y los Códecs utilizados para codificar la voz.  El formato más común para describir sesiones multimedia es el establecido por SDP, definido en IETF RFC 2327, el cual comprende un formato textual para describir sesiones multimedia.  SDP consiste de dos secciones: 1) información de sesión, 2) información de medios.  SIP es independiente de SDP, es decir, aunque es el más usado, no lo utiliza como único formato de descripción de sesión. Esto es, SIP puede entregar la información de descripción de sesión escrita en SDP o cualquier otro formato (por ejemplo, para IM no se usa SDP).
  81. 81. Descripción de sesión SIP SDP (Session Description Protocol)  SDP va contenido en el cuerpo de un mensaje SIP. A continuación, un ejemplo: v=0 o=Alice 3239874567 4447990887 IN IP4 10.0.0.1 s=Hablemos de aves c=IN IP4 10.0.0.1 t=0 0 m=audio 20000 RTP/AVP 0 a=sendrecv m=video 20002 RTP/AVP 31 a=sendrecv El ejemplo anterior contiene, la descripción de una sesión iniciada por el usuario «Alice», cuya dirección IP es 10.0.0.1, los números de puerto por donde quiere transmitir bidireccionalmente (enviar y recibir) información de audio (20000) y vídeo (20002) vía RTP/AVP y los Códecs de audio y video soportados (0 corresponde a ley µ según ITU-T G.711 y 31 corresponde a ITU-T H.261). El sujeto de conversación es «Hablemos de aves»
  82. 82. Descripción de sesión SIP SDP (Session Description Protocol) La siguiente tabla contiene los acrónimos de los tipos SDP y sus significados: Tipo Significado Tipo Significado v Versión del protocolo. u URL contenedora de descripción de la sesión. b Información de ancho de banda. t Tiempo en que la sesión se activa. o Dueño e identificador de sesión. e Dirección de correo electrónico para obtener información de descripción de la sesión. z Ajustes de huso horario. t Tiempo de cuando la sesión será repetida. s Sujeto de la sesión. p Número telefónico de donde obtener información de descripción de la sesión. k Clave de encriptado. m Línea de medios. i Información sobre la sesión. c Información de conexión. a Líneas de atributos. i Información sobre la línea de medios.
  83. 83. Ejemplo/estructura de mensaje SIP de respuesta: Response
  84. 84. Código de estado en mensaje SIP Response Entero de tres dígitos como resultado de entender y satisfacer el Request. Rango de códigos de estado Significado 100-199 Resultado provisional o informativo. El UAS informa al UAC sobre el progreso de la solicitud de la transacción. La respuesta provisional puede contener información adicional requerida por el UAC para la continuación de la transacción. 200-299 Resultado de solicitud exitosa. La transacción se ha ejecutado exitosamente. 300-399 Solicitud redireccionada. Una respuesta de esta clase informa al UAC que el destino de la forma en que fue indicado en el mensaje de solicitud de invitación a la sesión, debiera ser contactado bajo una dirección alternativa, o que un servicio alternativo debiera ser solicitado desde el suscriptor destinatario. 400-499 Falla de solicitud. El UA receptor de la solicitud, en su rol de UAS, ha indicado la imposibilidad de procesar el requerimiento. La acción a llevar adelante por el UAC depende del reporte de error específico, por ejemplo, reintentar la solicitud en un momento posterior. 500-599 Error de agente de usuario servidor. Una respuesta de este tipo indica un error de sistema el cual podría ocurrir por ejemplo, en un servidor proxy. El error podría deberse a una condición de congestión, sobrecarga, falla de infraestructura. Normalmente este error indica que un proxy en particular debe ser puesto en “cuarentena”, esto es, el UA receptor de esta respuesta no debiera enviar una solicitud hacia ese proxy por un tiempo determinado. 600-699 Error global. Este rango de códigos es específico de SIP. Provee una respuesta relativa al usuario destinatario en general, incluyendo un contexto de múltiples terminales para el usuario en cuestión. Por ejemplo, la respuesta podría indicar que el usuario se encuentra indisponible en todas sus terminales.
  85. 85. Mensajes SIP: Solicitudes/Repuestas Extremo-a-Extremo (End-to-End) vs. Salto-a-Salto (Hop-by-Hop)
  86. 86. Métodos SIP: REGISTER  Mapea una URI pública con la localización actual del usuario, es decir, notifica a una red SIP de su actual Contact URI y la URI a la que debieran enrutarse solicitudes hacia esta Contact URI.  Entrega al servidor de registro (Registrar) una dirección de contacto y un alias. Por ejemplo, la dirección sip:UAA@example.com es un alias para sip:UserA@10.20.30.40. El Registrar example.com puede redireccionar las llamadas para UAA hacia la dirección 10.20.30.40.  Un UA necesita este mensaje para recibir llamadas.  Un UA puede recibir un código de respuesta 3xx (redirección) o 4xx (falla de solicitud) conteniendo en el campo de encabezado Contact la ubicación del Registrar correcto.  El campo CSeq es incrementado para cada nueva solicitud REGISTER. El método no inicia un diálogo SIP.  Campos de encabezado mandatorios: Via, To, From, Call-ID, CSeq, Max-Forwards
  87. 87. Ejemplo de Registro SIP Este ejemplo de registro establece el registro del usuario con dirección Fernando@test.org y enlaza esa dirección a la ubicación actual del mismo, i.e., a la dirección IP 192.168.93.1 (puerto 16036) Tras este registro exitoso, todo intento de conectar vía SIP al usuario de URI sip:Fernando@test.org será dirigido a la URI sip:Fernando@192.168.93.1:16036
  88. 88. Código de Estado 2xx: Mensaje 200 OK  Indica que la solicitud se ha procesado exitosamente.  La información devuelta en la respuesta depende del método utilizado para generarla. Ejemplo para SIP REGISTER: REGISTER sip:test.org SIP/2.0 Via: SIP/2.0/UDP 192.168.93.1:16036;branch=z9hG4bK-d8754z-4256cc60f4a08b23-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:Fernando@192.168.93.1:16036;rinstance=b0f6de26f033be7f> To: "Fer"<sip:Fernando@test.org> From: "Fer"<sip:Fernando@test.org>;tag=dce56a27 Call-ID: NTVkYzgyODRjOTY2OWIyYTUzOTIyZmZiNWQ2Mjg5ZDU CSeq: 1 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: X-Lite 4.7.1 74247-74f72fa1-W6.1 Content-Length: 0 SIP/2.0 200 OK Call-ID: 49174b62bb8753e371c698aa9aca491a@127.0.0.1 CSeq: 1 REGISTER From: "localUser" <sip:localUser@localDomain.com>;tag=12345 To: "localUser" <sip:localUser@localDomain.com>;tag=4321 Via: SIP/2.0/UDP 127.0.0.1:5070;branch=z9hG4bKed8ad282c62794e12538d21b19ced425 Max-Forwards: 70 Content-Length: 0
  89. 89. Métodos SIP: INVITE  Establece una sesión (ejemplos: llamada a un agente de usuario, transferencia de llamada).  Las respuestas a INVITE son siempre reconocidas con un ACK.  Usualmente contiene un cuerpo conteniendo la información de medios de la parte llamante (en caso contrario, esta información es contenida en el mensaje ACK de respuesta a ser evaluado, si la información de medios no es aceptable, la parte llamante termina la sesión mediante un BYE).  Una sesión de medios queda establecida cuando han sido intercambiados los mensajes INVITE, 200 OK y ACK entre UAC y UAS, lo cual establece un diálogo entre ellos.  El UAC que envía el INVITE establece un identificador global único que identifica la llamada durante su extensión mediante el campo de encabezado Call-ID.  El campo CSeq es incrementado para cada nueva solicitud según la misma Call-ID.  Campos de encabezado mandatorios: Via, To, From, Call-ID, CSeq, Contact, Max- Forwards
  90. 90. Métodos SIP: ACK  Reconoce la recepción de una respuesta final para un INVITE (los otros métodos no utilizan este método de retroalimentación hacia atrás).  El UAS identifica a qué INVITE corresponde el ACK vía el número CSeq (por tanto, CSeq no es incrementado en un ACK !!!).  En un escenario donde los medios no se conocen tras un INVITE, el ACK puede contener un cuerpo de mensaje application/sdp.  En respuestas 2xx, el ACK es end-to-end, en caso contrario, hop-by- hop cuando existen proxis con estado en el camino (un ACK hop-by-hop reutiliza el mismo Branch ID desde que se considera parte de la misma transacción; un ACK end-to-end usa un Branch ID diferente desde que se considera otra transacción).  Campos de encabezado mandatorios: Via, To, From, Call-ID, Cseq, Max-Forwards
  91. 91. Mensajes SIP ACK Reconocimientos End-to-End vs. Hop-by-Hop
  92. 92. Métodos SIP: BYE  Termina una sesión establecida (se considera establecida si se recibió una respuesta de código 2xx o se ha enviado un ACK).  Es enviado por UA participantes de la sesión, nunca por proxis o terceras partes.  Es un método end-to-end.  Un UA responde a un BYE con un código de respuesta 481 Dialog/Transaction Does Not Exist cuando el diálogo es desconocido.  Campos de encabezado mandatorios: Via, To, From, Call-ID, Cseq, Max-Forwards
  93. 93. Transacción SIP INVITE
  94. 94. Establecimiento exitoso/fallido de llamada SIP
  95. 95. Transacción SIP INVITE-ACK
  96. 96. Señalización y Roles de Agentes de una llamada SIP simple entre extremos (UA1 - UA2)
  97. 97. Llamada convencional con Proxis según IETF RFC 3261
  98. 98. El Modo Proxy
  99. 99. El Modo Redirect
  100. 100. Métodos SIP: CANCEL  Cancela una solicitud pendiente (termina una sesión/llamada aún no confirmada). Ejemplo: método a utilizar por un UA para cancelar un INVITE ya transmitido que no ha recibido ACK).  Es una solicitud hop-by-hop y recibe una respuesta del siguiente elemento con estado. Un UA responde con 200 OK al CANCEL y 487 Request Terminated al INVITE.  Un proxy reenvía el CANCEL a los siguientes elementos con solicitudes pendientes respecto al INVITE previo.  Si una respuesta final se recibió previamente (cruce de mensajes), el UA deberá terminar la sesión con un BYE.  Campos de encabezado mandatorios: Via, To, From, Call-ID, Cseq, Max-Forwards
  101. 101. Métodos SIP: Transacción CANCEL
  102. 102. Métodos SIP: Transacción CANCEL - BYE Caso de cruce de mensajes que deriva en fin de sesión mediante BYE.
  103. 103. Métodos SIP: PRACK  Reconoce la recepción de una respuesta provisional (1xx) de transporte confiable.  No aplica a la respuesta 100 Trying, la cual nunca es confiablemente transportada.  Es generada por un UAC cuando se ha recibido una respuesta provisional conteniendo un número de secuencia confiable (campo de encabezado RSeq). El PRACK hace eco de este número y del CSeq de la respuesta en el campo de encabezado RAck.  Si no se recibe un PRACK tras un tiempo determinado, el mensaje es retransmitido. La recepción de un PRACK confirma la entrega de la respuesta y detiene subsiguientes retransmisiones.  La combinación de Call-ID, CSeq y RAck permite al UAC correlacionar el PRACK con la respuesta provisional que está reconociendo.  El PRACK siempre incrementa el CSeq.  Campos de encabezado mandatorios: Via, To, From, Call-ID, Cseq, Max-Forwards, RAck
  104. 104. Métodos SIP: PRACK
  105. 105. Métodos SIP: PRACK Tras la pérdida de un paquete, la combinación de Call- ID, CSeq y RAck permite al UAC correlacionar el PRACK con la respuesta provisional que está reconociendo.
  106. 106. Métodos SIP: INFO  Monitoreo de la llamada.  Transporta información de señalización de la red telefónica (por ejemplo ISUP, en el cuerpo del mensaje) entre dos UA que han establecido una sesión de medios entre ellos.  Toda solicitud INFO recibirá una respuesta de código 481 Transaction/Dialog Does Not Exist para diálogos desconocidos.  Este método siempre incrementa el número CSeq.  Campos de encabezado mandatorios: Via, To, From, Call-ID, Cseq, Max-Forwards.
  107. 107. Métodos SIP: SUBSCRIBE  Solicita ser notificado sobre un evento particular (a través de un método NOTIFY).  Una suscripción exitosa establece un diálogo entre UA.  El campo de encabezado Expires indica la duración de la suscripción (la cual puede refrescarse mediante otro SUBSCRIBE).  Un UAC debe estar preparado para recibir mensajes NOTIFY (de posibles diferentes UAS) previos a la única respuesta 200 OK posible final.  El tipo de evento de suscripción se establece en el campo de encabezado Event obligatorio del mensaje SUBSCRIBE.  Campos de encabezado mandatorios: Via, To, From, Call-ID, Cseq, Max-Forwards, Contact, Event, Allow-Events
  108. 108. Métodos SIP: NOTIFY  Notifica al agente de usuario de sus capacidades (e.g.: estado offline/online en servicio de presencia/mensajería instantánea).  Siempre es enviado dentro de un diálogo.  Normalmente recibe 200 OK. Si recibe 481 Dialog/Transaction Does Not Exist, la transacción es automáticamente terminada y no se envían más NOTIFY.  Un NOTIFY siempre es enviado al iniciar y al terminar una suscripción.  El campo de encabezado Event indica el nombre de paquete usado en la suscripción, en tanto el campo de encabezado Subscription-State indica el estado actual de la misma.  Campos de encabezado mandatorios: Via, To, From, Call-ID, Cseq, Max-Forwards, Contact, Event, Allow-Events, Subscription-State
  109. 109. Métodos SIP: SUBSCRIBE / NOTIFY
  110. 110. Métodos SIP: OPTIONS  Solicita información a un agente de usuario o servidor sobre sus capacidades (e.g.: mensajes y Códecs soportados).  Una respuesta de código 2xx puede contener los encabezados Allow, Accept, Accept-Encoding, Accept- Language y Supported indicando las capacidades.  Tags como audio, video o isfocus debieran incluirse en el campo de encabezado Contact.  Nunca es enviado por un proxy (aunque la solicitud sí puede ser para él).  Campos de encabezado mandatorios: Via, To, From, Call-ID, Cseq, Max-Forwards.
  111. 111. Métodos SIP: PUBLISH  Utilizado por un UA para enviar información de estado de evento a un servidor conocido como ESC (Event State Compositor).  Ante un PUBLISH, el ESC genera NOTIFY a elementos “observadores”.  A diferencia de NOTIFY, PUBLISH no es enviado en un diálogo SIP.  La respuesta 200 OK contiene información del evento de información generada por el ESC, la cual va contenida en el campo de encabezado SIP-ETag. Esta información puede utilizarse por el UA para actualizar la información publicada.  Campos de encabezado mandatorios: Via, To, From, Call-ID, Cseq, Max-Forwards, Contact, Event, Allow-Events, Expires, Min-Expires.
  112. 112. Métodos SIP: PUBLISH
  113. 113. Métodos SIP: UPDATE  Modifica el estado de una sesión sin modificar el estado del diálogo SIP.  Ninguna de las partes de una sesión puede re-invitar a la otra en una sesión pendiente (INVITE enviado pero sin respuesta recibida): para esto se usa UPDATE.  Usos de UPDATE incluyen poner una llamada en espera, renegociar QoS u otra negociación de atributos de estado end-to-end previa al establecimiento de la sesión.  Campos de encabezado mandatorios: Via, To, From, Call-ID, Cseq, Max-Forwards, Contact.
  114. 114. Métodos SIP: UPDATE
  115. 115. Métodos SIP: MESSAGE  Usado para transportar un mensaje instantáneo (IM) vía SIP.  No necesitan un diálogo para ser enviados, así como tampoco establecen un diálogo SIP por sí mismos.  El contenido del mensaje es enviado en el cuerpo del mensaje como un adjunto MIME.  Es obligatorio para un UA soportar el formato plain/text para este método (otros como text/html o message/cpim pueden soportarse).  Un mensaje de repuesta en una conversación no se envía en un mensaje 200 OK, sino en otro mensaje MESSAGE.  Campos de encabezado mandatorios: Via, To, From, Call-ID, Cseq, Max-Forwards.
  116. 116. Métodos SIP: MESSAGE
  117. 117. Métodos SIP: REFER  Instruye a un UA a enviar una solicitud de acceso a una URI o URL identificada en el campo de encabezado Refer- To.  Muy utilizado para transferir llamadas (cuando URI es sip o sips) u obtener una página Web.  Puede utilizarse dentro o fuera de un diálogo SIP.  No usa la máquina de estados INVITE (el UAS responde con 202 Accepted sin esperar a que se complete la solicitud enviada).  Campos de encabezado mandatorios: Via, To, From, Call-ID, Cseq, Max-Forwards, Refer-To.
  118. 118. Método SIP: REFER Transferencia de llamada.
  119. 119. Método SIP: REFER «GET» de página WEB.
  120. 120. Método SIP: REFER Transferencia de llamada con terminación desde el agente de usuario objetivo de la transferencia.
  121. 121.  Voz sobre IP (VoIP)  Introducción.  Principales componentes.  Códecs y protocolos.  Funcionamiento y arquitecturas.  Factores que afectan la calidad de voz.  Telefonía e Internet.  Protocolo de Inicio de Sesión: SIP  Definiciones y Arquitectura.  Métodos/Mensajes/Transacciones SIP.  Internetworking con redes legadas de circuitos conmutados.  Plano de Usuario en Telefonía IP: RTP/RTCP.  Descripción General.  Formato del paquete RTP.  Protocolo de Control RTP: RTCP.  Formato del paquete RTCP.  Protocolo AAA: Diameter.  Generalidades del protocolo.  Arquitectura Diameter.  Sesiones Diameter.  Comandos básicos.  Funciones AAA.
  122. 122. Internetworking con Redes Legadas CS
  123. 123. Flujo de llamada de voz exitosa entre Redes TDM – Redes IP Internetworking con Redes Legadas CS
  124. 124. Flujo de llamada de voz fallida entre Redes IP – Redes TDM Internetworking con Redes Legadas CS
  125. 125. Internetworking con Redes Legadas CS Reglas de Mapeo ISUP – SIP Elemento de información en ISUP IAM Encabezado en SIP INVITE Called Party Number Request URI To Calling Party Number (CgPN) P-asserted-entity From (si no existen CgPN adicionales –A-CgPN- en ISUP IAM) Privacy Additional calling party number (A-CgPN) From Hop counter Max-Forwards R. Noldus et al (2011)
  126. 126.  El interworking de video entre una red IP (e.g.: IMS) y redes de circuitos conmutados (e.g.: ISDN) requieren de MGCF y MGW con soporte de vídeo (Video Gateway).  Esta necesidad surge desde que en redes CS, la negociación de características de codificación de video y códec de video suceden en el plano de usuario en oposición al plano de control, como se muestra a continuación: R. Noldus et al (2011) Internetworking con Redes Legadas CS: Video llamada
  127. 127.  Para interworking en un Video Gateway se identifican dos asuntos a considerar: 1. Los flujos de datos transportados sobre el plano de usuario en la red de conmutación de circuitos o CS pasará por un tratamiento diferente en el MGW; algunos flujos de datos son reenviados hacia la red IP sobre RTP (plano de usuario o medios), en tanto otros flujos de datos serán reenviados al MGCF para su uso en el establecimiento de llamada SIP (plano de control o señalización); 2. El campo SDP offer a incluirse por el MGCF en el método SIP INVITE estará basado en la configuración en el MGCF; SDP puede ser actualizado tras el establecimiento de la llamada. R. Noldus et al (2011) Internetworking con Redes Legadas CS: Video llamada
  128. 128. Flujo de señalización de video llamada entre Redes TDM – Redes IP Internetworking con Redes Legadas CS
  129. 129.  Voz sobre IP (VoIP)  Introducción.  Principales componentes.  Códecs y protocolos.  Funcionamiento y arquitecturas.  Factores que afectan la calidad de voz.  Telefonía e Internet.  Protocolo de Inicio de Sesión: SIP  Definiciones y Arquitectura  Métodos/Mensajes/Transacciones SIP.  Internetworking con redes legadas de circuitos conmutados.  Plano de Usuario en Telefonía IP: RTP/RTCP.  Descripción General.  Formato del paquete RTP  Protocolo de Control RTP: RTCP.  Formato del paquete RTCP.  Protocolo AAA: Diameter.  Generalidades del protocolo.  Arquitectura Diameter.  Sesiones Diameter.  Comandos básicos.  Funciones AAA.
  130. 130. Características TCP / SCTP UDP / DCCP IP RTPH.323 SIPH.248 RTCP Plano de Control: Señalización Plano de Usuario: Medios (Audio, Vídeo) BICC
  131. 131. Descripción General  RTP (Real-time Transport Protocol, especificado en IETF RFC 3550) permite el transporte en tiempo real de información de medios tales como audio y vídeo.  RTP no reserva recursos ni garantiza la calidad para servicios en tiempo real.  Dado que prioriza la velocidad a la entrega completa de la información o calidad de servicio, RTP utiliza protocolos de transporte «no confiables» como UDP o DCCP.  Siempre es utilizado en conjunto con RTCP (RTP Control Protocol), el cual provee estadísticas de calidad de servicio e información para sincronización interna de medios. Ambos están diseñados para funcionar independientemente de las redes y transportes subyacentes.
  132. 132. Descripción General  Dado que las redes IP no mantienen relación de los datos transportados, esto es, introducen jitter, el propósito principal de RTP es permitir a los receptores reproducir la información de medios al ritmo apropiado. En otras palabras, en el caso de dos paquetes enviados al mismo destino separados en el tiempo de envío por exactamente N ms, nada asegura que el segundo paquete arribe al destino N ms después del primero (de hecho el segundo paquete podría arribar antes que el primero, mucho tiempo antes, o después, o al mismo tiempo).  Consecuentemente, los receptores no pueden confiar en los tiempos de arribo de los paquetes.  De modo de recobrar la relación de tiempos de la información de medios, se utilizan marcas o «RTP timestamps».
  133. 133. Descripción General  Los receptores ubican paquetes RTP en la memoria buffer de acuerdo a sus «timestamps» y comienzan a reproducirlos.  Si un paquete con una marca particular necesita ser reproducido y aún no ha arribado, el receptor utiliza técnicas de interpolación de modo de llenar el vacío (por ejemplo, en el caso de audio, podría reproducir el último paquete de audio por un tiempo mayor). En caso de recibirse este paquete después, el mismo es descartado.  La figura muestra unos paquetes en un buffer. El paquete con «timestamp 40» no ha arribado aún. El mismo será descartado en caso de arribar tiempo después del momento en que requería reproducirse. Camarillo, García-Martín (2008)
  134. 134. Descripción General  El receptor de la figura anterior necesita realizar una decisión importante: cuándo comenzar a reproducir los medios al usuario. Se enfrenta a una solución de compromiso, ambas con sus riesgos, esto es: a) Si comienza de inmediato, al tiempo de recibir el primer paquete, corre el riesgo de perder calidad a posteriori por pérdida de paquetes; b)Si espera un tiempo para comenzar la reproducción, el retardo puede llegar a ser tan grande que los usuarios terminarían inhabilitados de mantener una conversación normal (el buffer debería aumentarse para compensar esto).  Existen entonces diferentes implementaciones las cuales utilizan diferentes criterios para decidir la longitud de sus buffers:  Los buffers grandes mejoran la calidad de la conversación, pero como contrapartida, aumentan los retardos.  Los buffers pequeños disminuyen los retardos en detrimento de la calidad de la conversación.
  135. 135. Descripción General La figura muestra el retardo experimentado por una ráfaga de paquetes entre transmisor y receptor. En este ejemplo, la mayoría de los paquetes experimentan un retraso de alrededor de 50 ms, algunos más que eso, otros menos. Una aceptable solución de compromiso para este ejemplo sería que el receptor comenzara a reproducir los paquetes 100 ms después de su envío. De esta forma, sólo una pequeña porción de los paquetes recibidos, los que aparecen en la cola de la distribución (de muy alto retardo), serían descartados al momento de su arribo. Camarillo, García-Martín (2008)
  136. 136. Descripción General En adición a los timestamps, los paquetes RTP pueden transportar números de secuencia (pero no para retransmisión!!!). Los receptores los utilizan de modo de comprender cuántos de estos paquetes se pierden en la red durante la transmisión. Si la red pierde demasiados paquetes en un tiempo particular, los pares pueden decidir utilizar un códec diferente que provea una mejor calidad bajo condiciones de alta pérdida (esto es, un códec con mayor redundancia). Números que siempre se corresponden con el mismo códec refieren a tipos fijos de carga útil («payload»). Por ejemplo, «payload type 0» corresponde a Códec de audio G.711 según ley μ, en tanto «payload type 31» corresponde al Códec de vídeo H.261. La especificación IETF RFC 3551 define algunos de los tipos fijos de carga útil de audio y vídeo.
  137. 137. Descripción General Los tipos de payload dinámicos típicamente son negociados mediante el modelo oferta/respuesta. Identifican un códec particular para una sesión particular. La descripción SDP de sesión a continuación contiene un flujo de audio que puede codificarse mediante Códec de audio G.711 según ley μ (0), o utilizando un códec estéreo lineal de 16 bits a 16 KHz (tipo de carga útil dinámica «98», especificada en la línea a=rtpmap). El receptor de este flujo de audio recibirá paquetes RTP cuyos tipos de payload serán 0 o 98 y, basado en esta descripción de sesión SDP, los decodificará. v=0 o=Alice 2790844676 2867892807 IN IP4 192.0.0.1 s=Let’s talk c=IN IP4 192.0.0.1 t=0 0 m=audio 20000 RTP/AVP 0 98 a=rtpmap:98 L16/16000/2 Camarillo, García-Martín (2008)
  138. 138.  Voz sobre IP (VoIP)  Introducción.  Principales componentes.  Códecs y protocolos.  Funcionamiento y arquitecturas.  Factores que afectan la calidad de voz.  Telefonía e Internet.  Protocolo de Inicio de Sesión: SIP  Definiciones y Arquitectura  Métodos/Mensajes/Transacciones SIP.  Internetworking con redes legadas de circuitos conmutados.  Plano de Usuario en Telefonía IP: RTP/RTCP.  Descripción General.  Formato del paquete RTP.  Protocolo de Control RTP: RTCP.  Formato del paquete RTCP.  Protocolo AAA: Diameter.  Generalidades del protocolo.  Arquitectura Diameter.  Sesiones Diameter.  Comandos básicos.  Funciones AAA.
  139. 139. Paquete RTP La figura muestra todos los encabezados de un paquete RTP transportando una muestra de audio. El protocolo de transporte utilizado en este ejemplo es UDP. Camarillo, García-Martín (2008)
  140. 140. Encabezado RTP La figura muestra el formato del encabezado RTP. IETF RFC 3550
  141. 141. Encabezado RTP: Campos A continuación se describen los campos del encabezado RTP. IETF RFC 3550  Version (V): 2 bits. Identifica la versión del protocolo RTP. Para IETF RFC 3550, este valor es “2”.  Padding (P): De estar seteado (puesto en 1) el bit P, el paquete contiene uno o más octetos de relleno adicionales. El último octeto del relleno (padding) contiene una cuenta de cuantos octetos de rellenos deben ignorarse, incluyendo él mismo. El relleno puede necesitarse por algunos algoritmos de encriptado para bloques de tamaño fijo o para transportar múltiples paquetes RTP en una unidad de datos de protocolo de capa menor.  Extension (X): De estar seteado el bit X, el encabezado fijo debe ser seguido por exactamente una extensión de encabezado .  CSRC Count (CC): 4 bits. Contiene la cantidad de identificadores CSRC que prosiguen al encabezado fijo.
  142. 142. Encabezado RTP: Campos IETF RFC 3550  Marker (M): 1 bit. La interpretación del bit marcador es definido por un perfil. Se intenta permitir a eventos significativos tales como fronteras de trama a ser marcadas en el flujo del paquete. Un perfil puede definir bits de marcado adicional o especificar que no existe bit de marcado cambiando el número de bits en el campo de tipo de carga útil o «Payload Type (PT)».  Payload Type (PT): 7 bits. Este campo identifica el formato de la carga útil RTP y determina su interpretación por la aplicación. Un perfil puede especificar un mapeo estático por defecto de códigos de tipos de payload a formatos de payload. Códigos de tipo de payload adicionales pueden definirse dinámicamente vía métodos no-RTP. RFC 3551 define un set de mapeos por defecto para audio y vídeo. Una fuente RTP puede variar el tipo de payload durante una sesión, pero este campo no debiera utilizarse para multiplexar flujos de medios separados.  Sequence Number: 16 bits. Número que es incrementado por 1 para cada paquete enviado, ergo, puede ser utilizado por el receptor de modo de detectar pérdida de paquetes y restaurar la secuencialidad. El valor inicial debe ser randómico, de modo de prevenir ataques (aumentar la seguridad).
  143. 143. Encabezado RTP: Campos IETF RFC 3550  Timestamp: 32 bits. El timestamp refleja el instante de muestreo del primer octeto en el paquete RTP. El instante de muestreo debe derivarse de un reloj que incremente en forma monótona y linealmente a tiempo para permitir sincronismo y cálculos de jitter. Como para el número de secuencia, el valor inicial del timestamp debe ser azaroso. Timestamps de diferentes flujos pueden avanzar a diferentes tasas y tener corrimientos independientes, azarosos. Por tanto, si bien son suficientes para reconstruir el sincronismo de un flujo único, la comparación directa de timestamps no es efectiva para el sincronismo de medios diferentes. En cambio, para cada medio el timestamp se relaciona al instante de muestreo mediante el emparejamiento de sí mismo con un timestamp de un reloj de referencia que represente el tiempo de cuando los datos correspondientes al timestamp fueron muestreados.
  144. 144. Encabezado RTP: Campos IETF RFC 3550  SSRC Identifier: 32 bits. Identifica la fuente de sincronismo. Debiera elegirse al azar (mediante algoritmos), de modo que no existan en la misma sesión RTP dos fuentes de sincronismo con el mismo identificador SSRC. A pesar de que los algoritmos de generación de este identificador aseguran una probabilidad muy baja de repetición, toda implementación RTP debe estar preparada para detectar y resolver colisiones. Si una fuente cambia su dirección de fuente de transporte, debe modificar su identificador SSRC de modo de evitar ser interpretada como una fuente en bucle.
  145. 145. Encabezado RTP: Campos IETF RFC 3550  CSRC Identifier: 0 a 15 ítems, 32 bits c/u. Identifica las fuentes contribuyentes de la carga útil contenida en el paquete. La cantidad de identificadores CSRC viene dado por el campo CC. En caso de existir más de 15 fuentes contribuyentes, sólo 15 de ellas pueden ser identificadas. Los identificadores CSRC son insertados por mezcladores utilizando los identificadores SSRC de las fuentes contribuyentes. Por ejemplo, para paquetes de audio, los identificadores SSRC de todas las fuentes que fueron conjuntamente mezcladas para crear un paquete son listadas, permitiendo en el receptor indicación del comunicante apropiado.
  146. 146.  Voz sobre IP (VoIP)  Introducción.  Principales componentes.  Códecs y protocolos.  Funcionamiento y arquitecturas.  Factores que afectan la calidad de voz.  Telefonía e Internet.  Protocolo de Inicio de Sesión: SIP  Definiciones y Arquitectura  Métodos/Mensajes/Transacciones SIP.  Internetworking con redes legadas de circuitos conmutados.  Plano de Usuario en Telefonía IP: RTP/RTCP.  Descripción General  Formato del paquete RTP  Protocolo de Control RTP: RTCP.  Formato del paquete RTCP.  Protocolo AAA: Diameter.  Generalidades del protocolo.  Arquitectura Diameter.  Sesiones Diameter.  Comandos básicos.  Funciones AAA.
  147. 147. Descripción General  RTCP siempre es utilizado con RTP (de hecho, están ambos especificados por la misma norma IETF RFC 3550).  Provee información bidireccional de estadísticas de calidad de servicio, información para realización de sincronización inter-medios y mapeos entre identificadores binarios de envío RTP y nombres humanamente legibles (útil en conferencias donde los medios de todos los participantes es recibido en la misma dirección de transporte)  La generación de estadísticas de calidad de servicio (o tasa de pérdida de paquetes durante una sesión RTP) requiere que, mediante RTCP, los transmisores RTP reporten la cantidad de paquetes enviados a la red y, los receptores RTP, la cantidad de paquetes recibidos. Camarillo, García-Martín (2008)
  148. 148. Descripción General  Para una fuente RTP, RTCP transporta un identificador persistente a nivel de transporte denominado CNAME («Canonical Name»). Desde que el identificador SSRC puede modificarse ante un conflicto o reinicio de una aplicación, los receptores requieren este CNAME para seguir identificando a cada participante.  Los receptores también pueden requerir el CNAME para asociar flujos de medios múltiples desde un determinado participante en un conjunto de sesiones RTP relacionadas, por ejemplo, para sincronizar audio y video. El sincronismo inter-medios también requiere de timestamps NTP y RTP incluidos por los originantes en paquetes RTCP. Entonces, RTCP provee un mapeo entre los timestamps de sus flujos de medios y un reloj de referencia (wall-clock). Así, los receptores pueden sincronizar la reproducción de diferentes flujos. IETF RFC 3550
  149. 149. Descripción General Dado que las frecuencias de reloj usadas para los timestamps de diferentes flujos de medios pueden ser distintas y el valor inicial de los timestamps aleatorio, referencias a un wall-clock son necesarias. Entonces, sólo mediante inspección de los timestamps entre dos flujos de medios, es imposible determinar qué muestras deben reproducirse al mismo tiempo. Camarillo, García-Martín (2008) La figura muestra cómo los mapeos RTCP realizan esta sincronización inter-medios.
  150. 150. Descripción General  Cuando SDP es utilizado, los paquetes RTP normalmente son enviados por un puerto con un número par, en tanto los mensajes RTCP se envían al puerto impar consecutivo. Por ejemplo, la descripción de sesión mostrada debajo, expone la recepción de paquetes RTP transportando muestras de audio sobre UDP en el puerto 20000, en tanto los paquetes RTCP relacionados a este flujo de audio se reciben vía UDP en el puerto 20001(información implícita). Camarillo, García-Martín (2008) v=0 o=Alice 2790844676 2867892807 IN IP4 192.0.0.1 s=Let’s talk c=IN IP4 192.0.0.1 t=0 0 m=audio 20000 RTP/AVP 0 98 a=rtpmap:98 L16/16000/2
  151. 151.  Voz sobre IP (VoIP)  Introducción.  Principales componentes.  Códecs y protocolos.  Funcionamiento y arquitecturas.  Factores que afectan la calidad de voz.  Telefonía e Internet.  Protocolo de Inicio de Sesión: SIP  Definiciones y Arquitectura  Métodos/Mensajes/Transacciones SIP.  Internetworking con redes legadas de circuitos conmutados.  Plano de Usuario en Telefonía IP: RTP/RTCP.  Descripción General  Formato del paquete RTP  Protocolo de Control RTP: RTCP.  Formato del paquete RTCP.  Protocolo AAA: Diameter.  Generalidades del protocolo.  Arquitectura Diameter.  Sesiones Diameter.  Comandos básicos.  Funciones AAA.
  152. 152. Formato del paquete RTCP La especificación define múltiples tipos de paquetes RTCP para el transporte de una variedad de información:  SR (Sender Report): Reporte de transmisor para estadísticas de transmisión y recepción de participantes que transmiten activamente.  RR (Receiver Report): Reporte de receptor para estadísticas de recepción de participantes que no transmiten activamente, y en combinación con SR, para transmisores activos reportando para más de 30 fuentes.  SDES (Source Description): Ítems de descripción de fuente, incluido CNAME.  BYE: Indica fin de transmisión.  APP: Funciones específicas de aplicación. IETF RFC 3550
  153. 153. Formato del paquete RTCP  Cada paquete RTCP comienza con una sección fija seguida de elementos estructurados que pueden ser de longitud variable de acuerdo al tipo de paquete, pero deben terminar con una frontera de 32 bits.  El requisito de alineamiento más un campo de longitud en la sección fija de cada paquete son incluidas para hacer apilables o «stackable» a los paquetes RTCP.  Múltiples paquetes RTCP pueden concatenarse sin necesidad de separadores, de modo de componer un paquete RTCP que es enviado en un paquete singular del protocolo de capa inferior (e.g.: UDP).  No existe una cuenta explícita de los paquetes RTCP individuales en el paquete compuesto desde que se espera que los protocolos de capa inferior provean de una longitud global para determinar el fin del paquete compuesto. IETF RFC 3550
  154. 154. Formato del paquete RTCP  Se recomienda que traductores y mezcladores combinen paquetes RTCP que reenvían desde las múltiples fuentes en un paquete compuesto siempre que sea posible de forma de amortizar el overhead.  La figura debajo muestra un ejemplo de paquete compuesto producido por un mezclador. Si la longitud total del paquete compuesto excediese la máxima unidad de transmisión (MTU) del trayecto de transmisión, debería segmentarse en múltiples paquetes compuestos menores a ser transmitidos en paquetes separados del protocolo subyacente. Esto no menoscaba la estimación del ancho de banda dado que cada paquete compuesto representa al menos a un participante específico.  Cada paquete compuesto debe comenzar con un paquete SR o RR. IETF RFC 3550
  155. 155. Características  SRTP (IETF RFC 3711) provee confidencialidad, autenticación y protección de repetición al tráfico RTP y RTCP. La figura muestra las secciones de un paquete RTP autenticadas y las encriptadas.  Pares usando SRTP para el intercambio de información utilizan una protocolo de gestión de clave de modo de generar una clave maestra, la cual es utilizada para generar claves de sesión. Las claves de sesión son periódicamente refrescadas por seguridad, de modo que potenciales atacantes no tengan acceso a grandes volúmenes de tráfico encriptados bajo la misma clave. Camarillo, García-Martín (2008)
  156. 156.  Voz sobre IP (VoIP)  Introducción.  Principales componentes.  Códecs y protocolos.  Funcionamiento y arquitecturas.  Factores que afectan la calidad de voz.  Telefonía e Internet.  Protocolo de Inicio de Sesión: SIP  Definiciones y Arquitectura.  Métodos/Mensajes/Transacciones SIP.  Internetworking con redes legadas de circuitos conmutados.  Plano de Usuario en Telefonía IP: RTP/RTCP.  Descripción General.  Formato del paquete RTP.  Protocolo de Control RTP: RTCP.  Formato del paquete RTCP.  Protocolo AAA: Diameter.  Generalidades del protocolo y Arquitectura Diameter.  Sesiones Diameter.  Formato del mensaje Diameter.  Comandos básicos.  Funciones AAA.
  157. 157. Plano de Usuario: Medios (Audio, Vídeo) Plano de Control: Señalización AAA Protocolos de Aplicación/Transporte/Red para Planos de Control/Usuario/AAA en VoIP TCP / SCTP UDP / DCCP IP RTP/RTCPH.323 SIPH.248 BICC Diameter RADIUS
  158. 158. Generalidades  Diameter es un protocolo codificado en formato binario especificado por IETF RFC 6733. Está explicitado como un protocolo base más un set de aplicaciones que complementan sus funcionalidades primigenias. El protocolo base Diameter es implementado en todos los nodos Diameter, independientemente de cualquier aplicación específica.  Las aplicaciones comprenden extensiones de la funcionalidad básica y están diseñadas para usos específicos del protocolo básico en un contexto particular. El hecho de que sean extensiones permite escalabilidad en el desarrollo de nuevas aplicaciones de ser necesarias. Estas aplicaciones Diameter comprenden funcionalidades de nodos/interfaces cada vez más numerosos de telefonía sobre IP, como por ejemplo, las adaptaciones para configuraciones de servidor de acceso de red o NAS (Network Access Server), control de crédito, SIP, aplicaciones móviles, servicios de localización, etc.
  159. 159. Generalidades  Diameter no es el típico protocolo de tipo cliente/servidor sino más bien, un protocolo de comunicación entre pares o «peer-to-peer». Entonces, cualquier nodo Diameter puede enviar una solicitud en forma asíncrona a su par.  A diferencia de lo que sucede con protocolos de tipo cliente/servidor como SIP, el nodo cliente o «Diameter Client» no constituye la entidad funcional que envía una solicitud, en tanto un nodo servidor o «Diameter Server» tampoco constituye la entidad funcional que responde a la solicitud.  En cambio, en Diameter, tanto el nodo cliente como el servidor pueden transmitir solicitudes y respuestas. El nodo cliente o «Diameter Client» es una entidad funcional que realiza control de acceso, en tanto el nodo servidor o «Diameter Server» es la entidad que realiza la autenticación y autorización.
  160. 160. Generalidades Los mensajes Diameter componen solicitudes y respuestas al mismo tiempo. Una solicitud es contestada por una única respuesta. Las solicitudes Diameter, (salvo raras excepciones), son siempre respondidas. En caso de falla o error, el transmisor puede recuperar un determinado estado con facilidad en base a la respuesta recibida, contenedora de información precisa pertinente al motivo de la solicitud.
  161. 161. Generalidades de Transporte en Diameter  Diameter utiliza protocolos de transporte confiables que ofrezcan control de congestión como TCP y/o SCTP (sobre el puerto 3868 asignado por IANA). En otras palabras, Diameter, a diferencia de RADIUS (protocolo AAA del cual evolucionó Diameter), no es transportado por protocolos no confiables como UDP o DCCP.  Los mensajes Diameter perdidos son entonces retransmitidos en cada salto. Incluso, Diameter provee un mensaje «heartbeat» a nivel de aplicación de modo de monitorear el estado de la conexión y permitir la recuperación de la misma ante fallas.  Diameter también permite el enrutamiento de mensajes de control de crédito a servidores alternativos, de acuerdo a los mensajes previos de autenticación/autorización. IANA: Internet Assigned Numbers Authority
  162. 162. Generalidades de Transporte en Diameter  El perfil de transporte Diameter se define en [RFC 3539]. El protocolo Diameter base utiliza el puerto 3868 tanto para TCP [RFC 793] como SCTP [RFC 4960].  Para TLS [RFC 5246] y DTLS (Datagram Transport Layer Security) [RFC 6347], un nodo Diameter debe iniciar una conexión en el puerto 5868 previo a cualquier intercambio de mensajes. Se asume que TLS corre sobre de TCP cuando es usado, en tanto DTLS sobre SCTP.  Por motivos de retro-compatibilidad con nodos Diameter según [RFC 3588], en caso de que estos no puedan recibir TLS/TCP y DTLS/SCTP en el puerto 5658), entonces el iniciador puede revertir a utilizar TCP o SCTP en el puerto 3868.
  163. 163. Arquitectura Diameter: Entidades funcionales Diameter Client. Entidad funcional, típicamente ubicada en la frontera de una red para control de acceso. Ejemplos de esta entidad Diameter son los NAS («Network Access Servers») y los agentes de movilidad en IP Móvil o FA («Mobile IP Foreign Agents»). Diameter Server. Entidad funcional que maneja solicitudes de autenticación, autorización y contabilidad (AAA) para un dominio particular. Soporta aplicaciones de servidor por sobre el protocolo base, así como debiera soportar conexiones tanto sobre TCP como SCTP .
  164. 164. Arquitectura Diameter: Entidades funcionales  Realm. Corresponde a un dominio administrativo. Se corresponde con la cadena de caracteres que prosigue a «@» en el campo NAI («Network Address Indicator», IETC RFC 4282). NAI es utilizado por Diameter para extraer la información de identidad y dominio de usuario durante el proceso de autenticación y/o autorización, mientras el dominio es utilizado únicamente con propósitos de enrutamiento. Los nombres de dominio NAI son necesariamente únicos y superpuestos en la administración de espacio de nombres del DNS. Diameter hace uso del dominio o «Realm» (también referido como «Domain»), de forma de determinar si los mensajes pueden satisfacerse localmente o si deben enrutarse o redireccionarse.  Home Realm. Corresponde al dominio con el cual el usuario mantiene una relación de contabilidad.  Local Realm. Corresponde al dominio administrativo que provee servicios a un usuario. Puede actuar como «Local Realm» para algunos usuarios en tanto como «Home Realm» para otros.
  165. 165. Arquitectura Diameter: Entidades funcionales  Proxy. Entidad funcional encargada primariamente de reenviar mensajes Diameter. Adicionalmente, puede modificar los mensajes en base a un set de políticas que conllevan decisiones relacionadas a utilización de recursos, control de admisión y aprovisionamiento. Típicamente, esto es realizado mediante seguimiento del estado de dispositivos NAS. En tanto normalmente los proxis no responden a solicitudes de clientes previamente a recibir mensajes desde un servidor, pueden originar mensajes de rechazo en casos donde las políticas son violadas (por lo que deben comprender la semántica de todos los mensajes que los atraviesan, y no siempre soportan todas las aplicaciones).  Relay. Entidad funcional que reenvía mensajes Diameter basada en información relativa a enrutamiento y entradas de tablas de enrutamiento de dominios. Un relevo es típicamente transparente en la comunicación. Puede modificar mensajes Diameter únicamente mediante la inserción o remoción de datos relacionados a direccionamiento, pero no puede en cambio modificar otro tipo de información. No guardan estado de sesiones o recursos NAS.
  166. 166. Arquitectura Diameter: Entidades funcionales  Redirect Agent. Entidad funcional que refiere clientes a servidores y les permite comunicarse directamente. No alteran AVP alguno en tránsito entre cliente y servidor, desde que no se ubican en el trayecto de reenvío. No originan mensajes y soportan cualquier tipo de mensajes, a pesar de que sólo pueden estar configurados para redireccionar ciertos tipos solamente, en tanto actuar como relevo o proxy para otros tipos. No guardan estado de sesiones o recursos NAS.  Translation Agent. Entidad funcional que realiza traducción de protocolo entre el protocolo Diameter y otros protocolos AAA como por ejemplo, RADIUS.  Diameter Node. Entidad funcional que implementa el protocolo Diameter y actúa como Diameter Client, Diameter Server, Proxy, Relay, Redirect Agent o Translation Agent.
  167. 167. Direcciones AAA: AAA /AAAS URI Los protocolos AAA están habilitados para utilizar una URI «aaa» o «aaas» (con transporte seguro según TLS/TCP o DTLS/SCTP) para identificar recursos. La sintaxis de estas URI es: "aaa://" FQDN [ port ] [ transport ] [ protocol ] "aaas://" FQDN [ port ] [ transport ] [ protocol ] (FQDN: Fully Qualified Domain Name) Las URI pueden contener un número de puerto, protocolo de transporte y protocolo AAA opcionales para acceder al recurso deseado. El puerto por defecto es asumido en caso de estar ausente (3868 en Diameter). El protocolo de transporte por defecto en Diameter es SCTP, por lo que es el asumido de estar ausente en la URI. El parámetro [protocol] por defecto es Diameter, por lo que es el asumido de estar ausente. Ejemplos de URI aaa o aaas: aaas://host.ex.net aaa://host.ex.org:5658;transport=tcp;protocol=diameter aaa://accserver.ex.net:1813;transport=udp;protocol=radius aaa://server.ex.net:49;transport=tcp;protocol=tacacs+ aaa://aaaserver.ex.net
  168. 168.  Voz sobre IP (VoIP)  Introducción.  Principales componentes.  Códecs y protocolos.  Funcionamiento y arquitecturas.  Factores que afectan la calidad de voz.  Telefonía e Internet.  Protocolo de Inicio de Sesión: SIP  Definiciones y Arquitectura.  Métodos/Mensajes/Transacciones SIP.  Internetworking con redes legadas de circuitos conmutados.  Plano de Usuario en Telefonía IP: RTP/RTCP.  Descripción General.  Formato del paquete RTP.  Protocolo de Control RTP: RTCP.  Formato del paquete RTCP.  Protocolo AAA: Diameter.  Generalidades del protocolo y Arquitectura Diameter.  Sesiones Diameter.  Formato del mensaje Diameter.  Comandos básicos.  Funciones AAA.
  169. 169. Sesiones Diameter  Análogamente a las sesiones multimedia del plano de control basadas en SIP/SDP, la especificación Diameter también aborda el concepto de sesión, pero con un significado más amplio.  De acuerdo a IETF RFC 6733: «Una sesión Diameter es una consecución de eventos relacionados dedicados a una actividad específica. La documentación de las aplicaciones Diameter proveen los lineamientos de inicio y fin de sesión. Todos los paquetes Diameter con el mismo identificador de sesión o «Session-Id» son considerados parte de la misma sesión».
  170. 170. Sesiones Diameter  Ejemplos de una sesión Diameter:  En el contexto de un usuario que marca hacia un servidor de acceso de red o NAS, la sesión se compone de todos los mensajes Diameter intercambiados entre el NAS y el servidor Diameter desde el momento que usuario marca hasta que la conexión se interrumpe.  En el contexto del IMS (IP Multimedia Subsystem), una sesión Diameter puede estar compuesta de todos los mensajes intercambiados entre el servidor proxy SIP denominado S- CSCF (Serving - Call Session Call Function) actuando como Diameter Client, y el servidor base de datos de localización de suscripción o HSS (Home Subscriber Server) actuando como Diameter Server, durante el tiempo en que el usuario se encuentra registrado. Camarillo, García-Martín (2008)
  171. 171. Conexiones vs. Sesiones Diameter  Una conexión Diameter refiere a un enlace a nivel de transporte entre dos pares, la cual es utilizada para enviar y recibir mensajes Diameter.  Una sesión Diameter en cambio es el concepto lógico que existe a nivel de capa de aplicación entre el cliente y servidor Diameter, la cual es identificada mediante el AVP identificador de sesión o «Session-Id AVP».
  172. 172. Conexiones vs. Sesiones Diameter  Cada usuario de un servicio provoca una solicitud de autorización a ser enviada con una identificación de sesión unívoca. Una vez aceptada por el servidor, tanto el servidor como el cliente están conscientes de la sesión establecida entre ellos, más allá de las conexiones entre pares intermedias.  Es importante anotar que no existe relación entre conexión y sesión, en tanto los mensajes Diameter para múltiples sesiones son todos multiplexados a través de una única conexión. También anotar que los mensajes pertenecientes a una sesión, tanto los específicos de aplicación como los del protocolo Diameter base, deben transportar el identificador de aplicación o «Application Id». Los mensajes pertenecientes al establecimiento y mantenimiento de conexión entre pares transportan como identificador de aplicación el valor cero o Application-Id=0.
  173. 173.  Voz sobre IP (VoIP)  Introducción.  Principales componentes.  Códecs y protocolos.  Funcionamiento y arquitecturas.  Factores que afectan la calidad de voz.  Telefonía e Internet.  Protocolo de Inicio de Sesión: SIP  Definiciones y Arquitectura.  Métodos/Mensajes/Transacciones SIP.  Internetworking con redes legadas de circuitos conmutados.  Plano de Usuario en Telefonía IP: RTP/RTCP.  Descripción General.  Formato del paquete RTP.  Protocolo de Control RTP: RTCP.  Formato del paquete RTCP.  Protocolo AAA: Diameter.  Generalidades del protocolo y Arquitectura Diameter.  Sesiones Diameter.  Formato del mensaje Diameter.  Comandos básicos.  Funciones AAA.
  174. 174. Formato del mensaje Diameter • Un mensaje Diameter consiste de un encabezado de 20 octetos y una cantidad variable de contenedores datos de información denominados pares de atributos de valor o AVP («Attribute-Value Pairs»). • La cantidad de AVP depende del mensaje Diameter en sí; típicamente contienen datos de autenticación, autorización y contabilidad (AAA).
  175. 175. Formato del Mensaje Diameter  El encabezado Diameter se divide en campos, descriptos a continuación: Version: Indica la versión del protocolo Diameter correspondiente al mensaje. Según IETF RFC 6733, este valor debe ser seteado al valor «1». Message Length: Indica en tres octetos la longitud del mensaje incluyendo los campos de encabezados y los AVP embebidos en él. Por lo tanto, este valor es siempre un múltiplo de 4.
  176. 176. Formato del Mensaje Diameter  Command Flags: Comprende un campo de 8 bits asignados de la siguiente forma: R (Request): en caso de estar seteado a 1, el mensaje es una solicitud; en caso contrario, el mensaje es una respuesta. P (Proxiable): en caso de estar seteado a 1, el mensaje está habilitado para ser reenviado por un proxy; en caso contrario, debe ser procesado localmente. E (Error): en caso de estar seteado a 1, el mensaje contiene un error de protocolo y el mensaje no será conforme al formato de código de comando descripto para el mismo. Este bit no debe setearse a 1 en comandos de solicitud.
  177. 177. Formato del Mensaje Diameter T (Potentially retransmitted message): esta bandera es seteada tras un procedimiento de recuperación de enlace. Se setea al reenviar solicitudes aún no reconocidas, como una indicación de una posible duplicación debido a una falla de enlace. Este bit DEBE ser puesto a 0 al enviar una solicitud por primera vez, de otro modo, el transmisor DEBE poner esta bandera en 1. Los agentes Diameter sólo deben preocuparse por la cantidad de solicitudes que envían basados en una única solicitud recibida; las retransmisiones de otras entidades no deben ser rastreadas. Los agentes Diameter que reciben una solicitud con la bandera T seteada, DEBEN mantenerla así en la solicitud reenviada. Esta bandera NO DEBE setearse si un mensaje de error ha sido recibido para el mensaje anterior. Sólo puede setearse en casos donde no se ha recibido respuesta a una solicitud desde el servidor, y la solicitud ha sido enviada nuevamente. Esta bandera NO DEBE setearse en mensajes de respuesta.
  178. 178. Formato del Mensaje Diameter r (reserved): estos bits están reservados para uso futuro. Deben setearse a 0 y ser ignorados por el receptor.  Command Code: Compuesto por tres octetos y utilizado para comunicar el comando asociado con el mensaje. Tanto solicitudes como respuestas comparten el mismo espacio de dirección de código de comando. Una bandera presente en el campo Command Flags indica si el mensaje es una solicitud o respuesta.  Application-ID: Identifica la aplicación para la cual aplica el mensaje Diameter. Puede consistir de una aplicación de autenticación o contabilidad de acuerdo al protocolo base, o específica de un desarrollo particular (aplicación para SIP, de configuración de NAS, móvil, servicio de localización, etc.). El valor de este campo de encabezado DEBE coincidir con todo identificador de aplicación AVP relevante contenido en el mensaje.
  179. 179. Formato del Mensaje Diameter  Hop-by-Hop Identifier: Identificador cuyo valor permite a un nodo Diameter correlacionar solicitudes y respuestas, desde que el mismo valor que es seteado en un nodo del trayecto al enviar una solicitud, es copiado en la respuesta generada en otro salto del trayecto (algo que el emisor de la respuesta DEBE asegurar). Este valor es modificado en un nodo Diameter que procesa el mensaje. Este valor es único en una conexión dada para un momento dado, cuestión que el emisor DEBE asegurar. Normalmente se trata de un valor de incremento monótono, luego de ser generado randómicamente. Todo mensaje de respuesta sin este identificador debe ser descartado.
  180. 180. Formato del Mensaje Diameter  End-to-End Identifier: Identifica mensajes duplicados. El emisor de una solicitud setea este identificador, estático y único en cada mensaje, el cual no se modifica al atravesar nodos Diameter de cualquier tipo. Conjuntamente con la identidad de host de origen (Origin-Host AVP), el valor End-to-End Identifier es utilizado para identificar mensajes duplicados. El identificador debe permanecer único por un período de al menos 4 minutos, aún a través de reinicios. El origen de una respuesta DEBE asegurar que este valor se mantiene idéntico al encontrado en la solicitud. Las solicitudes duplicadas DEBIERAN generar la misma respuesta a transmitir y NO DEBEN afectar estado alguno que haya sido seteado cuando la solicitud original fue procesada. Los mensajes de respuesta duplicados a ser procesados localmente, DEBIERAN ser silenciosamente descartados.
  181. 181. Formato de los AVP del mensaje Diameter • Un mensaje Diameter contiene una cantidad variable de contenedores de datos de información (típicamente de autenticación, autorización y contabilidad) denominados pares de atributos de valor o AVP («Attribute- Value Pairs»). La figura muestra el formato de los AVP contenidos en el mensaje Diameter.
  182. 182. Campos de los AVP del mensaje Diameter  AVP Code: Unívocamente identifica el AVP, conjuntamente con el campo Vendor-ID (en caso de estar presente). Los números de código AVP de 1 a 255 identifican atributos importados o ya definidos para para el protocolo RADIUS, por lo que los AVP Code de valores superiores a 255 son específicos de Diameter (asignados por IANA). AVP Length: Indica la longitud del AVP, incluyendo todos los campos presentes en él. Comprende un campo de 8 bits asignados de la siguiente forma:  Flags: Indican al receptor cómo debe tratarse cada atributo.
  183. 183. Las Flags indican:  Bit V: Indicación de si el campo Vendor-ID está presente o no.  Bit M: Indicación de si el AVP es mandatorio u opcional. Si el receptor no comprende la semántica del AVP con el bit M seteado en 1, debe rechazarlo con un mensaje de error apropiado.  Bit P: bandera reservada para uso futuro relacionado a seguridad entre extremos. Al momento de la redacción de IETF RFC 6733, no existen mecanismos de seguridad entre extremos o «end-to-end», por lo que este bit debe «apagarse» a 0.  Bits r: Reservados. El transmisor debe setearlos a 0 y el receptor ignorarlos. Campos de los AVP del mensaje Diameter
  184. 184. Campos de los AVP del mensaje Diameter Vendor-ID: Este campo opcional está presente si el bit V del campo Flags está seteado. Contiene el valor "SMI Network Management Private Enterprise Codes“[ENTERPRISE] asignado por IANA, codificado en orden de byte de red. La combinación de este campo, Product-name y Firmware-Revision (secciones 5.3.7 y 5.3.4 de RFC 6733) pueden proveer información útil para depuración de errores.
  185. 185.  Data: Contiene la información específica del AVP. El campo tiene cero o más octetos, longitud derivada del campo AVP Length. El protocolo Diameter base especifica una cantidad de formatos para este campo: OctetString, Integer32, Integer64, Unsigned32, Unsigned64, Float32, Float64 y Grouped (este último comprende un grupo contenido en una secuencia de AVP). Diameter permite a aplicaciones derivar formatos de datos de AVP. El protocolo base ya define algunos AVP, siendo alguno de los más importantes: • Address: transportan una dirección IPv4 o IPv6; • Time: para presentación de fecha y tiempo; • UTF8String: para representación de una cadena codificado en formato UTF-8; • DiameterIdentity: comunica el nombre de dominio completamente calificado del nodo Diameter; Campos de los AVP del mensaje Diameter • DiameterURI: comunica una URI AAA o AAAS;
  186. 186. • Enumerated: valor numérico que representa algunas semánticas. • Result-Code: indica si la solicitud fue o no exitosamente completada (transportada en todas las respuestas). • Origin-Host: transmite el nombre de dominio completo del nodo Diameter que genera la solicitud. • Origin-Realm: incluye el dominio del nodo Diameter origen de la solicitud; • Destination-Host: transmite el nombre de dominio completo del nodo Diameter Server destinatario de la solicitud; • Destination-Realm: utilizado cuando el usuario no conoce el nombre actual del servidor, pero sí el dominio administrativo donde su nombre de usuario es válido/definido. Siempre es contenido este AVP para aquellas solicitudes que puedan enrutarse a través de proxis hacia el dominio destino. Campos de los AVP del mensaje Diameter • Authorization-Lifetime: indica el período de tiempo por el cual la autorización de un usuario es válida.

×