VoIP - Voz Sobre IP
VoIP - Voz Sobre IP
VoIP - Voz Sobre IP
Figura 5.2.: La señalización SIP y las conversaciones de voz (RTP) viajan por caminos
distintos.
El principal problema que afecta el funcionamiento de RTP son los NAT (Network
4
Address Translator ) . El efecto de un NAT en VoIP es que no se pueden recibir
conexiones iniciadas desde el exterior; en consecuencia, el que inicia la llamada detrás
de un NAT no puede escuchar a la otra parte. Si los dos comunicantes se encuentran
detrás de sus respectivos NAT, ningún ujo de audio originado llegará a su destino
nal. Para este problema ya existen soluciones implementadas en Asterisk (apartado
5.2.3).
Los elementos básicos de un sistema SIP son los agentes de usuario (UA, User Agent )
y los servidores. Estos últimos pueden ser de diferentes tipos: Proxy, de Registro y de
Redirección. La conguración más simple para establecer una sesión SIP utiliza sólo
4 Los NAT son traductores de direcciones IP, usados principalmente para permitir a máquinas conec-
tadas a LAN con direcciones IP privadas, acceder a servidores en Internet (que usan direcciones
IP públicas).
Protocolos de VoIP y ToIP 51
Existen dos tipos básicos de mensajes SIP: Peticiones y Respuestas. Ambos tipos
emplean un formato de mensaje genérico, que consiste en una línea inicial (Start Line )
seguida de uno o más campos de cabecera (Message Header ), una línea vacía que
indica el nal de las cabeceras, y por último el cuerpo del mensaje (Message Body ),
que es opcional.
La línea inicial contiene la versión del protocolo, y el método y direcciones involucradas
en la sesión, en el caso de las Peticiones, o el estado de la sesión, en el caso de las
Respuestas. La cabecera contiene información relacionada con la llamada en formato
de texto; por ejemplo, el origen y destino de la petición, el identicador de la llamada,
etc. El cuerpo del mensaje o carga útil lleva la información, comúnmente mensajes
SDP o ISUP (ISDN User Part ) en caso de interfuncionamiento con la RTPC.
Las Peticiones se emplean para iniciar alguna acción o para solicitar información. La
línea inicial de un mensaje de Petición (llamada también Request Line ) incluye el
nombre del método al que invoca, que puede ser uno de los siguientes:
INVITE: Utilizado para invitar un usuario a participar en una sesión o para
modicar parámetros.
ACK: Conrma el establecimiento de una sesión.
OPTION: Solicita información sobre las capacidades de un servidor.
BYE: Indica la nalización de una sesión.
CANCEL: Cancela una petición pendiente.
REGISTER: Registra un UA.
PRACK: Conrmación de respuesta provisional.
Las Peticiones no contienen por lo general un cuerpo de mensaje, porque no lo requie-
ren.
Las Respuestas se generan como retorno de una petición, devolviendo un código nu-
mérico de estado. La línea inicial de un mensaje de Respuesta (llamada también Status
Protocolos de VoIP y ToIP 53
Line )incluye el código de respuesta y una pequeña descripción de ese código. Hay seis
clases de códigos de respuesta, a saber:
1xx: Mensaje provisional. La petición fue recibida pero se desconoce aún el resul-
tado del procesamiento. El emisor se abstiene de enviar retransmisiones después
de recibir una respuesta de este tipo. Son ejemplos el código 180 (Ringing) y el
100 (Trying).
2xx: Éxito. Son respuestas nales positivas. La petición fue recibida y procesada
exitosamente. Por ejemplo, 200 (OK) signica que el extremo llamado aceptó
la invitación a la sesión.
3xx: Redirección: Son usados para redireccionar las llamadas. Dan información
acerca de la nueva localización de un usuario o sobre un Proxy alterno que puede
resolver satisfactoriamente alguna petición. El emisor del mensaje de petición
debe reenviar su petición a otro para que su petición sea atendida.
4xx: Fallo de método. Son respuestas nales negativas. Falla del lado del emisor,
mala sintaxis del mensaje, etc.
5xx: Fallos de servidor. Falla del lado del servidor. Aparentemente la petición es
válida pero el Proxy es incapaz de procesarla. El emisor debe reintentar después.
6xx: Fallos globales. La petición no puede ser atendida en ningún Proxy.
Una transacción SIP es una secuencia de mensajes entre dos elementos de red. Una
transacción corresponde a una petición y todas las respuestas a esa petición. Esto
quiere decir que una transacción incluirá cero o más respuestas provisionales y una
o más respuestas nales. En el caso de un mensaje INVITE, puede ser dividido por
un Proxy y por lo tanto tendrá múltiples respuestas nales. Las entidades SIP que
almacenan el estado de las transacciones se denominan Stateful y llevan un registro
de cada transacción.
Un diálogo SIP es una conversación par a par (peer-to-peer ) entre dos UA. Los diálogos
son identicados usando los campos Call-ID, From y To. Los mensajes que tienen estos
campos iguales pertenecen al mismo diálogo. El campo CSEQ es utilizado para ordenar
los mensajes en un diálogo. De hecho, CSEQ representa el número de transacción. De
forma simple se puede decir que un diálogo es una secuencia de transacción.
407, con lo cual tendrá que reenviar el mensaje de Registro hasta que tenga
éxito.
Invitación a una sesión (Figura 5.4): Una invitación inicia con el mensaje INVI-
TE dirigido comúnmente al Proxy. Este responde con 100 (Trying) para detener
las retransmisiones y reenvía las peticiones hacia el usuario llamado. Todas las
respuestas provisionales generadas por el usuario llamado son entregadas al usua-
rio origen. Por ejemplo, 180 (Ringing) que es un mensaje que se envía cuando el
usuario es contactado y comienza a timbrar. La respuesta 200 (OK) se genera
en cuanto el usuario llamado descuelga el auricular.
Terminación de sesión (Figura 5.5): Una sesión es nalizada cuando uno de
los usuarios envía el mensaje BYE al otro extremo. El otro usuario conrma
el nal de la conversación enviando por respuesta un mensaje 200 (OK). La
transacción que naliza la sesión se realiza de un extremo a otro sin pasar por
el Proxy, a menos que en el mismo se haya establecido un proceso de Registro
de ruta. Existen situaciones en las que el Proxy requiere permanecer en la ruta
de todos los mensajes con nes de control del tráco o, por ejemplo, cuando
existe un NAT. El Proxy logra esto insertando el campo RECORD ROUTE en
las cabeceras de los mensajes SIP.
con otros protocolos como SIP, Megaco o HTTP. El transporte de información acerca
de los ujos audiovisuales permite a los destinatarios participar en la sesión si ellos
soportan dichos ujos. Además, SDP permite la negociación de los parámetros de ujo
tales como la tasa de muestreo de la señal, el tamaño de los paquetes, etc.
La información que SDP incluye en sus paquetes de forma general es la siguiente:
La versión del protocolo.
El nombre de la sesión y su propósito.
El tiempo que la sesión está activa.
Los medios relacionados con la sesión (video, audio, formatos para video y audio,
etc.)
Las direcciones IP y los puertos pertinentes para el establecimiento de la sesión.
Los atributos especícos de la sesión o de los medios dentro de ella.
Son los protocolos usados para transportar ujos de audio/video en Telefonía IP. RTP
es utilizado para transportar ujos en tiempo real (real-time streaming ) y RTCP para
monitorear la calidad del servicio, así como para transportar información acerca de los
participantes en la sesión. Sus funciones generales son:
Identicación del tipo de carga útil transportada (códecs de audio/video).
Vericación de la entrega de los paquetes en orden (usando marcas de tiempo)
y, si resulta necesario, reordenamiento de los bloques fuera de orden.
Transporte de información de sincronización para la codicación y decodicación.
Monitoreo de la entrega de la información.
RTP utiliza UDP para el transporte de la información y aprovecha la suma de veri-
cación (checksum) del mismo para vericar la integridad de los datos. RTCP también
utiliza UDP para enviar paquetes de control hacia todos los participantes de una sesión.
5.2.2. H.323
Forma parte del grupo de recomendaciones H.300 de la UIT-T que dene el funciona-
miento de sistemas y equipos terminales para servicios audiovisuales. Particularmente,
H.323 es una recomendación que agrupa diferentes estándares para especicar un sis-
tema de comunicaciones multimedia a través de redes de paquetes IP. Su primera
versión fue denida en el año 1996, tiempo en el cual no había disponible ningún es-
tándar que permitiera establecer mecanismos de interoperabilidad entre fabricantes y
desarrolladores de sistemas de VoIP; por este motivo se convirtió en el protocolo más
utilizado y de mayor aceptación en el mercado. Actualmente sigue siendo utilizado en
gran medida por los grandes operadores de VoIP, y a la par del protocolo SIP es uno
Protocolos de VoIP y ToIP 57
de los estándares más utilizados por los desarrolladores de soluciones IP. La versión
actual de la recomendación es la H.323v7, que fue publicada en el 2009.
Los protocolos más relevantes involucrados en H.323 son:
H.225: Es el encargado de denir los procesos de señalización de las llamadas, así
como de la gestión del registro y las características de los usuarios del sistema.
H.245. Su labor es controlar las llamadas, deniendo los parámetros para el
establecimiento, mantenimiento y cierre de los canales lógicos utilizados.
H.450.x: Establece los servicios suplementarios de H.323, como desvío y llamada
en espera.
H.235: Dene los mecanismos de seguridad y autenticación para las comunica-
ciones multimedia.
Es importante destacar que los protocolos anteriores se encargan de la señalización de
las comunicaciones; una vez establecido el canal H.323, se utiliza el protocolo RTP
para el transporte de los paquetes audiovisuales involucrados en la llamada.
Componentes y topología: Un sistema de VoIP basado en H.323 consta de 4 ele-
mentos fundamentales: termínales, pasarelas (gateways ), MCU (Unidades de Control
Multipunto) y controladores de acceso (gatekeepers ). Estos elementos se agrupan en
zonas, constituidas por diversos nodos H.323 gestionados por un solo controlador de
acceso.
Terminales: Son componentes en los que terminan las comunicaciones de voz y
opcionalmente video y datos. Es obligatorio que los terminales soporten comu-
nicaciones con el códec G.711 y los protocolos H.245, H.225 y RAS (Registro,
Admisión y Estado). Otros protocolos y códecs son opcionales según los tipos
de servicios que se estén prestando.
Controladores de acceso: Son los nodos centrales de un sistema H.323. Se
encargan de controlar las comunicaciones y la conexión entre los terminales. Su
presencia no es necesaria para la realización de comunicaciones entre terminales
de un mismo segmento, aunque sí es recomendable. Tienen las siguientes tareas
fundamentales:
• Conversión de direcciones de terminales H.323 a direcciones IP o E.164,
para que sea posible la comunicación con terminales de otros segmentos o
de una RTPC.
• Administración del ancho de banda, asignando un ancho de banda a cada
conferencia entre terminales y estableciendo comunicaciones hasta que se
alcanza el ancho de banda máximo permitido, momento en el cual empieza
a rechazar las solicitudes desde los terminales.
• Control de admisión, a través del protocolo RAS, aceptando o negando
solicitudes dependiendo del terminal o pasarela que las esté realizando.
En caso de que una conferencia incluya a más de dos terminales, el controlador
de acceso redirecciona la señalización al MCU que presta soporte a la multicon-
ferencia.
58 VOZ SOBRE IP (VOIP) Y TELEFONÍA SOBRE IP (TOIP)
Suelen tener más opciones y ventajas que un teléfono convencional; algunos pueden
tener múltiples líneas, incluir cámara de vídeo para realizar videoconferencias, y dan la
posibilidad de congurar la calidad del servicio (QoS) o una LAN virtual (VLAN). La
conguración se realiza mediante un sistema de administración que puede ser accedido
vía Web en una dirección IP asignada para tal n.
Teléfonos IP: Un teléfono IP suele ser un equipo con forma de teléfono, aunque con
la particularidad de que utiliza una conexión de red de datos en lugar de una
conexión de red telefónica.