1.03 Introduccion PIII

Capítulo 1.
03:
Teoría VoIP
Tiempo real sobre conmutación de
paquetes
Fabián Pignataro – fabianpignataro84@gmail.com
RHCSA Red Hat Certified Sys. Admin.
dCAP DigiumCertified Asterisk Professional
ECE Elastix Certified Engineer
VoIP - Introducción
Telefonía IP, telefonía sobre internet, voz sobre IP o VoIP (Voice over Internet Protocol), viene a
significar una misma cosa: un servicio que permite una comunicación telefónica convencional
utilizando la red de internet para establecerla, mantenerla y finalizarla.
Qué pasa cuando hacemos una llamada telefónica utilizando VoIP?

Cuando hacemos una llamada telefónica por IP, nuestra voz se digitaliza (muestro-cuantización-
codificación) utilizando algún codec, se fragmenta en paquetes de datos IP y se transmiten estos
paquetes por la red, en el destino los paquetes son ordenados, desemcapsulados y convertidos
nuevamente a la señal de voz original.
Los terminales VoIP, ya sean softphone, teléfonos I o teléfonos convencionales con adaptadores
ATA, deben poseer una dirección IP para poder operar, es decir: son un host más dentro de una red.
Ventajas de la VoIP:
- Mejor utilización de los recursos

- Inferior costo de los equipos
- Mantenimiento y Gestión centralizada
- Movilidad
Mitos de la telefonía IP:
- Solo funciona en Internet

- Los terminales son caros
- Es complicado utilizar sus terminales
La VoIP por dentro
Como sabemos, para transmitir voz sobre el protocolo IP, la información a intercambiar (voz), debe
sufrir una serie de transformaciones de su forma y secuencia.
Cuerdas vocales → Micrófono → Digitalizacion (codec) → Fragmentación en paquetes
CODECS: Codificación de la voz
Si bien ya hemos estudiado el proceso de digitalización y codificación de la voz, vamos a volver a

repasarlo ya que está muy relacionado con los protocolos de transporte de voz y señalización, en los
que nos enfocaremos en este capítulo.
Una vez codificada una señal analógica, habrá que fragmentarla en paquetes IP y transmitirla por la
red, bien sea esta una red IP privada, pública o Internet. Pero debemos ir por partes y vamos a
centrarnos en la codificación.
La palabra codec proviene de abreviar las palabras COdificacion y DECodficacion. Su función
principal es la de adaptar la información digital de la voz para obtener algún beneficio. Este
beneficio en muchos casos es la compresión de la voz de tal manera que podamos utilizar menos
ancho de banda del necesario.
Vamos a repasar algunos codecs con los cuales vamos a trabajar:
G.711
Es un codec de forma de onda que como vimos, utiliza una velocidad de muestreo de 8 KHz usando
8 bits para cuantificar cada muestra, lo que nos da un ancho de banda de 64 kbps para la
transmición. G.711 utiliza cuantificación no uniforme en dos variantes: Ley u (G.711 U) utilizada
en EEUU y Japón y Ley A (G.711 A) utilizada en Europa y el resto del mundo.
Una de sus características es la calidad de voz debido a que casi no la comprime. Utiliza 64kbit/s, es
decir un muestreo de 8 bits a 8kHz. Es el codec recomendado para redes LAN pero hay que
pensarlo dos veces antes de utilizarlo en enlaces remotos debido al alto consumo de ancho de
banda.
G.729
También se trata de una recomendación ITU cuyas implementaciones ha sido históricamente

licenciadas, o sea que hay que pagar por ellas. La ventaja en la utilización de G.729 radica
principalmente en su alta compresión y por ende bajo consumo de ancho de banda lo que lo hace
atractivo para comunicaciones por Internet.
Pese a su alta compresión no deteriora la calidad de voz significativamente y por esta razon ha sido
ampliamente usado a través de los años por muchos fabricantes de productos de VoIP. G.729 utiliza
8kbit/s por cada canal. Si comparamos este valor con el de G.711 notaremos que consume 8 veces
menos ancho de banda, lo cual a simple vista es un ahorro de recursos significativo, pero como nada
es gratis, este ahorra de BW lo pagamos con carga para el procesador que codifica en este formato.
GSM
El estándar que define la tecnología celular GSM (Global System for Mobile communications)
incluye este codec, por lo que todos lo conocemos.
La ventaja de este codec también es su compresión. Acerca de la calidad de voz… bueno, ya
habremos hablado por un celular GSM alguna vez, existe una degradación pero la voz es totalmente
identificable y su calidad es aceptable. GSM comprime aproximadamente a 13kbit/s.
SPEEX
Speex está diseñado para comprimir voz a tasas desde 2 a 44 kbps y posee características que no
tienen otros códecs de voz como codificación de intensidad estéreo, integración de múltiples
frecuencias de muestreos en el mismo bitstream y modo VBR.
Speex no está diseñado para teléfonos celulares, pero si para Voz sobre IP (VoIP) y compresión
basada en archivos.
Las metas en el diseño eran permitir buena calidad en la voz y baja tasa (desafortunadamente no al
mismo tiempo). Buena calidad también significaba tener soporte para wideband (frecuencia de
muestreo de 16 kHz), además de narrowband (calidad de teléfono, frecuencia de muestreo de 8
kHz).
Características generales :
– Software libre/código libre, libre de patentes y regalías.

– Integración de narrowband y wideband en el mismo bitstream.
– Amplio rango de bitrate disponible (desde 2 kbps a 44 kbps).
– Cambio dinámico de bitrate y Variable BitRate (VBR).
– Detección de actividad de voz (VAD en sus siglas en inglés, integrado con VBR).
– Complejidad variable.
– Modo Ultra-wideband de 32 kHz.
– Opción de codificación de intensidad estéreo.
Vamos a volver a repetir, para cualquier tipo de codificador utilizado a la salida del mismo la señal
recientemente codificada debe ser empaquetada y transmida por la red, dentro de paquetes IP. Pero
antes de llegar a la capa 3, van a ser procesados por los “protocolos VoIP”.
Protocolos
Hay muchos protocolos involucrados en la transmisión de voz sobre IP.
Figura 1 – Protocolos involucrados
Como sabemos, internet se creó en un principio para transportar información de manera fiable, pero
sin que el tiempo de entrega afecte demasiados por sobre la fiabilidad de que la información llegue
intacta. Como ahora la información que se está intentando enviar por Internet (voz y/o video),
llamada de “tiempo real”, no prioriza tanto que toda la información llegue totalmente intacta al
destino, sino que se prefiere que sea en un tiempo prudencial y sobre todo a un flujo constante de
paquetes, aparecen ciertos protocolos para poder traficar dicha información “de tiempo real” sobre
una red que no fue pensada para tal fin.
Por dicho motivo aparecen una serie de protocolos que vamos a clasificar y estudiar a continuación,
ya que son los que permiten la existencia del tiempo real sobre Internet.
Clasificacion los protocolos VoIP
- Protocolos de señalización
Los protocolos de señalización en VoIP cumplen la funció de señalizar (valga la redundancia) las
llamadas, con señalizar estamos diciendo (inicializar, mantener y finalizar) cada llamada.
Dichos protocolos se encuentran en la capa 5 del modelo OSI, es decir en al capa de Sesión.
Algunos son:
• SIP
• IAX
• H.323
• MGCP
• SCCP
- Protocolos de transporte de voz
Dentro de este grupo no se encuentran los protocolos de la capa de transporte (no confungir), si no
que dentro de este grupo nos referimos al protocolo que transporta la voz propiamente dicha
(envuelve la voz como payload). Este protocolo entra a funcionar una vez que el protocolo de
señalización ha establecido una sesión entre los participantes y por ende se comienzan a
intercambiar fragmentos de voz (paquetes).
- Protocolos de plataforma IP
Aquí vamos a agrupar los protocolos básicos de redes IP y que forman la base sobre la cual se
añaden los protocolos de voz anteriores. Éstos procolos de base son: Ethernet, IP, TCP y UDP.
Figura 2 – Clasificación de protocolos
El protocolo SIP
Introducción
El protocolo SIP (Session Initialization Protocol) es un protocolo de señalización creado para

administrar sesiones multimedia entre dos o más partes.
Este protocolo ha sido definido por la IETF (The Internet Engineering Task Force) que es la entidad
que se encarga de definir los estándar para la red Internet. Justamente al tratarse de un protocolo
pensado desde Internet, para ser utilizado en Internet, es considerado como una gran ventaja.
SIP aporta lo impresindible para poder establecer una sesión (voz, video, juegos interactivos, datos)
entre dos equipos de Internet, utilizando una filosofía similar a protocolos como HTTP, SMTP, etc.
SIP puede establecer sesiones entre dos participantes, entre múltiples participantes (donde todos
pueden hablar y escuchar) y en modo multidifusión (donde uno habla y los otros escuchan). De las
misma forma dichas sesiones pueden contener audio, video o datos. Esto permite que se pueda
ejecutar cualquier tipo de aplicaciones simultáneamente a la comunicación de voz o video (por
ejemplo enviar un archivo ó un mensaje instantáneo).
Otra paticularidad de SIP es que puede incluir campos opcionales con información específica del
usuario. Esto permite hacer cosas interesantes como incluir en la invitación de la llamada el motivo
de la misma o un mensaje tipo “es urgente”, se puede tambien manejar estados, “disponible”,
“ausente”, etc, programar contestaciones automáticas “te llamó después de las 17:30 hs”.
La Arquitectura SIP
Como dijimos, SIP es un protocolo de señalización, concebido para controlar el establecimiento,

modificación y finalización de sesiones multimedia. Por lo tanto una vez establecida la sesión, el
intercambio de información multimedia se lleva a cabo entre los participantes de la sesión SIP
utilizando protocolos de intercambio de media (generalmente RTP/RTCP).
Figura 3 – Protocolo SIP en acción
SIP suele utilizar ahbitualmente UDP como protocolo de capa de transporte, pero también soporta
trabajar con TCP y TLS.
La arquitectura SIP se basa en un modelo peer-to-peer en el que el cliente realiza solicitudes

(requests) al servidor, quien le responde (responses) ya sea para aceptar, rechazar o redirigir dichas
solicitudes, pero dependiendo de quien tenga la intención de iniciar la sesión, se intercambian los
roles entre servidor y cliente. Entonces afirmamos que un terminal SIP puede trabajar como cliente
enviando solicitudes (cuando quiere llamar) y como servidor otorgando respuestas a solicitudes
(cuando es llamado).
La arquitectura SIP considera la existencia de múltiples componentes:
– Los equipos terminales UA (User Agent), que disponen de dos módulos
– UAC (User Agent Client): se trata de la aplicación que permite que el terminal pueda
iniciar una sesión (enviar solicitudes SIP). En el contexto VoIP la parte del teléfono
que realiza una llamada SIP.
– UAS (User Agent Server): se trata de la aplicación que permite que el termina pueda
procesar solicitudes SIP (aceptar llamados por ejemplo) y enviar respuestas SIP a
dichas solicitudes.
Ambos módulos le dan la funcionalidad completa al terminal.
– Servidor Proxy: se trata de un agente que recibe solicitudes de un UAC, las analiza y
decide si dichas solicitudes debe enviarlas a un UAC o a otro Servidor Proxy, habitualmente el
Servidor Proxy modifica la solicitud antes de enviarla, para el siguiente destino de la solicitud, el
mensaje procede de dicho Proxy. Una solicitud puede atravesar varios servidores proxy hasta
alcanzar el destino. El proxy server obviamente dispone de los dos módulos (UAC y UAS).
Figura 4 – SIP Proxy Server
– Servidor de redireccionamiento: este tipo de servidor solamente se limita a responder a las

solicitudes al cliente con la dirección del UAS o Servidor Proxy a quien deben enviar la solicitud en
lugar de lugar de enviarlos el mismo.
Figura 5 – Servicor de redireccionamiento
– Servidor de registro: recibi solicitudes de registro de los UA y mantiene una tabla con las
direcciones SIP de los usuarios y sus respectivas direcciones IP. Gracias a este servidor, se puede
localizar un UA registrado al momento de tratar de iniciar una sesión con el. Como sabemos una de
las ventajas del SIP es la movilidad del usuario (puede realizar el registro desde el teléfono de su
oficina, desde el softphone de se notebook o desde el softphone dentro de su smartphone) y el
Servidor de Registro guardará su ubicación para cuando alguien intente localizarlo.
Figura 6 – Servidor de registro
Generalmente los servicios de Proxy, Redirección y Registro se encuentran corriendo dentro de un

mismo equipo.
URI – Las direcciones SIP
El formato se basa en la estructura de direccionamiento empleada en Internet y conocida como URL

(Uniform Resource Locators).
Formato de una URI SIP
sip:usuario@dominio;parámetro=valor
Este tipo de direccionamiento nos permite por ejemplo que se utilice un número telefónico
tradicional en el campo usuario y en el dominio la dirección del gateway que interconecta la red SIP
con la red telefónica PSTN donde se encuentra dicho número.
Ejemplos:
sip:usuario@dominio
sip:usuario@dominio;transport=TCP
sip:5493516313933@190.210.6.162
El diálogo SIP
Como adelantamos más arriba tenemos dos tipos de mensajes, solicitudes (requests) y respuestas
(responses). El cliente de la sesión enviara una solicitud que será respondida por el servidor.
Si examinamos el paquete SIP, tanto las solicitudes como las respuestas están compuestas de:
– Una linea de inicio, indica si el mensaje es solicitud o respuesta.
– Una cabecera: formada por varios campos. Dichos campos contienen información adicional
a ls solicitud o respuesta en cuestión. Por ejemplo incluye el remitente y destinatario del paquete.
– El cuerpo del paquete, SIP no define el payload ni se ocupa de lo que haya. Generalmente
el payload del SIP es un paquete SDP (Session Description Protocol) que lo que hace es especificar
los parámetros de la sesión que se quiere establecer. Esto ocurre en los paquetes SIP de inicio de
sesión que intercambian la partes Solicitudes “INVITE” y/o Respuestas “200 OK”.
Figura 7 – Paquete SIP
Como dijimos arriba, los mensajes SIP pueden ser Solicitudes (Requests) o Respuestas (Responses).
Solicitudes (Métodos), en la versión 2.0 de SIP se incluyen seis tipos de métodos:
• INVITE: un dispositivo lo envía para inciar una llamada

• ACK: lo envía el UAC al UAS como confirmación de la respuesta. Solo se manda cuando
son códigos de respuestas frente a una solicitud INVITE.
• OPTIONS: son mensajes que se utiliza para preguntar a un UA sobre capacidades. Tambien
usado para saber si un UA está alcanzable.
• BYE: este mensaje se utiliza para terminar una llamada.
• CANCEL: se utiliza para anular una solicitud de inicio de sesión INVITE que aún no se ha
establecido.
• REGISTER: se utiliza para que los UA puedan dejar registro de su localización en el
Registration Server.
Respuestas, las respuestas a las solicitudes SIP, son códigos de tres dígitos, donde el primero de
ellos tiene que ver con la familia (clase de respuesta) y los otros dos con el mensaje concreto dentro
de esa clase.
• 1XX “información”: Indica que se ha recibido la solicitud y que se está procesando

• 2XX “Aceptación”: Indica que todo está correcto para comenzar el streaming
• 3XX “Redirección”: Indica que el usuario activó una redirección a otro UAS.
• 4XX “Error de solicitud”: Indica que el mensaje de solicitud no está bien. Por ejemplo un
número que no existe o una llamada que no se puede cursar, no se está autorizado, no se
soportan los codec ofrecidos, etc.
• 5XX “Fallo en el servidor”: Indica que aunque el mensaje de solicitud es válido, el servidor
tiene problemas para procesar la solicitud (servidor no disponible, saturado, etc).
• 6XX “Fallo General”; Indica que no se puede atender la solicitud por un “fallo general”.
Salvo las respuestas 1XX, todas las demás son respuestas finales, que dan por terminada la
transacción SIP.
A continuación citamos la lista completa de códigos
100 - Trying
180 - Ringing
181 - Call Being Forwarded
182 - Call Queued
183 - Session Progress
200 - OK
202 - Accepted
300 - Multiple Choices

301 - Moved Permanently
302 - Moved Temporarily
305 - Use Proxy
380 - Alternative Service
400 - Bad Request

401 - Unauthorized
402 - Payment Required
403 - Forbidden
404 - Not Found
405 - Method Not Allowed
406 - Not Acceptable
407 - Proxy Authentication Required
408 - Request Timeout
409 - Conflict
410 - Gone
411 - Length Required
413 - Request Entity Too Large
414 - Request URI Too Long
415 - Unsupported Media Type
416 - Unsupported URI Scheme
420 - Bad Extension
421 - Extension Required
423 - Interval Too Brief
480 - Temporarily Unavailable
481 - Call/Transaction Does Not Exist
482 - Loop Detected
483 - Too Many Hops
484 - Address Incomplete
485 - Ambiguous
486 - Busy Here
487 - Request Terminated
488 - Not Acceptable Here
491 - Request Pending
493 - Undecipherable
500 - Server Internal Error

501 - Not Implemented
502 - Bad Gateway
503 - Service Unavailable
504 - Server Time-Out
505 - Version Not Supported
513 - Message Too Large
600 - Busy Everywhere
603 - Declined
604 - Does Not Exist Anywhere
606 - Not Acceptable
La Cabecera del paquete SIP (Message Header)
La cabecera está formada por campos, algunos son usados en ambos tipos de mensajes y otros solo
en un tipo (Solicitudes o Respuestas).
Tenemos campos que pueden ser alterados en cada salto entre el origen y el destino (hop by hop) y
otros que permanecen intactos y son dirigidos al destinatario final (end to end).
En principios la recomendación RFC2543 incluia 37 campos de cabecera, no obstante en la

actualidad ya hay definidos más de 40!
Vamos a citar algunos:
• Call-ID: es un código que identifica cada llamada de forma única. Nos permite por ejemplo,
hacer corresponder una respuesta a una solicitud o cambiar dinámicamente los parámetros
de una llamada.
• Cseq: identifica cada solicitud, la respuesta a una solicitu lleva el mismo Cseq.
• From: aparece en todos los mensajes de solicitud y respuesta, identificando a quien originó
la llamada.
• To: aparece en todos los mensajes de solicitud y respuesta, identificando el destinatario de la
llamada.
• Via: Registra la ruta que siguió la solicitud.
• Content-Length: nos dice la longitud del cuerpo del mensaje SIP
• Content-Type: indica el contenido del cuerpo del mensaje SIP
• Subject: indica el asunto de la llamada
Figura 8 – Header SIP
El cuerpo del paquete SIP
Los paquetes SIP no están obligados a llevar una carga útil (payload) embebido. El payload puede
ser información dirigida a la aplicación de usuario o información de la sesión. El contenido del
paquete no es analizado por los dispositivos Proxy, sino que solamente lo interpretan los terminales.
Cuando SIP utiliza el cuerpo del paquete en el establecimiento de una sesión, este es ocupado por el
protocolo SDP (Session Description Procol). Es decir un paquete SDP va embebido dentro del
cuerpo del paquete SIP en algunas ocasiones.
Figura 9 – Payload SIP

SDP tiene la capacidad de describir las caracteristicas de una sesión de media. Si bien SDP es muy
amplio, SIP solamente utiliza una parte de las caracteristicas de SDP.
SIP utiliza SDP en los inicios de sesión, es decir el terminal que origina una llamada, manda como
cuerpo del paquete SIP de inicio de sesión, un paquete SDP el cual describe todas las caracteristicas
de “media” del terminal en cuestión (dirección ip y puerto donde espera recibir el streaming, codecs
disponibles y su orden de prioridad, etc.), por otro lado la parte “llamada”, responde a dicho
invitación con una respuesta SIP (200 OK), cuyo paquete lleva embebido otro paquete SDP el cual
describe las caracteristicas del UAS (User Agent Server) y en base a esto ambos acuerdan los
parámetros para comenzar el streaming.
A continuación describimos algunos campos del paquete SDP
• v: versión del protocolo
• o: identifica al remitente y a la sesión en si, posee 6 sub.campos

▪ nombre del remitente
▪ identificador de sesión
▪ versión de la sesión
▪ tipo de red
▪ tipo de direccion (IPV4 – IPV6)
▪ direccion de la maquina del remitente
• m: posee cuatro sub-campos:

▪ Tipo de media (audio, video, aplicación, etc.)
▪ Puerto (numero de puerto utilizado en el destino)
▪ Protocolo de transporte utilizado (RTP)
▪ Formatos multimedia aceptados por orden de preferencia
• k: lleva una clave de cifrado, en caso de trabajar con RTP encriptado
• a: se utiliza para describir atributos adicionales
Figura 10 – Payload SIP
El protocolo RTP
Figura 11 – RTP en acción
Como ya hemos escuchado, de los dos protocolos de la capa de transporte (UDP y TCP), el
adecuado para el envío de información en tiempo real es el UDP, pero de todas formas este
protocolo no nos garantiza que lleguen todos los paquetes ni que los que si lo hagan, lleguen en el
mismo orden en que fueron enviados. Por lo que frente a esta realidad se sabe que UDP debe ser
complementado para mejorar una comunicación en tiempo real, precisamente de esto se ocupa el
protocolo conocido como RTP – Real Time Protocol.
RTP se encarga de añadirle a los paquetes UDP un número de secuencia, una marca de tiempo y una
identificación del payload que transporta cada paquete UDP. Estos datos son aprovechados por el
protocolos RTCP (RTP Control Protocol) quien informa a los participantes de la sesión sobre la
calidad del streaming (perdidas de paquetes, desorden, jitter).
Gracias al campo “número de secuancia” de la cabecera RTP, se puede detectar la pérdida o

desorden de los paquetes recibidos, mientras que con el capo “tiempo” puedo detectar el delay y la
variación del dalay (jitter).
Generalmente el protocolos RTP y RTCP se utilizan conjuntamente, es decir que cuando se asigna
un puerto para una sesisón RTP, también se asigna uno para la sesión RTCP.
Figura 12 – RTP Payload
Identificación de los participantes de una sesión
Para identificar los participantes en una sesión RTP, se utiliza un campo de 32 bits. Dicho número
se conoce como SSRC (Synchronization Source).
Hacemos zoom ...
Figura 13 – RTP Header
En la figura resaltamos en rojo, los campos de la cabecera RTP repasados hasta el momento.
Es decir:
• Payload Type
• Sequence numbre
• Timestamp
• SSRC
Entre los más importantes.
Calculo de los parámetros de calidad
Los paquetes RTCP como dijimos se nutren de la información que aportan las cabeceras RTP a la
sesión, para determinar informes sobre la calidad del streaming. Estos resultados son
intercambiados entre las partes de la comunicación y las aplicaciones pueden llegar a tomar
decisiones como modificar el codec para ahorrar ancho de banda y así alivianar el flujo de paquetes
en el streaming.
Señalización SIP por el puerto UDP 5060, Flujo de media en algún puerto entre el UDP 10000 y
20000 (En Asterisk).
Juntando todas las partes (SIP + SDP + RTP)
Vamos a repasar como sería el establecimiento de una sesisón SIP
Figura 14 – SIP + RTP
• INVITE
Figura 15 – SIP Invite

• 100 TRYING
Figura 16 – SIP Trying
• 200 OK
Figura 17 – SIP 200 OK
• ACK
Figura 18 – SIP ACK
• RTP --->
Figura 19 – Flujo RTP de ida
• RTP <-----
Figura 20 – Flujo RTP de vuelta
• BYE
Figura 21 – SIP BYE
• ACK
Figura 22 – SIP ACK
El Protocolo IAX
IAX (Inter-Asterisk eXchange protocol) es uno de los protocolos utilizado por Asterisk y
patrocinado por Digium. Es utilizado para manejar conexiones VoIP entre servidores Asterisk, y
entre servidores y clientes que también utilizan protocolo IAX.
El protocolo IAX ahora se refiere generalmente al IAX2, la segunda versión del protocolo IAX. El
protocolo original ha quedado obsoleto en favor de IAX2.
IAX2 es robusto, lleno de novedades y muy simple en comparación con otros protocolos. Permite
manejar una gran cantidad de códecs y un gran número de streams, lo que significa que puede ser
utilizado para transportar virtualmente cualquier tipo de dato. Esta capacidad lo hace muy útil para
realizar videoconferencias o realizar presentaciones remotas.
IAX2 utiliza un único puerto UDP, el 4569 por default, para comunicaciones entre puntos finales
(terminales VoIP) para señalización y datos. El tráfico de voz es transmitido in-band, lo que hace a
IAX2 un protocolo casi transparente a los firewalls y realmente eficaz para trabajar dentro de redes
internas. En esto se diferencia de SIP, que utiliza una cadena RTP out-of-band para entregar la
información.
IAX2 soporta Trunking (red), donde un simple enlace permite enviar datos y señalización por
múltiples canales. Cuando se realiza Trunking, los datos de múltiples llamadas son manejados en un
único conjunto de paquetes, lo que significa que un datagrama IP puede entregar información para
más llamadas sin crear latencia adicional. Esto es una gran ventaja para los usuarios de VoIP, donde
las cabeceras IP son un gran porcentaje del ancho de banda utilizado.
El protocolo IAX2 fue creado por Mark Spencer para la señalización de VoIP en Asterisk. El
protocolo crea sesiones internas y dichas sesiones pueden utilizar cualquier codec que pueda
transmitir voz o video. El IAX esencialmente provee control y transmisión de flujos de datos
multimedia sobre redes IP. IAX es extremadamente flexible y puede ser utilizado con cualquier tipo
de dato incluido vídeo.
El principal objetivo de IAX ha sido minimizar el ancho de banda utilizado en la transmisión de voz
y vídeo a través de la red IP, con particular atención al control y a las llamadas de voz y proveyendo
un soporte nativo para ser transparente a NAT. La estructura básica de IAX se fundamenta en la
multiplexación de la señalización y del flujo de datos sobre un simple puerto UDP entre dos
sistemas. IAX es un protocolo binario y está diseñado y organizado de manera que reduce la carga
en flujos de datos de voz.
Características:
- Siempre usa UDP como protocolo de la capa de trasporte.
- Por default usa el puerto UDP 4569.
- El audio de la llamada y la señalización son transmitidos por paquetes IAX2.
- El protocolo nos ofrece una opcion (trunk) la cual permite que en un mismo datagrama se pueden
enviar varias sesiónes al mismo tiempo, lo que significa una reutilizacion de datagramas y por
consiguiente un ahorro de ancho de banda.
IAX2 trabajando en el modo por default: Cada fragmento de voz de cada sesión va dentro de un
frame IAX encargado de transportarlo hasta el destino.
Figura 23 – IAX normal
IAX2 trabajando en moto trunk: en ciertos casos podemos hacer que IAX encapsule en un
mismo frame varios fragmentos de voz de diferentes sesiones. Sobre todo cuando se trata de un
trunk entre dos Asterisk. De esta maneta podemos ahorrar ancho de banda.
Figura 24 – IAX modo trunking
A continuación veremos un paquete IAX2 de señalización
Figura 25 – Paquete IAX de señalizacion

Ahora veremos un paquete IAX que transporta “voz”
Figura 26 – Paquete IAX de voz
Ambos paquetes (señalizacion y voz) viajan encapsulados como UDP 4569.
Overhead en VoIP
Como ya vimos, para transportar la voz de un lugar a otro, en una red de paquetes, necesitamos la
ayuda de algunos protocolos; pero ya nos habremos dado cuenta de que estos protocolos transmiten
data adicional que ocupa ancho de banda extra a la voz propiamente dicha. Algunos de ellos son
Ethernet, IP, UDP, RTP.
En resumen esto hace que el ancho de banda real para transmitir voz sea mayor al del codec.
Por ejemplo, para transmitir voz usando G.711 en teoría deberíamos usar 64Kbps (peso del codec)
pero en realidad usamos 95.2Kbps de BW. En otros codecs más compresores la sobrecarga es
incluso más significativa (porcentualmente hablando).
Realicemps un pequeño análisis:
Bytes transmitidos cada 20ms = 38 + 20 + 12 + 8 + 160 = 238 bytes
Bits transmitidos cada 20ms = 238 bytes * 8 bits/byte = 1904 bits
Bits transmitidos cada segundo = 1904 bits/frame * 50 frames/seg = 95,200 bits/segundo =

95.2Kbps!
Vemos el overhead en la siguiente figura:
Figura 27 – Overhead 1
Comparativa de codecs
A continuación una tabla que muestra el overhead para algunos de los codecs más populares
soportados por Asterisk.
Figura 28 – Tabla comparativa CODEC-Overhead
Un fragmento de 20ms de voz podría visualizarse como esto:
Figura 29 – Otra vista del Overhead
Calidad de serivicio: Retos de la transmisión de la voz
Para los usuarios de las redes VoIP, las diferencias tecnológicas existentes frente a la red de
telefonía tradicional deben ser totalmente transparentes. Es decir, debemos conseguir que las redes
VoIP ofrezcan una calidad de servicio similar a la red telefonica tradicional.
Como sabemos, la tecnología IP no fue diseñada para soportar el intercambio de voz o cualquier
otro tipo de señal interactiva en tiempo real. IP fue diseñado para la transmisión de datos, donde
resulta extremadamente importante que no se pierda ni un solo bit, aunque es extremadamente
tolerante con el retardo. En cambio, la voz es muy sensible al retardo y a la variación del mismo,
aunque no importa que algún bit no llegue al destino.
Factores que afectan la QoS
- Retardo: tiempo necesario para que la señal de voz haga el camino de ida y vuelta entre los dos
extremos de la comunicación. No debe superar los 300 ms.
- Jitter: tan importante como el retardo que haya, es que ese retardo permanezca constante. Si
además del retardo que exista, éste varía, la comunicación se vuelve mucho más incomoda.
A la fluctuación del retardo se la conoce como jitter.
La forma de contrarestar el jitter es usando buffers que añadan retardo cuando la comunicación es
más rápida y que lo quiten cuando es más lenta. Si bien el retardo existe, al menos es constante.
Los motivos del jitter son dos:
- Entutamiento variable, los paquetes experimentan retardos distintos, según el camino que tomen.
- Ocupación variable, por más que los paquetes viajen por la misma ruta, los routers pueden tener
mayor o menor carga en el tiempo.
- Pérdida de paquetes: este factor está bastante contemplado en las comunicaciones de datos,
donde al perderse un paquete TCP puede pedir su retransmisión y éste tiempo no afecta a la carga
de una página web en un navegador por ejemplo. En el caso de la voz si se pierde un paquete es
preferible darlo por perdido que esperar la retransmisión del mismo. La falta esporádica de un
paquete no afecta en demasía el entendimiento de la comunicación.
- ECO: se produce cuando el emisor escucha parte de su propia voz junto con la del otro
interlocutor o en ausencia de ella.
Generalmente se presenta cuando hay un cambio de medio, VoIP a Telefonía convencional. Existen
canceladores de eco por soft y hard.
Dispositivos VoIP
Finalmente, antes de meternos de lleno en el mundo Asterisk, que es nuestro dispositivo VoIP
principal de nuestra red y la herramienta que vamos a estudiar en profundidad, vamos a citar a otros
dispositivos integrantes de esta nueva forma de red telefónica.
ATA
Este pequeño aparato transforma un teléfono tradicional en un interno SIP y le da la posibilidad de

utilizar su teléfono convencional para hacer llamadas por internet o integrar directamente su interno
análogo a su VoIP-PBX .
Gateways SIP - FXO | SIP - FXS
Es como un gran ATA, vienen con puertos FXO, FXS o FXO y FXS.
Gateways SIP - GSM
Es un dispositivo que hace de gateway entre la telefonía IP y la red GSM.
Placas PCI análogas – fxo-fxs
Se colocan en algún bus pci disponible de su PBX Asterisk, poseen puertos RJ11 que se pueden
comportar como interfaces FXS o FXO dependiendo de qué módulos se coloquen en cada ranura.
Los módulos rojos son FXO y los verdes FXS.
Placas PCI digital – E1 o T1.
Se colocan en algún bus pci disponible de su PBX Asterisk y nos permite conectar una trama digital
E1 o T1 a nuestra PBX.
Softphone
Son aplicaciones que corren en un sistema operativo y operan como un teléfono SIP
Teléfonos VoIP

1.03 Introduccion PIII

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1.03 Introduccion PIII

Uploaded by

Copyright:

Available Formats

Capítulo 1.

Qué pasa cuando hacemos una llamada telefónica utilizando VoIP?

- Mejor utilización de los recursos

Mitos de la telefonía IP:

- Solo funciona en Internet

Cuerdas vocales → Micrófono → Digitalizacion (codec) → Fragmentación en paquetes

CODECS: Codificación de la voz

Si bien ya hemos estudiado el proceso de digitalización y codificación de la voz, vamos a volver a

Vamos a repasar algunos codecs con los cuales vamos a trabajar:

También se trata de una recomendación ITU cuyas implementaciones ha sido históricamente

– Software libre/código libre, libre de patentes y regalías.

Hay muchos protocolos involucrados en la transmisión de voz sobre IP.

Figura 1 – Protocolos involucrados

Clasificacion los protocolos VoIP

Figura 2 – Clasificación de protocolos

El protocolo SIP (Session Initialization Protocol) es un protocolo de señalización creado para

Como dijimos, SIP es un protocolo de señalización, concebido para controlar el establecimiento,

Figura 3 – Protocolo SIP en acción

La arquitectura SIP se basa en un modelo peer-to-peer en el que el cliente realiza solicitudes

La arquitectura SIP considera la existencia de múltiples componentes:

– Los equipos terminales UA (User Agent), que disponen de dos módulos

Ambos módulos le dan la funcionalidad completa al terminal.

– Servidor de redireccionamiento: este tipo de servidor solamente se limita a responder a las

Figura 5 – Servicor de redireccionamiento

Generalmente los servicios de Proxy, Redirección y Registro se encuentran corriendo dentro de un

URI – Las direcciones SIP

El formato se basa en la estructura de direccionamiento empleada en Internet y conocida como URL

Formato de una URI SIP

– Una linea de inicio, indica si el mensaje es solicitud o respuesta.

Figura 7 – Paquete SIP

Solicitudes (Métodos), en la versión 2.0 de SIP se incluyen seis tipos de métodos:

• INVITE: un dispositivo lo envía para inciar una llamada

• 1XX “información”: Indica que se ha recibido la solicitud y que se está procesando

A continuación citamos la lista completa de códigos

300 - Multiple Choices

400 - Bad Request

500 - Server Internal Error

La Cabecera del paquete SIP (Message Header)

En principios la recomendación RFC2543 incluia 37 campos de cabecera, no obstante en la

Vamos a citar algunos:

Figura 8 – Header SIP

Figura 9 – Payload SIP

A continuación describimos algunos campos del paquete SDP

• v: versión del protocolo

• o: identifica al remitente y a la sesión en si, posee 6 sub.campos

• m: posee cuatro sub-campos:

Figura 10 – Payload SIP

Figura 11 – RTP en acción

Gracias al campo “número de secuancia” de la cabecera RTP, se puede detectar la pérdida o

Hacemos zoom ...

Figura 13 – RTP Header

Entre los más importantes.

Calculo de los parámetros de calidad

Figura 14 – SIP + RTP

Figura 15 – SIP Invite

Figura 16 – SIP Trying

Figura 17 – SIP 200 OK

Figura 18 – SIP ACK

Figura 19 – Flujo RTP de ida

Figura 20 – Flujo RTP de vuelta

Figura 21 – SIP BYE

Figura 22 – SIP ACK

Figura 24 – IAX modo trunking

Figura 25 – Paquete IAX de señalizacion