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

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
 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.
 Plano de Usuario en Telefonía IP: RTP/RTPC.
 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.

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

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.

 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).

 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).

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.

Interworking con Redes Legadas

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.

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)

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.

Códecs

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.

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.

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.

Retardo (Delay) – Retardo de Paquetización

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.

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.

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.

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.

Retardo Total
Ejemplo:
Memoria

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

Definiciones y Arquitectura
IP
Plano de Control:
Señalización
Plano de Usuario:
BICC

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

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.»

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

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

Arquitectura SIP - IETF RFC 3261

Servidores SIP / Interfaces VoIP

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

 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

 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

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

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.

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

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.

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».

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).

 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»

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).
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.

Establecimiento exitoso/fallido de llamada SIP

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

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.

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.
Via, To, From, Call-ID, Cseq, Max-Forwards, RAck

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.
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.
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.
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).

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.
Contact, Event, Allow-Events, Expires, Min-Expires.

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.
Contact.

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.

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).
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.

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

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:
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.
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

 Introducción.
 Definiciones y Arquitectura
 Formato del paquete RTP
 Funciones AAA.

Características
IP
Plano de Control:
Señalización
Plano de Usuario:
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.

 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».

 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)

 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.

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.

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.

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

 Introducción.
 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.

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.

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).

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.

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.

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.

 Introducción.
 Descripción General
 Formato del paquete RTP
 Funciones AAA.

 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.

 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

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.
La figura muestra cómo los mapeos RTCP realizan esta
sincronización inter-medios.

 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).
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

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

 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

 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.

 Introducción.
 Generalidades del protocolo y Arquitectura Diameter.
 Formato del mensaje Diameter.
 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
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 .

 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.

 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.

 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

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.

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.

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.

 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.

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.

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.

 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.

 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.

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;
• 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.
• 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)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (13)

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

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

Recently uploaded

Recently uploaded (20)

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