Jose Luis Quiroz Arroyo IT 536 M IMS 30 setiembre 2017

IP Multimedia Subsystem
(IMS)
IT 536 M
 INICTEL-UNI

Protocolos primarios SIP

CAPITULO 2 SEMANA 6

30/09/2017 IT 536 M IMS 2

 INICTEL-UNI

Protocolo de Descripcin de
Sesin: SDP
CAPITULO 2 SEMANA 6

30/09/2017 IT 536 M IMS 3

SDP Configurando la Sesin
INICTEL-UNI

INVITE contiene el Protocolo de Descripcin de Sesin (SDP)

en el cuerpo del mensaje.
SDP esta definido en la RFC 2327
SDP carga la descripcin de la sesin deseada desde la
perspectiva de quien est llamando
Las Sesiones consisten de un conjunto de flujos de medias.
Cada flujo puede ser de audio, video, texto, aplicacin, etc.

30/09/2017 IT 536 M IMS 4

Introduccin a SDP
INICTEL-UNI

SDP: Session Description Protocol (Protocolo de Descripcin de Sesin). Es un

formato para describir los parmetros de inicio de sesin de medios de streaming.
Fue publicado por la IETF como RFC 2327 (1998) y reemplazado por la RFC 4566
(2006). Los medios de streaming es el contenido visto o escuchado durante un envo
de datos.
Durante el proceso para establecer una sesin es necesario negociar los medios que
se usarn (voz, video o datos) y las respectivas informaciones para transmitirlos,
como el estndar del CODEC y el protocolo de control para la transmisin.

Mientras el SIP especifica el proceso para anunciar la descripcin de las

informaciones de una sesin, el SDP especifica solamente el formato para
describir esas informaciones.

30/09/2017 IT 536 M IMS 5

Introduccin a SDP
INICTEL-UNI

La descripcin de las informaciones de una sesin SDP se representa en su

totalidad de forma textual.
Esto facilita la portabilidad, permite una variedad de formas de transporte y
hace posible que herramientas basadas en texto puedan generar y procesar
descripciones de sesiones, de manera que los valores de los atributos
puedan usar todo el conjunto de caracteres del UTF-8.
Un mensaje SDP est compuesto por una serie de lneas denominadas
campos. Los nombres se abrevian con una sola letra. El formateo de las
lneas de texto estn descritas de la siguiente forma:

Tipo del campo = Valor del campo

30/09/2017 IT 536 M IMS 6

Introduccin a SDP
INICTEL-UNI

Por ejemplo, el campo m del SDP corresponde a la descripcin de los

medios. ste especifica el tipo de Medios, el puerto en el que se espera el
flujo de medio y una lista de CODECs que el endpoint conoce.
m=audio 3456 RTP/AVP 0,3,4 e 5

En este caso, se trata de un flujo de audio que se recibir en el puerto 3456

y que utilizar el protocolo RTP para transporte. Los CODECs posibles para
esta comunicacin son 0=PCM G711, 3=GSM, 4=G.723 y 5=DVI4.
Los cdigos que corresponden a los CODECs para los diversos tipos de
medios estn detallados en la RFC 3551.

30/09/2017 IT 536 M IMS 7

Configurando la Sesin
INICTEL-UNI

SDP tambin contiene informaciones necesarias sobre la propia

sesin:
Cdecs involucrados
Direccin de transporte y puertos

SDP puede cargar otras informaciones sobre la sesin:

Horario en que ella se iniciar
Quien origin la sesin
Asunto de la sesin
URL conteniendo mayores informaciones de la sesin
30/09/2017 IT 536 M IMS 8
Anatoma del SDP
INICTEL-UNI

SDP contiene encabezados de informaciones genrica

Versin del SDP (v)
Origen (o) (ID nico del usuario que origino)
Asunto (s)
Informacin adicional (i)
Algunos encabezados genricos opcionales:
Informacin de la tasa de transmisin (b)
Informacin adicional de la sesin (i)
Otros
Seguido por la secuencia de descripciones de flujos de medias

30/09/2017 IT 536 M IMS 9

Anatoma del SDP
INICTEL-UNI

Cada flujo de media contiene una lnea m definiendo

Puerto
Tipo de transporte para la media
Cdecs
Lneas opcionales para la media
Ttulo (i)
Informacin de conexin (c)
Tasa de transmisin (b)
Atributos adicionales (a)
Llave de cifrado (k)

30/09/2017 IT 536 M IMS 10

Ejemplo de SDP
INICTEL-UNI

http://tools.ietf.org/html/rfc4566
30/09/2017 IT 536 M IMS 11
Descriptores del SDP (RFC 4566)
INICTEL-UNI

30/09/2017 IT 536 M IMS 12

Negociando la Sesin
INICTEL-UNI

La parte llamada (receptor) recibe el SDP ofrecido por el

llamador (emisor)
Cada flujo puede ser:
Aceptado
Rechazado
Aceptar, significa generar en la respuesta un SD listando el
mismo flujo de media.
Con el nmero del puerto y la direccin de la parte llamada.
Adems del subconjunto de cdecs del SDP de la peticin.

30/09/2017 IT 536 M IMS 13

Negociando la Sesin
INICTEL-UNI

Rechazar, es indicada por el uso de cero en la configuracin del

puerto de la media
El SDP resultante es enviado adicionando a la respuesta 200 OK
La Media, ahora puede ser cambiada entre los puntos finales.
Cundo la Media puede ser enviada en cada direccin?

30/09/2017 IT 536 M IMS 14

Cambiando parmetros de la Sesin
INICTEL-UNI

Una vez que la llamada es iniciada, las sesiones pueden ser

modificadas
Posibles cambios:
Adicionar un flujo
Remover un flujo
Cambiar cdecs
Cambiar informaciones de direccionamiento

30/09/2017 IT 536 M IMS 15

Cambiando parmetros de la Sesin
INICTEL-UNI

Llamada en espera, bsicamente es una sesin que es alterada

dinmicamente.
El cambio de parmetros es posible reenviando el INVITE (re-
INVITE)
Tiene el mismo tipo de negociacin de sesin que el INVITE
original
Con la recusa del re-INVITE, la llamada todava permanece
activa

30/09/2017 IT 536 M IMS 16

Desconexin
INICTEL-UNI

El Como desconectar depende de cuando se hace:

Despus de que la llamada ha sido configurada:

Cada una de las partes involucradas, puede enviar una
peticin BYE
Hay Desconexin desde el llamador (emisor), antes de que la
llamada a sido aceptada:
Por el envo de CANCEL
Si la llamada fuera aceptada despus del CANCEL, entonces
es necesario usar el BYE

30/09/2017 IT 536 M IMS 17

Flujo Bsico: UA-Proxy-UA
INICTEL-UNI

Configuracin de llamada
Mensaje 100 Trying para cada hop visitado.
180 Ringing cuando este tocando en el lado llamado
200 OK - significa aceptar la llamada

Modificacin de parmetros de llamada

Re-INVITE (es el mismo INVITE original, con la descripcin de sesin
actualizada)

Terminacin : Mtodo BYE

30/09/2017 IT 536 M IMS 18

Seguridad
INICTEL-UNI

A travs de mecanismos legados como:

HTTP
Basic authentication, Digest authentication
CHAP (Challenge Handshake Authentication Protocol)
PGP (Pretty Good Privacy)
Relativo a la sealizacin
TLS Transporte
DTLS Transporte
S/MIME
Relativo a la media
SRTP
ZRTP
30/09/2017 IT 536 M IMS 19
Esquema de funcionamiento del NAT
INICTEL-UNI

NAT ejerce dos controles: Mapeo y Filtro

Equipos detrs de NAT solo entran en la tabla de
mapeo cuando este intenta hablar para afuera.
Como Filtro controla quien accede al mapeo existente

30/09/2017 IT 536 M IMS 20

Clasificacin de los tipos de NAT
INICTEL-UNI

Full Cone (Uno a Uno, NAT Esttico)

Asociacin directa de IP privados con IP pblicos
Cualquier host externo puede enviar paquetes para el host interno, utilizando su IP externo
Restricted Cone (NAT Dinmico)
Trabaja igual a Full Cone NAT, pero aplica restricciones adicionales basadas sobre una direccin IP.
Host X solo puede enviar paquetes para una mquina interna, en caso esta ya haya enviado anteriormente
paquetes para el host X
Port Restricted Cone (Nat Dinmico)
Trabaja igual a Port Restricted Cone NAT, pero restringe comunicacin a los puertos que estn siendo
utilizados.
Host X con puerto de origen P solamente puede enviar para una mquina interna si recibi anteriormente
paquetes de esta para el puerto P
Symmetric (NAT Dinmico)
Aplica restricciones exactamente igual como un Port Restricted Cone NAT, pero mantiene la traduccin NAT
diferente.
Todos los paquetes originados por un host interno para un IP X y puerto P son asociados a un IP pblico y
puertos especficos
Si enva un paquete para un IP y puerto P, otro mapeo ser utilizado.

30/09/2017 IT 536 M IMS 21

Problemas de NAT
INICTEL-UNI

Con el encabezado VIA

Con el encabezado CONTACT

Transmisin RTP

30/09/2017 IT 536 M IMS 22

Campo VIA
INICTEL-UNI

Problema
Respuestas para las peticiones no pueden ser enviadas al
origen, pues la direccin informada no puede ser usada fuera
de la red interna.
Solucin
Cuando el mensaje llega a un servidor o a un UA, se hace una
comparacin entre la direccin de origen y el presentado en el
encabezado VIA
Si hubiese diferencia, entonces el IP correcto (del cual el
paquete es originado) es escrito como el parmetro received=
y adicionado al encabezado VIA.
30/09/2017 IT 536 M IMS 23
 Campo CONTACT
INICTEL-UNI
Problema
Futuras peticiones sern generadas de manera errada debido a que la
direccin ser enrutada solamente dentro de la red interna
Solucin
De forma semejante al campo VIA, el problema es resuelto reescribiendo el
campo CONTACT
Surge otro problema
El campo CONTACT es referenciado por mensajes que ocurren despus de la
peticin original (como BYE o un re-INVITE)
Pero el NAT mantiene los registros de conexiones activas solamente por un
perodo limitado de tiempo.
Solucin
Algn programa que mantenga vivos esos registros de conexiones activas
30/09/2017 IT 536 M IMS 24
Transmisiones RTP
INICTEL-UNI

Problema
Los mensajes SDP, usados para la negociacin de puertos, cdec y etc.,
estn confinados en el cuerpo del mensaje y que por eso no son procesados
por el Proxy SIP, por las normas del IETF.
Contendrn informaciones vlidas solamente dentro de la red interna
Solucin cuando los dos UAs estn detrs de NAT
Se utiliza un Proxy RTP, lo que dividir la llamada en dos instancias
separadas
Solucin cuando apenas un UA est detrs de NAT
Se puede usar NAT simtrico, o
UA con IP vlido fuera de NAT usar el IP de flujo RTP, en lugar del IP
indicado por el SDP

30/09/2017 IT 536 M IMS 25

Convivencia con NAT
INICTEL-UNI

Problema de difcil solucin.

Mquinas detrs de NAT tpicamente se conectan normalmente, pero
consiguen flujos de audio solamente en un sentido.
Hay diversas alternativas de contorno, cada una adecuada a escenarios
diferentes
UPNP
STUN
TURN
ICE
ALG
Proxys con reescrita
VPN Veamos..
30/09/2017 IT 536 M IMS 26
UPNP
INICTEL-UNI

Universal Plug and Play

Servidor NAT y Cliente tiene que implementar el
protocolo.
Solucin adoptada por la Microsoft
Adecuada solamente para ambientes pequeos
Poco utilizada

30/09/2017 IT 536 M IMS 27

STUN
INICTEL-UNI

Simple Traversal of UDP through NAT

Permite al cliente descubrir cual IP pblico esta siendo utilizado por el servidor NAT para
su conexin.
Utiliza los puertos 3478 (TCP e UDP)
Puede utilizar la opcin DNS SRV para descubrir la direccin IP de los servidores STUN
asociados a un determinado dominio
dominio._STUN_UDP ou dominio._STUN_TCP
El Cliente STUN enva peticiones (requests) para el Servidor STUN (normalmente
asociado a la direccin IP pblica), que informa cual es el IP pblico que esta siendo
utilizado en el NAT, a travs de responses.
Flujos de media y sealizacin no pasan por el servidor STUN
No funciona adecuadamente cuando existen diversos equipamientos utilizando VoIP en la
red con direcciones privadas.
Depende del tipo de NAT que esta siendo adoptado por el servidor.

30/09/2017 IT 536 M IMS 28

TURN
INICTEL-UNI

Traversal Using Relay around NAT

Propuesta de IETF
Permite a los usuarios (cliente) detrs de NAT recibir data sobre
conexiones TCP o UDP
Usado por clientes detrs de NAT simtricos que estn sobre el extremo
de receptor de una conexin a un simple peer (telefona).
Similar al STUN, y funciona tambin como proxy de media y de
sealizacin.

30/09/2017 IT 536 M IMS 29

ICE
INICTEL-UNI

Interactive Connection Establishment

Proporciona un marco para evitar problemas de trfico VoIP en el que el
cliente tiene que registrarse con una direccin nica para el Proxy SIP.
Otro problema se refiere a que los servidores de seguridad pueden
bloquear trfico VoIP completamente.
Utiliza STUN y otros procedimientos
Enva sondas para probar los puertos entre los clientes.
Es necesario que los dos clientes implementen el protocolo.
Tambin poco utilizado.

30/09/2017 IT 536 M IMS 30

VPN
INICTEL-UNI

Virtual Private Network

Creacin de tneles entre clientes en redes Privadas con
servidores VPN en redes pblicas
Funciona en todos los casos
Puede utilizar cifrado
Problemas de escalabilidad?

30/09/2017 IT 536 M IMS 31

Algunos RFCs sobre SIP
INICTEL-UNI
RFC2327 SDP Session Description Protocol
RFC1889 RTP - Real-time Transport Protocol
RFC3261 SIP: Session Initiation Protocol, obsoleta
RFC2543
RFC3262 SIP PRACK method reliability for 1XX
messages
RFC3263 Locating SIP Servers SRV and NAPTR
RFC3265 SIP event notification SUBSCRIBE and NOTIFY
RFC3311 UPDATE Method, changing media
RFC3428 SIP extensions for Instant Messaging
RFC3515 SIP REFER method eg. call transfer
RFC3702 Authentication, Authorization, and Accounting
Requirements for the Session Initiation Protocol
30/09/2017 IT 536 M IMS 32
 INICTEL-UNI

CALIDAD DE SERVICIO PARA

TELEFONA IP

30/09/2017 IT 536 M IMS 33

Midiendo la Calidad
INICTEL-UNI
Evaluaciones Subjetivas
Mean Opinion Score (MOS)
1 (inaceptable) a 5 (excelente), indicando la calidad de audio (voz). Promedio
de opiniones de un gran grupo de usuarios.
Evaluaciones Objetivas
E-Model (ITU-T G.107 e ETSI ETR250)
Combina parmetros de performance en un modelo computacional complejo,
obteniendo parmetros que pueden ser mapeados en MOS. Percibida por un
usuario tpico.
Perceptual Evaluation of Speech Quality (PESQ) ITU-T P.862
Comparacin de un seal de referencia (voz previamente grabada) con la seal
degradada (sometido a sistema de transmisin)
Perceptual Speech Quality Measure (PSQM) ITU-T P.861
Perceptual Analisys Measurement System (PAMS)
30/09/2017 IT 536 M IMS 34
 E-Model versus MOS SATISFACCIN DEL USUARIO
INICTEL-UNI

R MOS
100 4.5
MUY SATISFECHO
Deseable 4.3
90
SATISFECHO
80 4.0

Aceptable ALGUNOS USUARIOS

INSATISFECHOS
70 3.6
MUCHOS USUARIOS
INSATISFECHOS
60 3.1
El resultado del E-Model es un factor escalar, CASI TODOS LOS
USUARIOS
llamado R (Transmission Rating Factor), 50 INSATISCHECHOS 2.6
que puede tomar valores entre 0 y 100.
0 NO RECOMENDADO 1

30/09/2017 IT 536 M IMS 35

E-Model Extendido
INICTEL-UNI

Matices no percibidos por el modelo E original

Cdecs son ms afectados con perdidas en rfagas.
La distribucin temporal de las perdidas afecta la percepcin
de calidad.
La perdida de calidad de voz es sentida muy rpido por el
usuario.
La mejora de calidad demora ms en ser sentida.
El modelo incorporando estos nuevos puntos es
denominado Modelo-E Extendido

30/09/2017 IT 536 M IMS 36

Influencia de la distribucin de prdidas
INICTEL-UNI

Paquete recibido

Paquete perdido

Llamada A (prdidas aisladas)

Llamada B (prdidas en rfagas)

Ambas llamadas poseen 25% de prdida (12 prdidas en 48 paquetes)

Entonces el MOS de A = MOS de B????
Probablemente NO.

30/09/2017 IT 536 M IMS 37

Influencia de la distribucin de prdidas
INICTEL-UNI

Perdidas con distribucin aleatoria versus perdidas en rfagas (codificador

G.711)

Aleatoria
En rfagas

G.711 con PLC ITU-T G.113

Prdida de paquetes (%)

30/09/2017 IT 536 M IMS 38

Efecto de memoria reciente
INICTEL-UNI

La localizacin de rfaga influencia en la percepcin

humana

Llamada con duracin de 60 segundos

INICIO FIN

RUIDO MOS 3.82

RUIDO MOS 3.28

RUIDO MOS 3.18

30/09/2017 IT 536 M IMS 39

Efecto de memoria reciente
INICTEL-UNI

El usuario no nota instantneamente la transicin de calidad

CALIDAD Patrn de calidad

conforme percepcin
de los usuarios
ALTA

Calidad de
transmisin

BAJA

30/09/2017 IT 536 M IMS 40

Influencia de Cdec en la calidad de voz
INICTEL-UNI

30/09/2017 IT 536 M IMS 41

Supresin de silencio y ruido de Comodidad
INICTEL-UNI

La Voz posee periodos activos (40%) y de silencio (60%), de

modo que la supresin de silencio puede economizar banda
El Anexo B de G.729 y Anexo A de G.723.1 describen el Detector
de Actividad de Voz (VAD) y el generador de ruido de comodidad
durante la supresin de silencio.
Entretanto, VAD puede presentar algunos problemas indeseables
como fallas en el comienzo de las palabras debido al umbral para
detectar la actividad de voz
Operar sin deteccin de silencio puede mejorar mucho la calidad
de una llamada!

30/09/2017 IT 536 M IMS 42

Factores impactantes de Calidad
INICTEL-UNI

Eco
Prdida
Banda
Atraso
Variacin de atraso

30/09/2017 IT 536 M IMS 43

Factores impactantes de Calidad
INICTEL-UNI

Eco
El retorno de voz que esta siendo transmitida por el canal de recepcin, que
puede ser local o remotamente es imperceptible si < 25 ms
Eco local es confundido con la propia voz, y no llega a ser un problema
Eco Acstico
Fraccin de seal acstico realimentada entre alto-parlantes y micrfono
Solucin: Usar headset
Eco Electrnico
Surge una desadaptacin de impedancia en la conversin analgica de los 2
hilos de la lnea del suscriptor a 4 hilos que hacen la conexin de los PBXs
(circuito hbrido)
Telfonos analgicos son de 2 hilos, pero las redes son de 4 hilos, con
canales independientes en cada sentido de la llamada
30/09/2017 IT 536 M IMS 44
Donde surge eco: 4 hilos a 2 hilos
INICTEL-UNI

Circuito hbrido para la conversin

30/09/2017 IT 536 M IMS 45

Factores Impactantes de calidad
INICTEL-UNI

Eco
En la telefona IP pura no existe eco electrnico, pues el
sistema es full dplex en todo el camino de la llamada.
Pero los largos atrasos envueltos en la telefona IP favorecen a
la aparicin de eco cuando las llamadas VoIP terminan en la
telefona tradicional.
Eco distante generado en los gateways VoIP/PSTN es el
problema crtico, y los canceladores de eco tienen que estar
habilitados en estos equipos cuando el atraso es en general
mayor de 30 ms.

30/09/2017 IT 536 M IMS 46

Funcionamiento del cancelador eco
INICTEL-UNI

El cancelador de eco usa una ventana de tiempo para comparar lo que llega
(Rin) con lo que es enviado (Sin)
Ventana de comparacin efectiva en torno de decenas de ms.
Distorsin puede perjudicar la comparacin.
Ventanas > 128 ms requieren circuitos ms sofisticados y ms caros.
30/09/2017 IT 536 M IMS 47
Eco Remoto
INICTEL-UNI

La seal de eco debe ser por lo menos 6 dB a 15 dB inferior a la seal de

voz en el mismo sentido, para no ser confundido con ella.
Un procedimiento tpico es atenuar la salida (signal out) y dar ganancia en la
entrada (signal in), para facilitar la operacin del circuito de cancelamiento.
ERL = echo return loss (cuanto mayor mejor)
ERLE = echo return loss enhancement (cuanto mayor mejor)
ACOM = atenuacin del eco medida del lado IP (cuanto mayor mejor)

30/09/2017 IT 536 M IMS 48

Factores impactantes de Calidad
INICTEL-UNI

Perdida de Paquetes
Vuelve a la conexin entrecortada y con fallas.
La mayora de los codificadores implementan algn
mecanismo para atenuar los efectos de prdida.
Packet Loss Concealment (PLC)
Algunos cdecs pueden corregir hasta 30 ms de prdida,
pero la prdida de dos o ms paquetes sucesivos
sobrepasa la ventana de correccin y ocurre degradacin
de la voz.
Forward Error Correction (FEC)
Ideal < 1%, menor que 2% es aceptable
30/09/2017 IT 536 M IMS 49
Factores impactantes de Calidad
INICTEL-UNI

Ancho de banda (en kbps)

Bajo consumo por llamada, variando en funcin del cdec y
tamao de cuadro.
Pero sin usar supresin de silencio, la banda necesaria puede
ser menor que los 64 kbps de la telefona tradicional.
Aumentar el tamao del cuadro para valores arriba de 30 ms
reducira el overhead por paquete pero la calidad de la voz es
afectada negativamente.
La Banda efectiva en la capa fsica depende tambin del tipo
de enlace.

30/09/2017 IT 536 M IMS 50

Consumo de Banda
INICTEL-UNI

30/09/2017 IT 536 M IMS 51

Consumo Real de Banda
INICTEL-UNI

Considerando overhead de nivel 2

30/09/2017 IT 536 M IMS 52

Consumo de Banda
INICTEL-UNI

Por razones de seguridad la media y la sealizacin pueden ser

codificadas.
Privacidad de la media puede ser conseguida con:
Cifrado de carga RTP
IPsec, VPN segura

Procesamiento y banda extras son necesarios.

30/09/2017 IT 536 M IMS 53

Compresin de Cabecera RTP (cRTP)
INICTEL-UNI

cRTP Compressed Real-Time Protocol

Compacta 40 bytes de cabecera en 2
o 4 bytes
Operacin hecha hop-by-hop
Esencial en enlaces lentos
Disminuye mucho el overhead
20 ms a 8 kbps genera 20 bytes
payload
Encabezamiento = 40 bytes
IP (20 bytes) + UDP (8 bytes) + RTP
El Tipo de cdec, muestras por paquete,
(12 bytes) VAD, y cRTP afectan, en una u otra manera,
el ancho de banda de una llamada.

30/09/2017 IT 536 M IMS 54

Componentes del Atraso
INICTEL-UNI

ITU-T G.114: atraso mx. de 150 ms para conversacin interactiva en cada

sentido, aunque 200 ms tolerable en la prctica
Atrasos en los codificadores de voz
De 25 ms. (G.729a) hasta 100 ms. (G.723.1)
Involucra: algoritmo, supresin de eco, supresin de ruido, etc.
Buffer de compresin de jitter
30 a 60 ms, en general, ms dinmico en funcin del jitter de la red.
Atrasos en las colas de los elementos de red (variable)
Atrasos de serializacin en las interfaces fsicas
Tiempo que un cuadro de datos debe esperar para que el otro paquete (el 1ro) se Tx bit a
bit en la interfaz o enlace.
Ts = Tamao del paquete / velocidad del enlace
Atrasos de propagacin en el medio fsico (5 ms/ 1000 km)

30/09/2017 IT 536 M IMS 55

Componentes del Atraso
INICTEL-UNI
Atraso de codificador
G.729 = 25ms
Atraso de serializacin
Enlace 64kbps=100ms
Cdec
Multiplexacin estadstica
G.729 Atraso de decodificador.
Atrasos variados (jitter) En general menor o igual
al atraso del codificador

PC Multiplexacin estadstica
Micro
Cliente VoIP Atrasos variados (jitter)
Decodec
Router
G.729

Router

Router

Buffer de compensacin de Jitter:

PC Elimina los atrasos variados
Acceso a web inducidos en la red.
Normalmente de 40 a 60ms

30/09/2017 IT 536 M IMS 56

Convergencia de Red
INICTEL-UNI

Convergencia para una nica red con mayor trafico y mayor banda es
mejor para el usuario?

30/09/2017 IT 536 M IMS 57

Convergencia de Red
INICTEL-UNI

B va a experimentar un acceso n veces mejor!

Sistemas grandes son ms eficientes!

Atraso en la cola es n veces

menor en esta situacin!

30/09/2017 IT 536 M IMS 58

Convergencia
INICTEL-UNI

La Convergencia no debe cubrir apenas la situacin fsica de la

red, debe incluir los recursos humanos, entrenamiento y gerencia
operacional de las aplicaciones.
Los Comportamientos tendrn que ser alterados
PBXs actualizan software una vez cada dos aos o menos, y
los equipos de datos emiten actualizaciones cada semestre o
menos.
Actualizaciones automticas pueden ser un riesgo inmenso y
simplemente podra ocurrir en los equipos de VoIP (misin
crtica).

30/09/2017 IT 536 M IMS 59

Factores impactantes de Calidad
INICTEL-UNI

Variacin de atraso
Grandes variaciones de atraso requieren grandes buffer de
compensacin de jitter para evitar perdida, lo que causa
perdida de calidad en la interactividad y facilita el
aparecimiento de eco.
Para disminuir la variacin de atraso de la red, solamente
priorizar el trfico de voz en colas muy congestionadas.
La variacin mxima tolerable, entre 20 ms y 50 ms en la
prctica.

30/09/2017 IT 536 M IMS 60

Atraso de Serializacin
INICTEL-UNI

Tiempo de gasto por un paquete en el buffer FIFO de la capa 2, que fuerza

la serializacin de la transmisin.
Ejemplo: Cisco implementa FIFO fsica como TX-RING
Crtico para enlaces de baja velocidad (< 1 Mbps)

Velocidad de TAMAO DE
enlace FRAGMENTACION
DE TRAMA O
PAQUETE

30/09/2017 IT 536 M IMS 61

Atraso de Serializacin
INICTEL-UNI

Atencin con los enlaces de baja capacidad y alta utilizacin donde la

priorizacin (QoS) tiene que ser aplicada.
Como la prioridad es aplicada en la capa 3, es necesario limitar el tamao de la
cola FIFO de la capa 2.
En baja velocidad (< 768 kbps), fragmentar paquetes grandes de datos para
garantizar tx_fragmento < 10 ms.
Trabajar con mltiples colas para permitir mezclar los paquetes (LFI link
fragmentation and interleaving)
Limitar los buffers de interface fsica (TX-RING) para garantizar atraso de
serializacin < 10 ms
Regla prctica (asumiendo tamao medio de paquetes de 700 bytes): TX-
RING (en paquetes) < 0,8 C (tasa en Mbps)

30/09/2017 IT 536 M IMS 62

TX-Ring
INICTEL-UNI

TX-Ring Buffer
TASA EN FR (kbps) (paquetes)

Para 768 kbps, TX-RING < =1,4 (2 mnimo), Default = 21 !

Para 10 Mbps, TX-RING < =18, (antiguo Cisco 2500 tiene Default = 32.000!)
Valor Default es mucho ms alto que lo deseado!

30/09/2017 IT 536 M IMS 63

Clasificacin de los paquetes
INICTEL-UNI

TOS
3 bits ms significativos indican la precedencia IP
DSCP
6 bits ms significativos del TOS son interpretados como:

30/09/2017 IT 536 M IMS 64

Recomendaciones de Clasificacin de Trfico
INICTEL-UNI

Trfico de Voz
DSCP EF = 46 decimal, precedencia IP = 5
Videoconferencia
DSCP AF41 = 34 decimal, precedencia IP = 4
Trfico de Sealizacin de Voz
DSCP AF31 = 26 decimal, precedencia IP = 3
Best-Effort
DSCP BE, precedencia IP = 0
Less-Than-Best-Effort
DSCP 2-6, precedencia IP = 0
30/09/2017 IT 536 M IMS 65
Cmo tratar con prdida, atraso y jitter?
INICTEL-UNI

Priorizar el trfico de voz en la capa 3 para disminuir la prdida, atraso y

variacin de atraso.
Marcar los paquetes e implementar cola con prioridad en los routers
(WFQ, PQ+WFQ, CBWFQ, etc.)

Para el trfico de datos en enlaces muy congestionados, habilitar

RED/WRED.
Evita la sincronizacin global en las sesiones TCP.
Mejora la utilizacin de los enlaces.
Disminuye la probabilidad de descartes de paquetes que llegan en
rfagas a una cola de router.

30/09/2017 IT 536 M IMS 66

Esquema de Priorizacin LLQ(PQ+CBWFQ)+LFI
INICTEL-UNI

Fragmentacin de paquetes
grandes:
El tamao del fragmento Priorizacin en la capa 3
definido de acuerdo con el
atraso necesario

LLQ: Low Latency Queuing

CBWFQ: Class-Based Weighted Fair Queuing

30/09/2017 IT 536 M IMS 67

Establecimiento de llamada VoIP
INICTEL-UNI

Involucra etapas:
Localizacin del usuario
Descubrir el IP destino con base en el nmero telefnico o
alias.
Negociacin de los parmetros para la llamada
Tipo de CODEC, etc.
Establecimiento de los canales para la media de voz
Puerto UDP para RTP/RTCP

30/09/2017 IT 536 M IMS 68

Protocolos de Sealizacin VoIP
INICTEL-UNI

ITU-T H.323
Estandarizadas por la comunidad de telecomunicaciones
Preocupacin con interoperabilidad y control

IETF SIP (Session Initiation Protocol)

Estandarizado por la Internet
Preocupacin con flexibilidad y facilidad de integracin con
Web
Otros
Skype, MGCP/Megaco/H.248, SIGTRAN
30/09/2017 IT 536 M IMS 69
 INICTEL-UNI

ITU-T H.323

30/09/2017 IT 536 M IMS 70

Introduccin a H.323
INICTEL-UNI

Dedicado a la centralizacin de control por su gestacin en la comunidad de

telecomunicaciones.
Su complejidad puede llevar a errores de implementacin.
No fue concebido para ser extensible y su integracin con otros protocolos
es difcil.
Posee una arquitectura monoltica sin necesidad de prestarse
funcionalidades de otros protocolos
H.323 usa una codificacin binaria (no es modo texto)
Proceso de depuracin ms difcil
Sujeto a ataques que causan overflow de buffers
Su falta de flexibilidad favorece la seguridad, pero limita su adaptabilidad y
soporte a nuevos servicios.
30/09/2017 IT 536 M IMS 71
H.323 y SIP
INICTEL-UNI

Tanto el conjunto de protocolos H.323, propuesto por la ITU-T,

como el protocolo SIP, propuesto por el IETF, definen
mecanismos de sealizacin para establecer y terminar llamadas,
as como otras funciones de control de conferencia, negociacin
de capacidades y servicios adicionales sobre redes de
conmutacin de paquetes.
SIP se dise despus con la pretensin de presentar dos
ventajas frente a H.323:
Mayor flexibilidad para incorporar nuevas funciones.
Implementacin ms fcil de realizar y depurar.

30/09/2017 IT 536 M IMS 72

H.323 y SIP
INICTEL-UNI

SIP es un protocolo ligero similar a otros desarrollados previamente

por el IETF y de amplia extensin, como HTTP.
H.323 sigue un esquema similar al sistema tradicional de conmutacin
de circuitos, basndose en la sealizacin de la red digital de servicios
integrados, ISDN, y otras recomendaciones de la serie H.
Las arquitecturas en las que se basan H.323 y SIP son
sustancialmente distintas; sin embargo, al comparar la evolucin de
ambos estndares durante los
ltimos aos, se extrae la conclusin de que, a medida que se definen
nuevas ampliaciones a SIP y aparecen nuevas versiones de H.323
cada vez se diferencian menos en cuanto a las funciones y
posibilidades que ofrecen.
30/09/2017 IT 536 M IMS 73
H.323 y SIP
INICTEL-UNI

Un factor comn a ambas arquitecturas es el protocolo de

transporte utilizado para el intercambio de datos multimedia
durante las sesiones que, aunque no est prefijado, en la prctica
es RTP.

30/09/2017 IT 536 M IMS 74

H.323 y SIP
INICTEL-UNI

Como precondiciones generales para una arquitectura que debe dar soporte,
al menos, a un sistema global de telefona que coexista con (posiblemente
sustituya) a la red telefnica tradicional se deben tener en cuenta las
siguientes:
Escalabilidad hasta un gran nmero de usuarios de todo el mundo as
como un gran nmero de llamadas activas de forma simultnea, del orden
de millones.
Permitir gestionar la red, de modo que sea posible aplicar polticas de
control y tarificacin.
Proporcionar mtodos de seleccin de calidad de servicio.
Interoperabilidad entre diferentes fabricantes, protocolos y versiones de
protocolos.
Facilidad de ampliacin.
30/09/2017 IT 536 M IMS 75
Comparando H.323 y SIP
INICTEL-UNI

A continuacin se compara, a grandes rasgos, las arquitecturas

de control de sesiones multimedia H.323 y SIP, segn criterios
de:
Complejidad
Despliegue
Escalabilidad
Servicios ofrecidos
Funcionamiento.

30/09/2017 IT 536 M IMS 76

Comparando H.323 y SIP: Complejidad
INICTEL-UNI

Es mayor la complejidad de la Recomendacin H.323 que la del

protocolo SIP.
Las 46 cabeceras de SIP (originalmente 37) tienen un reducido
nmero de valores y parmetros, comparados con los cientos de
elementos definidos en H.323.
SIP es un protocolo de codificacin textual, donde es posible
utilizar analizadores y realizar generacin de mensajes mediante
scripts en lenguajes como Perl o Tcl, facilitando su integracin
con los entornos web. Sin embargo, H.323 requiere generalmente
el uso de herramientas de generacin de analizadores para
sintaxis ASN.1
30/09/2017 IT 536 M IMS 77
Comparando H.323 y SIP: Complejidad
INICTEL-UNI

El establecimiento de llamadas H.323 supone la intervencin de

varios de los protocolos asociados, en un proceso en el que los
elementos que intervienen deben mantener el estado de la
sesin.
En cambio todas las operaciones del protocolo SIP se basan en
el intercambio de peticiones y respuestas individuales. Este factor
tiene una gran influencia en la escalabilidad de la arquitectura.

30/09/2017 IT 536 M IMS 78

Comparando H.323 y SIP: Despliegue
INICTEL-UNI

El despliegue es un factor importante para el xito de los protocolos

de sesiones multimedia, al tiempo que es crucial que los
dispositivos diseados para distintas versiones y por distintos
fabricantes sean compatibles entre s en la ejecucin de un
conjunto mnimo de funciones.
Por ejemplo en SIP se han tomado como precedente la evolucin
de dos protocolos muy extendidos: HTTP y SMTP.
Esto ha llevado a prever mecanismos para garantizar la
compatibilidad entre diferentes versiones del protocolo, as como
mtodos de ampliacin basados en el registro de nuevas
caractersticas a travs de la IANA.
30/09/2017 IT 536 M IMS 79
Comparando H.323 y SIP: Despliegue
INICTEL-UNI

En H.323 tambin se reservan algunos campos para futuras

ampliaciones especficas del fabricante; sin embargo, stas slo
se pueden realizar en aquellas partes donde se ha previsto de
forma explcita.
Adems, no existen mecanismos para determinar qu
ampliaciones admite un dispositivo, por lo que el uso de estas
ampliaciones conlleva riesgos de incompatibilidad entre distintos
fabricantes.

30/09/2017 IT 536 M IMS 80

Comparando H.323 y SIP: Despliegue
INICTEL-UNI

Respecto al uso de formatos multimedia estandarizados:

Las sesiones controladas usando SIP, emplean el formato SDP,
que es un procedimiento plenamente abierto.
Las sesiones controladas usando H.323 solo pueden usar
formatos registrados a travs de una entidad central, ITU-T.

30/09/2017 IT 536 M IMS 81

Comparando H.323 y SIP: Despliegue
INICTEL-UNI

Respecto a la modularidad del sistema:

El protocolo SIP comprende funciones de sealizacin bsica,
localizacin y registro de usuarios. Otras funciones, como
garanta de calidad de servicio, descripcin de contenidos,
servicios de directorio y control de conferencia se delegan en
otros protocolos.
Entonces, cada protocolo empleado en una arquitectura SIP es
plenamente intercambiable.
Mientras que la arquitectura establecida por la recomendacin
H.323 define un conjunto de componentes acoplados que cubren
un mayor rango de funciones.
30/09/2017 IT 536 M IMS 82
Comparando H.323 y SIP: Escalabilidad
INICTEL-UNI

Se debe considerar la simplicidad para la gestin del gran nmero

de sesiones que puede llegar a procesar los componentes de la
infraestructura telefnica de Internet.
En este aspecto, SIP no requiere mantener estados en elementos
intermedios y utiliza fundamentalmente conexiones UDP o de
otros protocolos que requieren menos recursos que TCP, como
SCTP.
Por el contrario, H.323 requiere que los elementos intermedios
mantengan el estado a lo largo de toda la sesin, y slo emplea
UDP a partir de la versin 3 (la versin 7, Nov-2009), debiendo
mantener la compatibilidad con versiones previas plenamente
basadas en conexiones TCP.
30/09/2017 IT 536 M IMS 83
Comparando H.323 y SIP: Escalabilidad
INICTEL-UNI

Tanto H.323 como SIP admiten sesiones con mltiples

participantes y transporte multicast.
No obstante, a diferencia de la especificacin de H.323, la
especificacin de SIP no define ninguna entidad central para
coordinar las sesiones, estableciendo un modelo de control
plenamente distribuido.
SIP al basarse fundamentalmente en UDP, puede distribuir
mensajes en modo multicast. Por ello, a igualdad de recursos
disponibles, el nmero de participantes en una sesin controlada
mediante SIP puede llegar a ser mayor que en una sesin H.323.

30/09/2017 IT 536 M IMS 84

Comparando H.323 y SIP: Escalabilidad
INICTEL-UNI

La versin inicial de H.323 se dise para utilizarse en redes de

rea local, por lo que, aunque las ltimas versiones han
incorporado mtodos de localizacin de usuarios, carece de
algunos mecanismos, como prevencin de bucles.
Sin embargo, SIP se ha diseado para redes de rea extensa,
por lo que cuenta con mecanismos flexibles de localizacin y
registro de usuarios definidos con suficiente generalidad, como
bsqueda a travs de un nmero indefinido de servidores proxys,
bsqueda en paralelo y ramificacin.

30/09/2017 IT 536 M IMS 85

Comparando H.323 y SIP: Servicios ofrecidos
INICTEL-UNI

A medida que SIP y H.323 evolucionan de forma competitiva, el

conjunto de servicios que ambos ofrecen va parecindose ms.
Como excepcin, H.323 proporciona servicios de negociacin de
contenidos mucho ms completos que los de SIP, permitiendo
especificar complejas combinaciones de formatos multimedia
admitidos por los dispositivos, junto con diversos parmetros de
estos formatos. SIP prev nicamente el intercambio de
conjuntos de formatos admitidos.

30/09/2017 IT 536 M IMS 86

Comparando H.323 y SIP: Funcionamiento
INICTEL-UNI

Establecer una llamada con H.323 versiones 1 o 2 requiere establecer,

previamente a la conexin H.323, conexiones TCP para H.225.0 y H.245.
Por el contrario, el establecimiento de una llamada SIP slo requiere un
intervalo de ida y vuelta de paquetes en el caso ms comn, puesto que se
realiza mediante un mensaje transportado generalmente sobre UDP.
A partir de la versin 3, H.323 permite iniciar llamadas mediante UDP. No
obstante, el establecimiento de llamadas es aun as normalmente ms
rpido con SIP; sin embargo, H.323 puede solventar con mayor rapidez
situaciones de error.
No obstante, con la incorporacin de SCTP como protocolo de transporte
para sealizacin SIP, se mejora las prestaciones en situaciones con un
elevado porcentaje de errores en la transmisin.

30/09/2017 IT 536 M IMS 87

H.323: Esquema de arquitectura
Terminal INICTEL-UNI
Terminal
Red de Conmutacin
de paquetes (IP)
Gatekeeper

Router
Terminal Terminal

Pasarela

Red de conmutacin
de circuitos
(ISDN o Red Pblica)

30/09/2017 IT 536 M IMS 88

 INICTEL-UNI

El proceso de finalizacin de llamadas se lleva a cabo mediante sendos

mensajes RELEASE, COMPLETE y BYE, para H.323 y SIP,
respectivamente.
En cuanto al control durante la llamada, tanto SIP como H.323 proporcionan
servicios suplementarios que permiten modificar y comprobar el estado de
una sesin durante su desarrollo, como desconexin provisional,
identificacin de llamadas, llamadas en espera o redireccin y transferencia
de llamadas.

30/09/2017 IT 536 M IMS 89

Arquitectura H.323
INICTEL-UNI

Los sistemas basados en sealizacin H.323 se articulan en

torno a cuatro tipos de componentes: terminales, pasarelas,
gatekeepers y unidades de control multipunto.
Los mensajes H.323 siguen un esquema de codificacin binaria,
especificada mediante sintaxis ASN.1 y reglas de codificacin de
paquetes (PER).

30/09/2017 IT 536 M IMS 90

Arquitectura H.323
INICTEL-UNI

30/09/2017 IT 536 M IMS 91

Arquitectura H.323
INICTEL-UNI

30/09/2017 IT 536 M IMS 92

Recomendaciones H.323
INICTEL-UNI

30/09/2017 IT 536 M IMS 93

Terminales
INICTEL-UNI

Son los clientes situados en redes IP. Se comunican

bidireccionalmente y en tiempo real con el resto de elementos de
los sistemas H.323. Deben ser capaces de comunicarse
mediante los protocolos de control H.225 y H.245, as como de
transmitir datos en tiempo real sobre RTP/RTCP.
Asimismo, pueden contener varios codificadores y
decodificadores de formatos de sonido y vdeo, de entre los
cuales, el formato de sonido G.711 (PCM) es obligatorio, con
objeto de garantizar una mnima compatibilidad entre todos los
terminales.

30/09/2017 IT 536 M IMS 94

Pasarelas
INICTEL-UNI

Encargadas de conectar redes de conmutacin de paquetes con

redes de conmutacin de circuitos, ya sean pblicas o privadas.
Deben ser capaces de establecer y controlar llamadas en ambos
tipos de redes, traduciendo los distintos formatos y
procedimientos de transmisin.
Su presencia, del mismo modo que la conexin a redes de
conmutacin de circuitos, es opcional.

30/09/2017 IT 536 M IMS 95

Gatekeepers
INICTEL-UNI

Su presencia en un sistema es asimismo opcional; sin embargo,

cuando estn presentes deben desempear cuatro funciones:
Control de admisin
Control de ancho de banda
Traduccin de direcciones alias o nmeros de telfono a
direcciones de transporte, y viceversa.
Gestin de zonas.
Cuando existe un gatekeeper en el sistema, todos los dispositivos
deben registrarse y obtener permiso de l antes de realizar
llamadas.

30/09/2017 IT 536 M IMS 96

Unidades de control multipunto (MCU)
INICTEL-UNI

Permiten que se establezcan conferencias entre tres o ms

elementos.
Generalmente constan de un controlador multipunto y un nmero
variable de procesadores multipunto.
En terminologa H.323, un canal es equivalente a una conexin
de nivel de transporte.
La recomendacin H.323 especifica cuatro tipos de canales:

30/09/2017 IT 536 M IMS 97

Unidades de control multipunto (MCU)
INICTEL-UNI
Canal de sealizacin de llamada. Por el cual circula la
informacin relativa al control de llamadas y servicios adicionales.
El protocolo de control utilizado se especifica en las
recomendaciones H.450 y H.225.0
Canal de control H.245. Dedicado al control de la transferencia de
informacin multimedia y la negociacin de capacidades.
Canal de control RAS. Destinado a la comunicacin entre los
terminales y sus Gatekeepers asociados.
El protocolo RAS (registro, admisin y estado) est
especificado en la norma H.225.0 y permite que los terminales
se registren ante un gatekeeper y soliciten permiso para
establecer llamadas.
30/09/2017 IT 536 M IMS 98
Unidades de control multipunto (MCU)
INICTEL-UNI

Canales lgicos para informacin multimedia. Por donde circulan

los datos de sonido, vdeo y cualquier otro medio.
Cada uno de ellos se transporta mediante una sesin RTP.

30/09/2017 IT 536 M IMS 99

 INICTEL-UNI

http://www.packetizer.com/ipmc/papers/understanding_voip/voip_protocols.html

COMENTARIOS

30/09/2017 IT 536 M IMS 100

Comentarios
INICTEL-UNI

Fundamentally, H.323 and SIP allow users to do the same thing:

to establish multimedia communication (audio, video, or other
data communication).
However, H.323 and SIP differ significantly in design, with H.323
borrowing heavily from legacy communication systems and being
a binary protocol, and with SIP not adopting many of the
information elements found in legacy systems and being an
ASCII-based protocol.
Supporters of each protocol have debated at length as to which
approach is better and the results are certainly mixed.
http://www.packetizer.com/ipmc/papers/understanding_voip/voip_protocols.html
30/09/2017 IT 536 M IMS 101
Comentarios
INICTEL-UNI

Over the years, there have been a lot of papers debating H.323
vs. SIP, but most of the arguments have often been "religious" in
nature (e.g., "ITU vs. IETF" and "binary versus ASCII").
Very few of the papers and reports have compared the protocol
on the basis of functionality and what really matters: does the
protocol do the job?

http://www.packetizer.com/ipmc/papers/understanding_voip/voip_protocols.html
30/09/2017 IT 536 M IMS 102
Comentarios
INICTEL-UNI

The fact is, both can do the job, though H.323 is superior in a number of
ways: better interoperability with the PSTN, better support for video, excellent
interoperability with legacy video systems (e.g., H.320), and reliable out-of-
band transport of DTMF. SIP, being a "session initiation protocol", was not
designed to address many of the problems that were raised and solved in
legacy communication systems.
SIP was also popularized in the market through misstatements that it was
"easy to implement and debug". The truth is that there is a certain amount of
complexity in any communication system and, no matter how one looks at it,
it requires about the same amount of work to do the same thing two different
ways.

http://www.packetizer.com/ipmc/papers/understanding_voip/voip_protocols.html
30/09/2017 IT 536 M IMS 103
Comentarios
INICTEL-UNI

Both H.323 and SIP can be referred to as "intelligent endpoint

protocols".
What this means is that all of the intelligence required to locate
the remote endpoint and to establish media streams between the
local and remote device is an integral part of the protocol.
There is another class of protocols which is complementary to
H.323 and SIP referred to as "device control protocols". Those
protocols are H.248 and MGCP.

http://www.packetizer.com/ipmc/papers/understanding_voip/voip_protocols.html
30/09/2017 IT 536 M IMS 104
Comentarios
INICTEL-UNI

To understand the purpose of H.248 and MGCP, it is important to

first understand the function of a gateway.
A gateway is a device that offers an IP interface on one side and
some sort of legacy telephone interface on the other side. The
legacy telephone interface may be complex, such as an interface
to a legacy PSTN switch, or may be a simple interface that allows
one to connect one or a few traditional telephones.
Depending on the size and purpose of the gateway, it may allow
IP-originated calls to terminate to the PSTN (and vice-versa) or
may simply provide a means for a person to connect a telephone
to the Internet.
http://www.packetizer.com/ipmc/papers/understanding_voip/voip_protocols.html
30/09/2017 IT 536 M IMS 105
Comentarios
INICTEL-UNI

Originally, gateways were viewed as monolithic devices that had

call control (H.323/SIP) and hardware required to control the
PSTN interface.
In 1998, the idea of splitting the gateway into two logical parts was
proposed: one part, which contains the call control logic, is called
the media gateway controller (MGC) or call agent (CA), and the
other part, which interfaces with the PSTN, is called the media
gateway (MG). With this functional split, a new interface existed
(going between the MGC and MG), driving the necessity to define
MGCP and H.248.

http://www.packetizer.com/ipmc/papers/understanding_voip/voip_protocols.html
30/09/2017 IT 536 M IMS 106
Comentarios
INICTEL-UNI

Some service providers provide users with devices that implement H.248 or
MGCP (or comparable protocols).
In the core of the network, some device serving as the MGC provides the
H.323 or SIP logic necessary to properly terminate VoIP calls around the
world.
Outside of H.323/SIP and H.248/MGCP, there are also non-standard
protocols introduced by various companies that have been very successful in
the market.
Skype is one such company that has been extremely successful using a
proprietary protocol. Which protocol is best for you? It really depends on your
requirements, but most people simply want to make a phone call and, as
such, it really does not matter.
http://www.packetizer.com/ipmc/papers/understanding_voip/voip_protocols.html
30/09/2017 IT 536 M IMS 107
Comentarios
INICTEL-UNI

It is also important to remember that, just as with every other new

capability introduced in the world of high-tech, there is always
something new and bigger coming down the road.
Presently, the ITU is working on a new protocol that will have
much more capability than either SIP or H.323. The new protocol
is referred to as H.325 and is expected to enable voice, video,
and data communications capabilities across a number of
separate devices that work together, such as a mobile phone, a
PC, and even an HD TV!

http://www.packetizer.com/ipmc/papers/understanding_voip/voip_protocols.html
30/09/2017 IT 536 M IMS 108
Referencias
INICTEL-UNI

http://www.h323forum.org/about/
http://www.itu.int/rec/T-REC-H.323-200912-I/en

30/09/2017 IT 536 M IMS 109