SlideShare una empresa de Scribd logo
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
 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.
Introducción
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.
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.
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.
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?
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
Introducción
Estadísticas de VoIP
Introducción
Estadísticas de VoIP
Introducción
Estadísticas de VoIP
Introducción
Estadísticas de VoIP
Introducción
Estadísticas de VoIP
 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.
Componentes Básicos de Red VoIP
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.
 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.
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.
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.
Códecs para VoIP
http://blog.tmcnet.com/voice-of-ip/hd_voice/
Códecs para VoIP
http://www.cisco.com/c/en/us/support/docs/voice/h323/14
069-codec-complexity.html
Códecs para VoIP
http://www.cisco.com/c/en/us/support/docs/voice/h323/14
069-codec-complexity.html
Códecs para VoIP
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
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
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.
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).
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.
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).
 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.
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).
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.
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
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.
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.
Arquitectura VoIP
Interworking con Redes Legadas
 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.
Factores que afectan la calidad de la voz
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.
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)
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.
Factores que afectan la calidad de la voz
Códecs
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.
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.
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.
Factores que afectan la calidad de la voz
Retardo (Delay) – Retardo de Paquetización
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.
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.
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.
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.
Factores que afectan la calidad de la voz
Retardo Total
Ejemplo:
Memoria
 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.
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)
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
 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.
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
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
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.»
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
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
Definiciones y Arquitectura
Arquitectura SIP - IETF RFC 3261
Definiciones y Arquitectura
Servidores SIP / Interfaces VoIP
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
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
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
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
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.
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
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.
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».
Trapezoide SIP
 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.
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.).
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.-).
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.
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.
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).
Ejemplo/estructura de mensaje SIP de solicitud: Request
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).
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»
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.
Ejemplo/estructura de mensaje SIP de respuesta: Response
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.
Mensajes SIP: Solicitudes/Repuestas
Extremo-a-Extremo (End-to-End) vs. Salto-a-Salto (Hop-by-Hop)
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
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
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
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
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
Mensajes SIP ACK
Reconocimientos End-to-End vs. Hop-by-Hop
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
Transacción SIP INVITE
Establecimiento exitoso/fallido de llamada SIP
Transacción SIP INVITE-ACK
Señalización
y Roles de
Agentes
de una
llamada SIP
simple entre
extremos
(UA1 - UA2)
Llamada
convencional
con Proxis
según IETF
RFC 3261
El Modo Proxy
El Modo Redirect
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
Métodos SIP:
Transacción CANCEL
Métodos SIP:
Transacción CANCEL -
BYE
Caso de cruce de
mensajes que deriva en
fin de sesión mediante
BYE.
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
Métodos SIP:
PRACK
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.
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.
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
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
Métodos SIP:
SUBSCRIBE /
NOTIFY
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.
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.
Métodos SIP:
PUBLISH
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.
Métodos SIP:
UPDATE
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.
Métodos SIP: MESSAGE
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.
Método SIP:
REFER
Transferencia de
llamada.
Método SIP: REFER
«GET» de página
WEB.
Método SIP: REFER
Transferencia de llamada
con terminación desde el
agente de usuario
objetivo de la
transferencia.
 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.
Internetworking con Redes Legadas CS
Flujo de llamada de
voz exitosa entre
Redes TDM – Redes IP
Internetworking
con Redes
Legadas CS
Flujo de llamada de voz fallida entre Redes IP – Redes TDM
Internetworking con Redes Legadas CS
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)
 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
 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
Flujo de señalización
de video llamada entre
Redes TDM – Redes IP
Internetworking
con Redes
Legadas CS
 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.
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
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.
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».
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)
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.
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)
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.
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)
 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.
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)
Encabezado RTP
La figura muestra el formato del encabezado RTP.
IETF RFC 3550
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.
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).
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.
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.
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.
 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.
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)
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
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.
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
 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.
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
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
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
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)
 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.
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
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.
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.
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.
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
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.
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 .
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.
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.
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.
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
 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.
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».
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)
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».
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.
 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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
 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;
• 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.
Telefonía IP (SIP, Diameter, RTP/RTPC)
Telefonía IP (SIP, Diameter, RTP/RTPC)
Telefonía IP (SIP, Diameter, RTP/RTPC)
Telefonía IP (SIP, Diameter, RTP/RTPC)
Telefonía IP (SIP, Diameter, RTP/RTPC)
Telefonía IP (SIP, Diameter, RTP/RTPC)
Telefonía IP (SIP, Diameter, RTP/RTPC)
Telefonía IP (SIP, Diameter, RTP/RTPC)
Telefonía IP (SIP, Diameter, RTP/RTPC)
Telefonía IP (SIP, Diameter, RTP/RTPC)
Telefonía IP (SIP, Diameter, RTP/RTPC)
Telefonía IP (SIP, Diameter, RTP/RTPC)
Telefonía IP (SIP, Diameter, RTP/RTPC)
Telefonía IP (SIP, Diameter, RTP/RTPC)
Telefonía IP (SIP, Diameter, RTP/RTPC)
Telefonía IP (SIP, Diameter, RTP/RTPC)
Telefonía IP (SIP, Diameter, RTP/RTPC)
Telefonía IP (SIP, Diameter, RTP/RTPC)
Telefonía IP (SIP, Diameter, RTP/RTPC)
Telefonía IP (SIP, Diameter, RTP/RTPC)
Telefonía IP (SIP, Diameter, RTP/RTPC)
Telefonía IP (SIP, Diameter, RTP/RTPC)

Más contenido relacionado

La actualidad más candente

Redes de acceso
Redes de accesoRedes de acceso
Redes de acceso
Iestp Instituto Superior
 
Telefonia PSTN
Telefonia PSTNTelefonia PSTN
Tecnicas mic pdh sdh
Tecnicas mic pdh sdhTecnicas mic pdh sdh
Tecnicas mic pdh sdh
Luis Yallerco
 
5.SONET/SDH Red óptica síncrona
5.SONET/SDH Red óptica síncrona5.SONET/SDH Red óptica síncrona
5.SONET/SDH Red óptica síncrona
Edison Coimbra G.
 
Capitulo 2 - Arquitectura de red UMTS (3G)
Capitulo 2 - Arquitectura de red UMTS (3G)Capitulo 2 - Arquitectura de red UMTS (3G)
Capitulo 2 - Arquitectura de red UMTS (3G)
Andy Juan Sarango Veliz
 
Fundamentos de Telecomunicaciones - Unidad 3 modulacion
Fundamentos de Telecomunicaciones - Unidad 3 modulacionFundamentos de Telecomunicaciones - Unidad 3 modulacion
Fundamentos de Telecomunicaciones - Unidad 3 modulacion
José Antonio Sandoval Acosta
 
VOiP
VOiPVOiP
VOiP
kio89
 
SDH
SDHSDH
codificacion de linea
codificacion de lineacodificacion de linea
codificacion de linea
sarochishernandez
 
9.1 Red telefonica publica conmutada
9.1  Red telefonica publica conmutada9.1  Red telefonica publica conmutada
9.1 Red telefonica publica conmutada
Edison Coimbra G.
 
Radioenlaces terrenales 2da parte
Radioenlaces terrenales 2da parteRadioenlaces terrenales 2da parte
Radioenlaces terrenales 2da parte
Universidad Técnica Particular de Loja
 
Evolucion del celular
Evolucion del celularEvolucion del celular
Evolucion del celular
laurabayort
 
Arquitectura MPLS
Arquitectura MPLSArquitectura MPLS
Arquitectura MPLS
Andy Juan Sarango Veliz
 
What is SS7? An Introduction to Signaling System 7
What is SS7?  An Introduction to Signaling System 7What is SS7?  An Introduction to Signaling System 7
What is SS7? An Introduction to Signaling System 7
Alan Percy
 
PDH
PDHPDH
Capacidad del canal
Capacidad del canalCapacidad del canal
Capacidad del canal
Leonardo Navarro
 
Sip
SipSip
GPON
GPONGPON
GPON
haroldguz
 
Tecnologías de acceso
Tecnologías de accesoTecnologías de acceso
Tecnologías de acceso
Equipo de Redes
 
95895431 trama-e1
95895431 trama-e195895431 trama-e1
95895431 trama-e1
josé López
 

La actualidad más candente (20)

Redes de acceso
Redes de accesoRedes de acceso
Redes de acceso
 
Telefonia PSTN
Telefonia PSTNTelefonia PSTN
Telefonia PSTN
 
Tecnicas mic pdh sdh
Tecnicas mic pdh sdhTecnicas mic pdh sdh
Tecnicas mic pdh sdh
 
5.SONET/SDH Red óptica síncrona
5.SONET/SDH Red óptica síncrona5.SONET/SDH Red óptica síncrona
5.SONET/SDH Red óptica síncrona
 
Capitulo 2 - Arquitectura de red UMTS (3G)
Capitulo 2 - Arquitectura de red UMTS (3G)Capitulo 2 - Arquitectura de red UMTS (3G)
Capitulo 2 - Arquitectura de red UMTS (3G)
 
Fundamentos de Telecomunicaciones - Unidad 3 modulacion
Fundamentos de Telecomunicaciones - Unidad 3 modulacionFundamentos de Telecomunicaciones - Unidad 3 modulacion
Fundamentos de Telecomunicaciones - Unidad 3 modulacion
 
VOiP
VOiPVOiP
VOiP
 
SDH
SDHSDH
SDH
 
codificacion de linea
codificacion de lineacodificacion de linea
codificacion de linea
 
9.1 Red telefonica publica conmutada
9.1  Red telefonica publica conmutada9.1  Red telefonica publica conmutada
9.1 Red telefonica publica conmutada
 
Radioenlaces terrenales 2da parte
Radioenlaces terrenales 2da parteRadioenlaces terrenales 2da parte
Radioenlaces terrenales 2da parte
 
Evolucion del celular
Evolucion del celularEvolucion del celular
Evolucion del celular
 
Arquitectura MPLS
Arquitectura MPLSArquitectura MPLS
Arquitectura MPLS
 
What is SS7? An Introduction to Signaling System 7
What is SS7?  An Introduction to Signaling System 7What is SS7?  An Introduction to Signaling System 7
What is SS7? An Introduction to Signaling System 7
 
PDH
PDHPDH
PDH
 
Capacidad del canal
Capacidad del canalCapacidad del canal
Capacidad del canal
 
Sip
SipSip
Sip
 
GPON
GPONGPON
GPON
 
Tecnologías de acceso
Tecnologías de accesoTecnologías de acceso
Tecnologías de acceso
 
95895431 trama-e1
95895431 trama-e195895431 trama-e1
95895431 trama-e1
 

Destacado

Digitalización de las señales de abonado
Digitalización de las señales de abonadoDigitalización de las señales de abonado
Digitalización de las señales de abonado
Eng. Fernando Mendioroz, MSc.
 
Sincronización en Redes Telefónicas Públicas Conmutadas
Sincronización en Redes Telefónicas Públicas ConmutadasSincronización en Redes Telefónicas Públicas Conmutadas
Sincronización en Redes Telefónicas Públicas Conmutadas
Eng. Fernando Mendioroz, MSc.
 
Restcomm Geolocation API and GMLC Restconn 2017
Restcomm Geolocation API and GMLC Restconn 2017Restcomm Geolocation API and GMLC Restconn 2017
Restcomm Geolocation API and GMLC Restconn 2017
Eng. Fernando Mendioroz, MSc.
 
Sistemas de Conmutación: Introducción
Sistemas de Conmutación: IntroducciónSistemas de Conmutación: Introducción
Sistemas de Conmutación: Introducción
Eng. Fernando Mendioroz, MSc.
 
Presentación del Curso Sistemas de Conmutación en Unicauca
Presentación del Curso Sistemas de Conmutación en UnicaucaPresentación del Curso Sistemas de Conmutación en Unicauca
Presentación del Curso Sistemas de Conmutación en Unicauca
Eng. Fernando Mendioroz, MSc.
 
Conmutadores Digitales
Conmutadores DigitalesConmutadores Digitales
Conmutadores Digitales
Eng. Fernando Mendioroz, MSc.
 
Introducción a Redes IP
Introducción a Redes IPIntroducción a Redes IP
Introducción a Redes IP
Eng. Fernando Mendioroz, MSc.
 
Introducción a WDM y OTN
Introducción a WDM y OTNIntroducción a WDM y OTN
Introducción a WDM y OTN
Eng. Fernando Mendioroz, MSc.
 
Modo de Transferencia Asíncrona (ATM)
Modo de Transferencia Asíncrona (ATM)Modo de Transferencia Asíncrona (ATM)
Modo de Transferencia Asíncrona (ATM)
Eng. Fernando Mendioroz, MSc.
 
NGN SOA Cloud Computing NGOSS/eTOM
NGN SOA Cloud Computing NGOSS/eTOMNGN SOA Cloud Computing NGOSS/eTOM
NGN SOA Cloud Computing NGOSS/eTOM
Eng. Fernando Mendioroz, MSc.
 
Telefonía Móvil Celular (0 a 4G LTE-Advanced)
Telefonía Móvil Celular (0 a 4G LTE-Advanced)Telefonía Móvil Celular (0 a 4G LTE-Advanced)
Telefonía Móvil Celular (0 a 4G LTE-Advanced)
Eng. Fernando Mendioroz, MSc.
 

Destacado (11)

Digitalización de las señales de abonado
Digitalización de las señales de abonadoDigitalización de las señales de abonado
Digitalización de las señales de abonado
 
Sincronización en Redes Telefónicas Públicas Conmutadas
Sincronización en Redes Telefónicas Públicas ConmutadasSincronización en Redes Telefónicas Públicas Conmutadas
Sincronización en Redes Telefónicas Públicas Conmutadas
 
Restcomm Geolocation API and GMLC Restconn 2017
Restcomm Geolocation API and GMLC Restconn 2017Restcomm Geolocation API and GMLC Restconn 2017
Restcomm Geolocation API and GMLC Restconn 2017
 
Sistemas de Conmutación: Introducción
Sistemas de Conmutación: IntroducciónSistemas de Conmutación: Introducción
Sistemas de Conmutación: Introducción
 
Presentación del Curso Sistemas de Conmutación en Unicauca
Presentación del Curso Sistemas de Conmutación en UnicaucaPresentación del Curso Sistemas de Conmutación en Unicauca
Presentación del Curso Sistemas de Conmutación en Unicauca
 
Conmutadores Digitales
Conmutadores DigitalesConmutadores Digitales
Conmutadores Digitales
 
Introducción a Redes IP
Introducción a Redes IPIntroducción a Redes IP
Introducción a Redes IP
 
Introducción a WDM y OTN
Introducción a WDM y OTNIntroducción a WDM y OTN
Introducción a WDM y OTN
 
Modo de Transferencia Asíncrona (ATM)
Modo de Transferencia Asíncrona (ATM)Modo de Transferencia Asíncrona (ATM)
Modo de Transferencia Asíncrona (ATM)
 
NGN SOA Cloud Computing NGOSS/eTOM
NGN SOA Cloud Computing NGOSS/eTOMNGN SOA Cloud Computing NGOSS/eTOM
NGN SOA Cloud Computing NGOSS/eTOM
 
Telefonía Móvil Celular (0 a 4G LTE-Advanced)
Telefonía Móvil Celular (0 a 4G LTE-Advanced)Telefonía Móvil Celular (0 a 4G LTE-Advanced)
Telefonía Móvil Celular (0 a 4G LTE-Advanced)
 

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

TELEFONIA IP.pdf
TELEFONIA IP.pdfTELEFONIA IP.pdf
TELEFONIA IP.pdf
NataliaPortuguez1
 
VOIP I - Marzo 2010
VOIP I - Marzo 2010VOIP I - Marzo 2010
VOIP I - Marzo 2010
Jose Cordova
 
Voz sobre ip
Voz sobre ipVoz sobre ip
Voz sobre ip
guest84bdc4
 
Voip
VoipVoip
Sistemas de VoIP con Asterisk: Modulo I
Sistemas de VoIP con Asterisk: Modulo ISistemas de VoIP con Asterisk: Modulo I
Sistemas de VoIP con Asterisk: Modulo I
Gabriel Astudillo
 
Fundamentos20de20telefonia20ip 131006193600-phpapp02
Fundamentos20de20telefonia20ip 131006193600-phpapp02Fundamentos20de20telefonia20ip 131006193600-phpapp02
Fundamentos20de20telefonia20ip 131006193600-phpapp02
myconta
 
Fundamentos de telefonia ip
Fundamentos de telefonia ipFundamentos de telefonia ip
Fundamentos de telefonia ip
Jose Luis Chauca
 
Vo ip
Vo ipVo ip
Voz Ip
Voz IpVoz Ip
Voz Ip
guest8f37b2
 
Redes neldo
Redes neldoRedes neldo
Redes neldo
OJames22
 
Voz sobre IP
Voz sobre IPVoz sobre IP
Voz sobre IP
Sergio J. Castro
 
VoIP
VoIPVoIP
Protocolos de voip de acuerdo al modelo osi
Protocolos de voip de acuerdo al modelo osiProtocolos de voip de acuerdo al modelo osi
Protocolos de voip de acuerdo al modelo osi
Solxitlaly Guerra
 
La vo ip
La vo ipLa vo ip
Voz sobre ip
Voz sobre ipVoz sobre ip
Expo electiva
Expo electivaExpo electiva
Expo electiva
Francy Ruiz
 
Voip
VoipVoip
Voip
VoipVoip
Telf ip parte ii_el629_2012v01
Telf ip parte ii_el629_2012v01Telf ip parte ii_el629_2012v01
Telf ip parte ii_el629_2012v01
Luis Castillo Barros
 
Configuración básica asterisk sixbell - v2.0
Configuración básica asterisk   sixbell - v2.0Configuración básica asterisk   sixbell - v2.0
Configuración básica asterisk sixbell - v2.0
Sebastian Cisternas Arenas
 

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

TELEFONIA IP.pdf
TELEFONIA IP.pdfTELEFONIA IP.pdf
TELEFONIA IP.pdf
 
VOIP I - Marzo 2010
VOIP I - Marzo 2010VOIP I - Marzo 2010
VOIP I - Marzo 2010
 
Voz sobre ip
Voz sobre ipVoz sobre ip
Voz sobre ip
 
Voip
VoipVoip
Voip
 
Sistemas de VoIP con Asterisk: Modulo I
Sistemas de VoIP con Asterisk: Modulo ISistemas de VoIP con Asterisk: Modulo I
Sistemas de VoIP con Asterisk: Modulo I
 
Fundamentos20de20telefonia20ip 131006193600-phpapp02
Fundamentos20de20telefonia20ip 131006193600-phpapp02Fundamentos20de20telefonia20ip 131006193600-phpapp02
Fundamentos20de20telefonia20ip 131006193600-phpapp02
 
Fundamentos de telefonia ip
Fundamentos de telefonia ipFundamentos de telefonia ip
Fundamentos de telefonia ip
 
Vo ip
Vo ipVo ip
Vo ip
 
Voz Ip
Voz IpVoz Ip
Voz Ip
 
Redes neldo
Redes neldoRedes neldo
Redes neldo
 
Voz sobre IP
Voz sobre IPVoz sobre IP
Voz sobre IP
 
VoIP
VoIPVoIP
VoIP
 
Protocolos de voip de acuerdo al modelo osi
Protocolos de voip de acuerdo al modelo osiProtocolos de voip de acuerdo al modelo osi
Protocolos de voip de acuerdo al modelo osi
 
La vo ip
La vo ipLa vo ip
La vo ip
 
Voz sobre ip
Voz sobre ipVoz sobre ip
Voz sobre ip
 
Expo electiva
Expo electivaExpo electiva
Expo electiva
 
Voip
VoipVoip
Voip
 
Voip
VoipVoip
Voip
 
Telf ip parte ii_el629_2012v01
Telf ip parte ii_el629_2012v01Telf ip parte ii_el629_2012v01
Telf ip parte ii_el629_2012v01
 
Configuración básica asterisk sixbell - v2.0
Configuración básica asterisk   sixbell - v2.0Configuración básica asterisk   sixbell - v2.0
Configuración básica asterisk sixbell - v2.0
 

Último

INTRDODUCCION A SQL ES UN CURSO DISEÑADO PARA ING. EN SISTEMA
INTRDODUCCION A SQL ES UN CURSO DISEÑADO PARA  ING. EN SISTEMAINTRDODUCCION A SQL ES UN CURSO DISEÑADO PARA  ING. EN SISTEMA
INTRDODUCCION A SQL ES UN CURSO DISEÑADO PARA ING. EN SISTEMA
Albert Bamba
 
PRESENTACIÓN CONCRETO PRETENSADO Y POSTENSADO
PRESENTACIÓN CONCRETO PRETENSADO Y POSTENSADOPRESENTACIÓN CONCRETO PRETENSADO Y POSTENSADO
PRESENTACIÓN CONCRETO PRETENSADO Y POSTENSADO
yvanarojas333
 
Solucionario examen final 2023.20 TIPO C.pdf
Solucionario examen final 2023.20 TIPO C.pdfSolucionario examen final 2023.20 TIPO C.pdf
Solucionario examen final 2023.20 TIPO C.pdf
CLEVERCRISTIANVILLAR
 
PRESENTACION PROY REGIONAL PRONATEL (1).pptx
PRESENTACION PROY REGIONAL PRONATEL (1).pptxPRESENTACION PROY REGIONAL PRONATEL (1).pptx
PRESENTACION PROY REGIONAL PRONATEL (1).pptx
deborah13ya
 
Clase 05 - Asistente técnica en obras públicas.pdf
Clase 05 - Asistente técnica en obras públicas.pdfClase 05 - Asistente técnica en obras públicas.pdf
Clase 05 - Asistente técnica en obras públicas.pdf
pedropea79
 
Los cinco niveles de competencia dentro de un Estándar de Competencia Laboral...
Los cinco niveles de competencia dentro de un Estándar de Competencia Laboral...Los cinco niveles de competencia dentro de un Estándar de Competencia Laboral...
Los cinco niveles de competencia dentro de un Estándar de Competencia Laboral...
Jose Manuel de la Cruz Castro
 
TRANSMISIONES MECANICAS AUTOMOVIL PRESENTACION
TRANSMISIONES MECANICAS AUTOMOVIL PRESENTACIONTRANSMISIONES MECANICAS AUTOMOVIL PRESENTACION
TRANSMISIONES MECANICAS AUTOMOVIL PRESENTACION
GABRIEL RUIZ
 
plagas y enfermedades del cafe en la convencion.ppt
plagas y enfermedades del cafe en la convencion.pptplagas y enfermedades del cafe en la convencion.ppt
plagas y enfermedades del cafe en la convencion.ppt
adan yomar fenandez toro
 
uso del ultrasonido en procesos de deshidratación de alimentos
uso del ultrasonido en procesos de deshidratación de alimentosuso del ultrasonido en procesos de deshidratación de alimentos
uso del ultrasonido en procesos de deshidratación de alimentos
YaneMedinaOrtiz1
 
Locomoción: el principio de la movilidad robótica
Locomoción: el principio de la movilidad robóticaLocomoción: el principio de la movilidad robótica
Locomoción: el principio de la movilidad robótica
JonacToapanata
 
listado de precios unitarios de cegin.pdf
listado de precios unitarios de cegin.pdflistado de precios unitarios de cegin.pdf
listado de precios unitarios de cegin.pdf
luisespinocarrera1
 
Geotecnia temas completos unsa docente .pdf
Geotecnia temas completos unsa docente .pdfGeotecnia temas completos unsa docente .pdf
Geotecnia temas completos unsa docente .pdf
frida171614
 
“RECONOCIMIENTO DEL SECUENCIADOR DE NANOPOROS (NANOPORE SEQUENCING) MINION MK1C”
“RECONOCIMIENTO DEL SECUENCIADOR DE NANOPOROS (NANOPORE SEQUENCING) MINION MK1C”“RECONOCIMIENTO DEL SECUENCIADOR DE NANOPOROS (NANOPORE SEQUENCING) MINION MK1C”
“RECONOCIMIENTO DEL SECUENCIADOR DE NANOPOROS (NANOPORE SEQUENCING) MINION MK1C”
javisoad
 
EJEMPLO DIAPOSITIVAS ANALISIS DE PROBLEMAS QUE ENFRENTAN LAS ORGANIZACIONES E...
EJEMPLO DIAPOSITIVAS ANALISIS DE PROBLEMAS QUE ENFRENTAN LAS ORGANIZACIONES E...EJEMPLO DIAPOSITIVAS ANALISIS DE PROBLEMAS QUE ENFRENTAN LAS ORGANIZACIONES E...
EJEMPLO DIAPOSITIVAS ANALISIS DE PROBLEMAS QUE ENFRENTAN LAS ORGANIZACIONES E...
GABRIELISAACCHIRITOC
 
Most Girls Call Noida 9873940964 Provide Best And Top Girl Service And No1 in...
Most Girls Call Noida 9873940964 Provide Best And Top Girl Service And No1 in...Most Girls Call Noida 9873940964 Provide Best And Top Girl Service And No1 in...
Most Girls Call Noida 9873940964 Provide Best And Top Girl Service And No1 in...
AK47
 
Matriz IPERC - Retiro de guarda de Molino de bolas.pdf
Matriz IPERC - Retiro de guarda de Molino de bolas.pdfMatriz IPERC - Retiro de guarda de Molino de bolas.pdf
Matriz IPERC - Retiro de guarda de Molino de bolas.pdf
LuisAlbertoBustamant12
 
diploma-crear y emprender en educación para el trabajo
diploma-crear y emprender en educación para el trabajodiploma-crear y emprender en educación para el trabajo
diploma-crear y emprender en educación para el trabajo
MakoMedinaChrisAvril
 
nuevo - BALANCE DE ENERGIA PARA SISTEMAS REACCIONANTES.pptx
nuevo - BALANCE DE ENERGIA PARA SISTEMAS REACCIONANTES.pptxnuevo - BALANCE DE ENERGIA PARA SISTEMAS REACCIONANTES.pptx
nuevo - BALANCE DE ENERGIA PARA SISTEMAS REACCIONANTES.pptx
HernandoVillavicenci
 
Diapositivas-Diseño-de-Afirmado en caminos de BVT
Diapositivas-Diseño-de-Afirmado en caminos de BVTDiapositivas-Diseño-de-Afirmado en caminos de BVT
Diapositivas-Diseño-de-Afirmado en caminos de BVT
DamianAlfaroFlores
 
RESULTADO DE METALES PESADOS RED DE SALUD JAUJA.pptx
RESULTADO DE METALES PESADOS RED DE SALUD JAUJA.pptxRESULTADO DE METALES PESADOS RED DE SALUD JAUJA.pptx
RESULTADO DE METALES PESADOS RED DE SALUD JAUJA.pptx
WendyJhoysALVAREZANT1
 

Último (20)

INTRDODUCCION A SQL ES UN CURSO DISEÑADO PARA ING. EN SISTEMA
INTRDODUCCION A SQL ES UN CURSO DISEÑADO PARA  ING. EN SISTEMAINTRDODUCCION A SQL ES UN CURSO DISEÑADO PARA  ING. EN SISTEMA
INTRDODUCCION A SQL ES UN CURSO DISEÑADO PARA ING. EN SISTEMA
 
PRESENTACIÓN CONCRETO PRETENSADO Y POSTENSADO
PRESENTACIÓN CONCRETO PRETENSADO Y POSTENSADOPRESENTACIÓN CONCRETO PRETENSADO Y POSTENSADO
PRESENTACIÓN CONCRETO PRETENSADO Y POSTENSADO
 
Solucionario examen final 2023.20 TIPO C.pdf
Solucionario examen final 2023.20 TIPO C.pdfSolucionario examen final 2023.20 TIPO C.pdf
Solucionario examen final 2023.20 TIPO C.pdf
 
PRESENTACION PROY REGIONAL PRONATEL (1).pptx
PRESENTACION PROY REGIONAL PRONATEL (1).pptxPRESENTACION PROY REGIONAL PRONATEL (1).pptx
PRESENTACION PROY REGIONAL PRONATEL (1).pptx
 
Clase 05 - Asistente técnica en obras públicas.pdf
Clase 05 - Asistente técnica en obras públicas.pdfClase 05 - Asistente técnica en obras públicas.pdf
Clase 05 - Asistente técnica en obras públicas.pdf
 
Los cinco niveles de competencia dentro de un Estándar de Competencia Laboral...
Los cinco niveles de competencia dentro de un Estándar de Competencia Laboral...Los cinco niveles de competencia dentro de un Estándar de Competencia Laboral...
Los cinco niveles de competencia dentro de un Estándar de Competencia Laboral...
 
TRANSMISIONES MECANICAS AUTOMOVIL PRESENTACION
TRANSMISIONES MECANICAS AUTOMOVIL PRESENTACIONTRANSMISIONES MECANICAS AUTOMOVIL PRESENTACION
TRANSMISIONES MECANICAS AUTOMOVIL PRESENTACION
 
plagas y enfermedades del cafe en la convencion.ppt
plagas y enfermedades del cafe en la convencion.pptplagas y enfermedades del cafe en la convencion.ppt
plagas y enfermedades del cafe en la convencion.ppt
 
uso del ultrasonido en procesos de deshidratación de alimentos
uso del ultrasonido en procesos de deshidratación de alimentosuso del ultrasonido en procesos de deshidratación de alimentos
uso del ultrasonido en procesos de deshidratación de alimentos
 
Locomoción: el principio de la movilidad robótica
Locomoción: el principio de la movilidad robóticaLocomoción: el principio de la movilidad robótica
Locomoción: el principio de la movilidad robótica
 
listado de precios unitarios de cegin.pdf
listado de precios unitarios de cegin.pdflistado de precios unitarios de cegin.pdf
listado de precios unitarios de cegin.pdf
 
Geotecnia temas completos unsa docente .pdf
Geotecnia temas completos unsa docente .pdfGeotecnia temas completos unsa docente .pdf
Geotecnia temas completos unsa docente .pdf
 
“RECONOCIMIENTO DEL SECUENCIADOR DE NANOPOROS (NANOPORE SEQUENCING) MINION MK1C”
“RECONOCIMIENTO DEL SECUENCIADOR DE NANOPOROS (NANOPORE SEQUENCING) MINION MK1C”“RECONOCIMIENTO DEL SECUENCIADOR DE NANOPOROS (NANOPORE SEQUENCING) MINION MK1C”
“RECONOCIMIENTO DEL SECUENCIADOR DE NANOPOROS (NANOPORE SEQUENCING) MINION MK1C”
 
EJEMPLO DIAPOSITIVAS ANALISIS DE PROBLEMAS QUE ENFRENTAN LAS ORGANIZACIONES E...
EJEMPLO DIAPOSITIVAS ANALISIS DE PROBLEMAS QUE ENFRENTAN LAS ORGANIZACIONES E...EJEMPLO DIAPOSITIVAS ANALISIS DE PROBLEMAS QUE ENFRENTAN LAS ORGANIZACIONES E...
EJEMPLO DIAPOSITIVAS ANALISIS DE PROBLEMAS QUE ENFRENTAN LAS ORGANIZACIONES E...
 
Most Girls Call Noida 9873940964 Provide Best And Top Girl Service And No1 in...
Most Girls Call Noida 9873940964 Provide Best And Top Girl Service And No1 in...Most Girls Call Noida 9873940964 Provide Best And Top Girl Service And No1 in...
Most Girls Call Noida 9873940964 Provide Best And Top Girl Service And No1 in...
 
Matriz IPERC - Retiro de guarda de Molino de bolas.pdf
Matriz IPERC - Retiro de guarda de Molino de bolas.pdfMatriz IPERC - Retiro de guarda de Molino de bolas.pdf
Matriz IPERC - Retiro de guarda de Molino de bolas.pdf
 
diploma-crear y emprender en educación para el trabajo
diploma-crear y emprender en educación para el trabajodiploma-crear y emprender en educación para el trabajo
diploma-crear y emprender en educación para el trabajo
 
nuevo - BALANCE DE ENERGIA PARA SISTEMAS REACCIONANTES.pptx
nuevo - BALANCE DE ENERGIA PARA SISTEMAS REACCIONANTES.pptxnuevo - BALANCE DE ENERGIA PARA SISTEMAS REACCIONANTES.pptx
nuevo - BALANCE DE ENERGIA PARA SISTEMAS REACCIONANTES.pptx
 
Diapositivas-Diseño-de-Afirmado en caminos de BVT
Diapositivas-Diseño-de-Afirmado en caminos de BVTDiapositivas-Diseño-de-Afirmado en caminos de BVT
Diapositivas-Diseño-de-Afirmado en caminos de BVT
 
RESULTADO DE METALES PESADOS RED DE SALUD JAUJA.pptx
RESULTADO DE METALES PESADOS RED DE SALUD JAUJA.pptxRESULTADO DE METALES PESADOS RED DE SALUD JAUJA.pptx
RESULTADO DE METALES PESADOS RED DE SALUD JAUJA.pptx
 

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

  • 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.  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.
  • 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. 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. 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. 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. 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
  • 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.
  • 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.  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. 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. 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.
  • 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. 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. 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. 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. 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. 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.  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. 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. 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. 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. 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. 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.
  • 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. Factores que afectan la calidad de la voz
  • 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. 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. 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. Factores que afectan la calidad de la voz Códecs
  • 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. 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. 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. Factores que afectan la calidad de la voz Retardo (Delay) – Retardo de Paquetización
  • 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. 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. 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. 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. Factores que afectan la calidad de la voz Retardo Total Ejemplo: Memoria
  • 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. 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. 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.  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. 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. 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. 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. 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. 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
  • 63. Definiciones y Arquitectura Servidores SIP / Interfaces VoIP
  • 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. 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. 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. 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. 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. 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. 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. 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».
  • 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. 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. 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. 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. 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. 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. Ejemplo/estructura de mensaje SIP de solicitud: Request
  • 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. 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. 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. Ejemplo/estructura de mensaje SIP de respuesta: Response
  • 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. Mensajes SIP: Solicitudes/Repuestas Extremo-a-Extremo (End-to-End) vs. Salto-a-Salto (Hop-by-Hop)
  • 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. 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. 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. 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. 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. Mensajes SIP ACK Reconocimientos End-to-End vs. Hop-by-Hop
  • 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
  • 96. Señalización y Roles de Agentes de una llamada SIP simple entre extremos (UA1 - UA2)
  • 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
  • 102. Métodos SIP: Transacción CANCEL - BYE Caso de cruce de mensajes que deriva en fin de sesión mediante BYE.
  • 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
  • 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. 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. 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. 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
  • 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. 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.
  • 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.
  • 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.
  • 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.
  • 119. Método SIP: REFER «GET» de página WEB.
  • 120. Método SIP: REFER Transferencia de llamada con terminación desde el agente de usuario objetivo de la transferencia.
  • 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.
  • 123. Flujo de llamada de voz exitosa entre Redes TDM – Redes IP Internetworking con Redes Legadas CS
  • 124. Flujo de llamada de voz fallida entre Redes IP – Redes TDM Internetworking con Redes Legadas CS
  • 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.  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.  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. Flujo de señalización de video llamada entre Redes TDM – Redes IP Internetworking con Redes Legadas CS
  • 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. 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. 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. 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. 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. 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. 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. 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. 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.  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. 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. Encabezado RTP La figura muestra el formato del encabezado RTP. IETF RFC 3550
  • 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. 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. 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. 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. 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.  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. 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. 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. 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. 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.  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. 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. 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. 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. 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.  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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.  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. 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. 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. 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. 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.  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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.  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. • 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.