VISIÓN INVESTIGADORA

Visión Electrónica, 2012-06-01 Volumen:6, Año:1 pág:14-27

---

TRANSPORTE DE VOZ EN ENTORNOS IPV4 E IPV6

VOICE TRANSPORT IPV4 AND IPV6 ENVIRONMENTS

Fausto Gamboa

Ingeniero de Sistemas; Ingeniero de Calidad de Software de la Secretaría Distrital de Salud. Correo: fagamboaq@correo.udistrital.edu.co; fagamboaq@correo.udistrital.edu.co

Danilo A. López S.

M.Sc. Ingeniero Electrónico, Universidad Distrital Francisco José de Caldas. Correo: dalopezs@udistrital.edu.co

Octavio J. Salcedo P.

Ph.d. en Ingeniería Informatica; M.Sc. en Teleinformática; M.Sc. en Economía; Ingeniero de Sistemas, Universidad Distrital Francisco José de Caldas. Correo: ojsalcedop@udistrital.edu.co

RESUMEN

En este artículo se expone el estado actual de las redes de voz y su funcionamiento sobre redes IP versión 6, las arquitecturas en las que se puede implementar y los protocolos que las soportan. Se indican sus ventajas respecto de la versión 4 del protocolo, gracias a las características que mejoran la calidad del servicio. Se evalúa el desempeño, teniendo en cuenta el retardo, jitter y la pérdida de paquetes.

Palabras clave

VoIP, IPv6, QoS, SIP, H.323.

Abstract

This article outlines the current state of voice networks and their operation over IP version 6, the architectures that can be implemented and the different protocols used. Indicating its advantages over protocol version 4, thanks to features that improve the quality of service. Performance is evaluated, taking into account the delay, jitter and packet loss.

Key Words

VoIP, IPv6, QoS, SIP, H.323.

---

Introducción

Los esquemas tradicionales de transmisión de voz han sido replanteados, dada la necesidad de proveedores y usuarios de servicios de telecomunicaciones de migrar todos ellos hacia una red donde estos converjan. La integración de servicios se ha dado hacia Internet, ya que en esta red puede coexistir la transmisión de cualquier tipo de información, ya sea video, audio o datos (Figura 1). Por esta razón, para transmitir voz es necesario estudiar el protocolo IP, base de la transmisión de datos en Internet.

Figura 1. Tipos de transmisiones VoIP [3].

En la actualidad se está dando la migración de la versión 4 de IP a la versión 6, ya que el creciente número de dispositivos conectados al Internet, en conjunto con la deficiente manera en que las direcciones IP son asignadas, han provocado una pronta escasez en el espacio de direcciones disponibles [1], lo que se acrecienta por la tendencia a llevar el Internet a diferentes electrodomésticos. Además de esto, se tienen mejoras en seguridad y mecanismos para disminuir la complejidad en la administración de las redes. Por naturaleza, las señales analógicas de voz se perciben como una secuencia de vibraciones de sonido. Debido a que las vibraciones no pueden ser representadas directamente en formato digital, las comunicaciones modernas deben reproducir las señales de voz de la toma de muestras de sonido humano. Después, estas muestras son codificadas en dígitos para su transmisión como datos.

Las redes telefónicas tradicionales asignan circuitos dedicados para comunicaciones de voz. Esto ocurre cada vez que un cliente descuelga el teléfono y marca a un receptor. Debido a que los circuitos están dedicados al usuario, la calidad de las señales de voz se puede garantizar, pero esto implica que se desperdicie ancho de banda cada vez que hay períodos de silencio durante la comunicación.

Este documento muestra los requerimientos para implementar el servicio de voz sobre una red IPv6, y señala los elementos que afectan la calidad de servicio (QoS), las especificaciones para realizar una migración de voz sobre IPv4 a IPv6 y las oportunidades actuales y futuras de implementar esta tecnología.

Transmisión de voz sobre IP

Para transportar voz sobre IP, la señal analógica de la voz se muestrea, se cuantifica y se codifica, para convertirla en paquetes de datos que forman un datagrama IP; en el nodo de destino se realiza el procedimiento inverso. Para la transmisión de voz, uno de los primeros protocolos usados es el estándar de la ITU H-323, que cubre la mayor parte de los mecanismos necesarios para la integración de la voz (Figura 2). El VoIP/H323 [2] tiene como objetivo primordial facilitar y asegurar la interoperabilidad entre equipos de diversos fabricantes, establece los aspectos como supresión de silencios, compresión, direccionamiento y establecimiento de elementos que permiten la interconectividad con la red telefónica conmutada (RTC) tradicional.

Figura 2. Pila de protocolos H.323 [3].

La pila de protocolos de H.323 es la siguiente: el Protocolo de Transporte en Tiempo Real (RTP) y el Protocolo de Control en Tiempo Real (RTCP) son los encargados del transporte multimedia en tiempo real y de su control.

El Protocolo de Reservación (RSVP) se encarga de dividir los paquetes de datos grandes y da prioridad a los paquetes de voz cuando hay una congestión en un nodo. Los códecs (G.711, G.723.1, etc.) son los estándares para la compresión de la voz. El H.225 Call Control se usa para conectar dos participantes, después del establecimiento; H.225 RAS Control (Registro, Admisión y Estado) es un protocolo de comunicaciones que permite a una estación H323 localizar otra estación H323 a través de una entidad llamada Gatekeeper.

IP versión 6

El encabezado de la versión 6 es una mejora de la versión 4; consta de 40 octetos distribuidos en los siguientes campos (Figura 3) [4]: Para el soporte de servicios de voz, los campos más importantes de la cabecera, que aseguran la calidad del servicio, son: Clase de tráfico y Etiqueta de flujo.

Figura 3. Cabecera IP versión 6 [5].

El campo Clase de Tráfico está disponible para usarse por nodos origen y/o enrutadores de reenvío para identificar y distinguir entre las diferentes clases o prioridades de paquetes IPv6. Este funciona como una clase de ”servicio diferenciado“. Los siguientes requisitos generales se aplican al campo Clase de Tráfico:

• La interface de servicio para el servicio IPv6 dentro de un nodo debe proporcionar un medio para que un protocolo de capa superior proporcione el valor de los bits Clase de Tráfico en los paquetes originados para esa estructura de capa. El valor por defecto debe ser cero para todos los 8 bits.
• A los nodos que soportan un uso (experimental o estándar eventual) específico de algunos o todos los bits Clase de Tráfico se les permite cambiar el valor de esos bits en los paquetes que ellos originan, reenvían o reciben, como sea requerido para ese uso específico. Los nodos deben ignorar y dejar sin alterar cualquiera de los bits del campo Clase de Tráfico para los cuales no dan soporte a un uso específico.
• Un protocolo de capa superior no debe asumir que el valor de los bits Clase de Tráfico en un paquete recibido es el mimo que el enviado por el origen del paquete. [4]

El campo Etiqueta de Flujo puede ser usado por un origen para etiquetar secuencias de paquetes para los cuales solicita un manejo especial por los enrutadores IPv6, como la calidad de servicio no estándar o el servicio en ”tiempo real“, muy útil para asegurar la calidad de servicio de la transmisión de voz.

Un flujo, en transmisión de voz, es una secuencia de paquetes enviada desde un origen determinado hacia un destino (unicast o multicast) para el cual el origen desea un tratamiento especial por los enrutadores intermedios. Deben enviarse todos los paquetes que pertenecen a la misma conversación con la misma dirección de origen, dirección de destino y etiqueta de flujo. Si alguno de esos paquetes incluye una cabecera Opciones de Salto a Salto, entonces todos ellos deben originarse con los mismos contenidos de cabecera Opciones de Salto a Salto. En síntesis, todos los paquetes de la conversación deben llevar los mismos valores que aseguran la calidad del servicio, para así ser tratados de la misma forma por los nodos intermedios.

Migración de voz a IP versión 6

Para realizar la migración de las redes convencionales de voz a las redes IPv6, se debe describir la tecnología de señalización de voz sobre IP, donde la más óptima es la que usa el Protocolo de Inicio de Sesiones (SIP) definido en el RFC 3261 de la IETF.

Este protocolo SIP, cuya pila de componentes se puede observar en la Figura 4, se concentra en el establecimiento, modificación y terminación de las sesiones, y se complementa, entre otros, con el Protocolo de Descripción de Sesión (SDP), que describe el contenido multimedia de la sesión, por ejemplo qué direcciones IP, puertos y códecs se usarán durante la comunicación. También se relaciona directamente con el Real-time Transport Protocol (RTP), que es el verdadero portador del contenido de voz y vídeo que intercambian los participantes en una sesión establecida por SIP [7].

Figura 4. Pila de protocolo SIP [3].

El SIP fue diseñado de acuerdo con el modelo de Internet por el grupo de trabajo Multiparty Multimedia Session Control (MMUSIC) del Internet Engineering Task Force (IETF), con el fin de estandarizar sesiones interactivas de usuario, con elementos multimedia; es un protocolo de señalización extremo a extremo que implica que toda la lógica se almacena en los dispositivos finales (salvo el enrutado de los mensajes SIP). El estado de la conexión también se almacena en los dispositivos finales [16].

El precio a pagar por esta capacidad de distribución y su gran escalabilidad es una sobrecarga en la cabecera de los mensajes, producto de tener que enviar toda la información entre los dispositivos finales.

Para que la transición hacia IPv6, mediante el protocolo SIP, sea una solución completa tiene que soportarse tanto en la capa de señalización como en la capa de sesión. Aunque SIP puede manejar redes heterogéneas IPv6/IPv4 en la capa de señalización, siempre que los servidores proxy y el Sistema de Nombres de Dominio (DNS) sean configurados correctamente, los agentes de usuario con diferentes redes y la dirección que usen diferentes redes y espacios de direcciones deben implementar las extensiones para el intercambio de voz entre ellos [8].

Figura 5. Fuentes de retardo de VoIP [9].

Calidad de servicio

El principal problema que presentan las diferentes aplicaciones que funcionan sobre IP (entre ellas VoIP) es el relacionado con la garantía de QoS, ya que es necesario reservar anchos de banda y valores muy pequeños de fluctuación (jitter), retardo (delay), latencia, supresión de eco, etc. Particularmente, las diferentes fuentes de retardo en transmisión de VoIP se pueden observar en la figura 5, por eso, se presentan diversos problemas para garantizar la calidad del servicio.

Los problemas de la calidad del servicio en VoIP vienen derivados de dos factores principalmente: 1. Internet es un sistema basado en conmutación de paquetes y, por tanto, la información no viaja siempre por el mismo camino. Esto produce efectos como la pérdida de paquetes; 2. las comunicaciones VoIP son en tiempo real, lo que hace que efectos como el eco, la pérdida de paquetes y latencia sean muy molestos y perjudiciales y deban ser evitados o controlados.

Cuando las tramas se transmiten a través de una red IP, la cantidad de retardo experimentado por cada una puede diferir. Esto lo causa la cantidad de retraso de encolamiento y tiempo de procesamiento, que puede variar dependiendo del tráfico cargado en la red. Sin embargo, como el gateway fuente genera tramas de voz a intervalos regulares (es decir, cada 20 ms), el Gateway destino típicamente no recibirá tramas de voz en intervalos regulares, lo que produce el jitter (Figura 6).

Figura 6. Variación del retardo Jitter [3].

Para flujos de voz, esta variable entre punto inicial y final de la comunicación debiera ser inferior a 100 ms. Si el valor es menor a 100 ms. el jitter puede ser compensado de manera apropiada; en caso contrario, debe ser minimizado [15].

La latencia se define técnicamente en VoIP como el tiempo que tarda un paquete en llegar desde la fuente al destino. Las comunicaciones en tiempo real (como VoIP) son sensibles a este efecto. Es un problema frecuente en enlaces lentos o congestionados. La latencia o retardo entre punto inicial y final de la comunicación debiera ser inferior a 150 milisegundos. El oído humano es capaz de detectar latencias de unos 250 ms, y de 200 ms en el caso de personas bastante sensibles. Si se supera ese umbral, la comunicación se vuelve molesta [17].

El eco es una reflexión retardada de la señal acústica original, y produce un retorno de la voz en los altavoces. Este problema se agudiza cuanto mayor sea el retardo y mayor sea su intensidad. La medida tolerable es de máximo 65 ms y una atenuación de 25 a 30 dB [9].

La pérdida de datos es el porcentaje de información descartado en la red y puede producirse por una alta tasa de error en los medios. En el caso del tráfico de datos, los paquetes perdidos pueden retransmitirse, pero en telefonía IP, que es en tiempo real, ello causa distorsión vocal, por lo que esta variable no debe ser superior a 1%. Todos estos factores se pueden llegar a resolver si se cuenta con arquitecturas robustas como MPLS, GMPLS y ASON.

Desempeño IPv6 frente a IPv4

En redes IPv4, a fin de garantizar cierta ”reserva“, se hace uso del ítem ”servicio diferenciado“ dentro del encabezado. En IPv6, los campos Clase de Tráfico (que especifican parámetros de prioridad, retardo, rendimiento, fiabilidad) y Etiqueta de Flujo (que especifica la forma de etiquetar los paquetes de voz como pertenecientes a un mismo flujo), permiten al origen solicitar un manejo especial por parte de los nodos intermedios [10]. Si se configuran adecuadamente estos dos campos, se logra reducir el retardo de la trasmisión y se genera una mayor calidad de audio, lo que repercute en el mejoramiento del servicio.

IPv6 proporciona mayor facilidad de clasificar los paquetes con identificadores de tráfico. Adicionalmente, el campo Etiqueta de Flujo tiene la ventaja de estar localizado antes de los campos de dirección, lo que ayuda a reducir los retardos en la verificación del paquete [11]. En la Tabla 1 se muestran los beneficios que tiene IPv6 sobre IPv4:

Tabla 1. Beneficios VoIPv6 respecto de VoIPv4.

Arquitectura de integración

Para lograr integración entre los servicios de voz proporcionados por las redes análogas, la Red Telefónica Pública Básica Conmutada (RTPBC), las redes bajo IPv4 y las redes que operan bajo IPv6, es necesario definir una arquitectura donde se puedan tener diferentes esquemas de direccionamiento y afrontar el cambio de versión del protocolo IP. Para solucionar esto se deben implementar puertas de enlace distribuidas, una pila doble que permita las dos versiones del protocolo y entidades de transición, además de un árbol con los pasos para la estrategia de transición. Una propuesta de arquitectura se presenta en la Figura 7.

En la Figura 7 se observa que hasta el Gateway la transferencia multimedia y la señalización se realizan a través de MTP, ISUP y DSS1, protocolos y elementos propios de la RTPBC. Cuando se hace la transición hacia redes IP, se hace a nivel de capas inferiores, en cualquiera de las versiones: 4 ó 6. En las capas superiores se utiliza SIP. En este punto hacen su aparición los nodos Media Gateway Control (MGC) y Media Gateway (MG): el primero se encarga de la adaptación de señalización, interfaz a la capa superior, gestión de políticas etc., y el segundo realiza la adaptación multimedia en los límites de la RTPBC y la red IP. De aquí en adelante, se realiza el enrutamiento y la interoperabilidad de IP entre versiones 4 y 6 de manera normal; en el caso específico de la Figura 7, se emplea NAT como traductor.

Figura 7. Arquitectura propuesta VoIPv6 [12].

Medición del retardo

Para cuantificar la mejora de IPv6 respecto a IPv4, se realizaron llamadas utilizando el servicio Asteriskv6, que es un programa de software libre que implementa transmisión de voz sobre IPv6 y al cual se le puede configurar el protocolo SIP para que haga la transmisión sobre este. Se usó un servidor con Asteriskv6 y clientes Ubuntu con linphone y Windows con X-lite como software de voz. Se tomaron como muestra diez llamadas y se realizaron diferentes capturas mediante Wireshark, donde se tomaron los paquetes recibidos y los tiempos de duración; los datos obtenidos se observan en la Tabla 2, [13].

Tabla 2. Tiempos de llamada en VoIP, v4 y v6 [13].

Estos tiempos se pueden graficar en forma de barras para observar la mejora sustancial en el tiempo del retardo, que se da cuando se emplea IPv6. Para calcular el retardo se utiliza la ecuación:

        (1)

Partiendo de los valores de la Tabla 2 y la Figura 8, se obtienen los retardos para los tiempos de la muestra (Tabla 3).

Figura 8. Tiempos de llamada vs. Paquetes IPv4 e IPv6.

Los valores de la Tabla 3 se grafican en la Figura 9. De allí se concluye que existe una disminución en el retardo de entre 35% y 50%para las redes IPv6.

Tabla 3. Retardo en VoIP, v4 y v6.

Figura 9. Retardo IPv4 e IPv6.

A. JITTER

Para comparar la variación del retardo se captura tráfico con Wireshark en la máquina receptora, de allí se establece el jitter promedio (Tabla 4)

De esta forma se puede determinar que el Jitter disminuye en la versión 6. Aplicando una regla de 3, se encuentra en porcentaje la mejora para esta variable.

Tabla 4. Jitter promedio VoIP, v4 y v6.

        (2)

Esto significa que se ha reducido el jitter en 33,5475% al usar la versión 6 de IP.

B. Pruebas con generación de tráfico:

Adicional a esto, se realizan pruebas para medir el desempeño con un generador de tráfico (MGEN o multigenerador). Se usaron dos clientes de VoIP: el número 1 en Linux y el 2 en Windows usando Linphone. La topología de la red se puede observar en la Figura 10. La captura de tráfico se realizó mediante Wireshark, corriendo sobre Linux, mientras que el generador de tráfico MGEN se ejecutó sobre Windows XP.

Figura 10. Topología de red para pruebas con generación de tráfico.

Se aumentó el tráfico de los MGEN desde 0 a 200 Mbps, ya que de aquí en adelante la tasa de pérdida de paquetes genera calidad de voz pobre, al calcular valores Mean Opinion Score (MOS), [14]

En las pruebas realizadas no se hizo uso de los campos IPv6 para mejorar la QoS Clase de tráfico y Etiqueta de Flujo; por tanto, los valores observados aquí para esta versión del protocolo se pueden mejorar y así se puede obtener mayor calidad de las llamadas.

La comparación del jitter máximo entre losdos sistemas operativos se muestra en la Figura 11. En esta imagen se puede observar que en Windows XP el jitter máximo permanece casi constante en 20 ms, solo hay un incremento en la versión 6 de IP, cuando se tiene tráfico de fondo generado en 200 Mbps, que alcanza 28 ms. De otro lado, en Linux el jitter máximo va ascendiendo de acuerdo con el incremento del tráfico de fondo generado. Los valores van desde 10 ms sin tráfico de fondo hasta 20 ms con 200 Mbps en IPv6 y 13 Mbps en IPv4.

Figura 11. Jitter máximo.

El jitter promedio (Figura 12) muestra un comportamiento diferente en los dos sistemas operativos; mientras en Windows XP este valor decrece a medida que incrementa el tráfico generado, en Linux el valor va aumentando. En Windows XP, el jitter promedio empieza en 19 ms y decrece lentamente hasta los 150 Mbps de tráfico de fondo generado. Al llegar a los 200 Mbps, decae con más fuerza, hasta llegar a los 19,67 ms en versión 4 y 19.73 ms en versión 6, lo que muestra una variabilidad mínima, de menos de 0,35 ms en el rango de tráfico generado desde 0 a 200 Mbps. De otro lado, en Linux se tiene una variación un poco mayor, ya que este empieza en 8 ms, cuando no se tiene tráfico de fondo, y llega a un punto máximo en 150 Mbps de tráfico con jitter de 11 ms en versión 6 y 10 ms en versión 4, para decaer un poco en 200 Mbps de tráfico, con 11 ms de jitter en versión 6 y 9 ms en versión 4.

Figura 12. Jitter promedio.

Cuando se mide el porcentaje de pérdida de paquetes, se genera la Figura 13, donde se confronta el porcentaje de paquetes perdidos contra el tráfico de fondo generado por el MGEN. En la gráfica se observa que la pérdida de paquetes en los dos sistemas operativos, en la versión 4 del protocolo se inicia cuando se tiene tráfico de fondo generado de 150 Mbps, y antes de esto no se presenta, y llega en Windows XP a un máximo de 17% con 200 Mbps en las dos versiones del protocolo. En este sistema operativo la diferencia entre protocolos se presenta principalmente cuando hay tráfico de 100 Mbps, mientras en la versión 4 no hay pérdida, en versión 6 se pierde 4%. Con tráfico de fondo de 150 Mbps, la diferencia entre los protocolos es mínima.

Figura 13. Pérdida de paquetes.

En Linux, se tiene un máximo de pérdida con IPv6 y 200 Mbps de tráfico, que llega al 24%, mientras con este tráfico en versión 4 se llega al 18%. Con tráfico de fondo de 150 Mbps, se tienen pérdidas de 11% y 13% en versión 4 y 6, respectivamente, y con 100 Mbps el porcentaje de pérdidas es de 0% y 3% en versión 4 y 6, respectivamente.

Para analizar el Mean Opinion Score (MOS), método para expresar numéricamente la calidad de comunicaciones de tipo multimedia como voz y video, se tiene una escala de 1 a 5, donde 1 representa la imposibilidad de comunicación y 5 una comunicación perfecta, que es como tener una comunicación frente a frente. Los valores de estas mediciones se observan en la Figura 14.

En Windows XP se tienen valores por encima de 4, que está definido como justo, donde se pueden percibir imperfecciones, pero el sonido es claro; este es el rango supuesto para comunicaciones de voz. Por encima de este valor de tráfico generado, se observa detrimento en la comunicación, al llegar a un valor de 2,5, que se encuentra en mitad de la catalogación entre muy molesto y molesto, lo cual indica que está cerca de la imposibilidad de comunicación.

En Linux se presenta un comportamiento similar, pues decae después de que el tráfico pasa de 100 Mbps hasta llegar a valores de 2,4 y 2,7 para versión 4 y 6, respectivamente. Al comparar la Figura 13 con la 14, se puede deducir que la pérdida de paquetes es el principal factor que degrada la calidad de la comunicación. Mientras la pérdida de paquetes se mantuvo en 0, el MOS fue de 4,5, y a medida que aumentó la pérdida fue disminuyendo el valor de MOS.

Respecto al troughput, se debe tener en cuenta que el tamaño de la cabecera IPv6 es de 40 bytes y la dirección es de 16 bytes (el doble del tamaño de una cabecera, en dirección IPv4 fija). Sin embargo, si la tasa de paquetes por segundo es casi la misma para IPv6 e IPv4, los valores de rendimiento deben ser similares.

Los valores esperados de rendimiento para voz con IPv4 e IPv6 son, respectivamente, 87,2 y 95,2 Kbps (en caso de que se ignore CRC, como Wireshark lo hace, los valores son 85,6 y 93,6 Kbps, respectivamente, y la relación de rendimiento es 0,915). Sin embargo, los factores que afectan el rendimiento, tales como diferencias entre las pilas de IPv6 e IPv4, el procesamiento de datos superiores y los retrasos, no se reflejan en los valores teóricos [14]. Los resultados prácticos pueden verse en la Figura 15. En esta gráfica se tienen valores para Windows XP que van decreciendo a medida que aumenta el tráfico de fondo, y van entre los 85 kbps y 94 Kbps, para versión 4 y 6 respectivamente, y sin tráfico de fondo, decayendo hasta llegar a 70 Kbps y 78 Kbps en versión 4 y 6, con el máximo tráfico de fondo.

Figura 14. MOS.

Figura 15. Troughput.

En Linux los valores van desde 85 Kbps y 94 Kbps, para IPv4 e IPv6, sin tráfico de fondo, y decaen hasta llegar a los 70 kbps, en ambas versiones, cuando se tiene tráfico de fondo de 200 Mbps.

Los resultados experimentales muestran que la disminución de rendimiento es un poco más rápida en IPv6 que en IPv4 con altos niveles de tráfico de fondo. Esto se debe a que IPv6 posee un nivel de paquetes por segundo menor. El rendimiento varía desde 83,24 hasta 85,63 Kbps para IPv4 e IPv6 de 93,61 a 93,63 Kbps sin tráfico de fondo, y desde 70,40 hasta 75,20 Kbps para IPv4 e IPv6 de 71,18-77,56 Kbps.

Conclusiones

Un entorno de la telefonía IP se compone de una serie de protocolos. Estos protocolos interoperan de una manera jerárquica para proporcionar los servicios necesarios. El protocolo de interacción se puede representar como una pila, similar al método utilizado para representar a muchos otros sistemas de comunicaciones.

Eventualmente, todas las redes de telefonía tradicional serán reemplazadas por telefonía VoIP. Las ventajas que proporciona esta tecnología, al compararla con la telefonía tradicional, son tantas que ya muchas empresas están cambiando sus sistemas de telefonía por VoIP, y muchos hogares en el mundo ya lo están adquiriendo.

Las ventajas son, usualmente, costos muchos más bajos para llamadas de larga distancia, llamadas locales usualmente gratis y servicios adicionales que las telefónicas cobran aparte: Caller ID, llamada en espera, transferencia de llamadas, llamada tripartita, entre otras.

EL número de posibles direcciones IP en la versión 6 soluciona el problema de falta de direcciones de IPv4 y esto permite llevar VoIPv6 a cualquier dispositivo que soporte IPv6, lo que posibilita la integración del servicio en muchos más aparatos, como electrodomésticos, celulares y vehículos.

El protocolo de señalización más óptimo es el SIP, pues este, al tener ya definidas las características para la transición a IPv6, permite la interoperabilidad entre IPv4 e IPv6.

Dentro de los beneficios de migrar las redes de voz a IPv6 se encuentran los menores costos de la comunicación y cabeceras de protocolo más óptimas.

Referencias

1. M. Axel. IPv6 Interoperabilidad y robustez. México: Centro de investigación y de estudios avanzados del instituto politécnico nacional, 2004.
2. ITU. Recommendation H323: Visual telephone systems and equipment for local area networks provide a nonguaranteed quality of service 12/09. [En línea]. Disponible en: http://www.itu.int/rec/T-REC-H.323-200912-I/en
3. TCP/IP. ”Voice over IP“. Tutorial and technical overview. Redbooks, IBM, 2007, Chapter 20.
4. Internet Protocol, Version 6 (IPv6) Specification, RFC 2460. Diciembre 1998. [En línea]. Disponible en: http://www.ietf.org/rfc/rfc2460.txt
5. S. Ahuatzin y L. Gerardo. Desarrollo de un esquema de traducción de direcciones IPv6-IPv4-IPv6. Puebla: Universidad de las Américas, 2005, pp. 26-40.
6. IP Version 6 Addressing Architecture. RFC 2373. Julio 1998. [En línea]. Disponible en: http://www.ietf.org/rfc/rfc2373.txt
7. SIP. Session Initiation Protocol. RFC 3261. Junio 2002. [En línea]. Disponible en: http://www.ietf.org/rfc/rfc3261.txt
8. IPv6 Transition in the Session Initiation Protocol (SIP). RFC 3264. Abril 2011. [En línea]. Disponible en: http://www.ietf.org/rfc/rfc3264.txt
9. Jessica Diana C. y Ana Gabriela V. Telefonía IP. Análisis de tecnologías existentes y diseño de proyecto de implementación en una entidad financiera. Universidad Politécnica Salesiana, 2011, pp. 12-30.
10. Using the Flow Label Field in IPv6. RFC 1809. Junio 1995. [En línea]. Disponible en: http://www.ietf.org/rfc/rfc3264.txt
11. O. Salcedo, D.López y Á. Rodríguez. Desempeño de la Calidad del Servicio (QoS) sobre IPv6. Bogotá: Universidad Distrital Francisco José de Caldas, agosto de 2010.
12. H. Rune. A framework architecture for internetworking PSTN, IPv4 and IPv6. [En línea]. Disponible en: http://www.6init.org/public/6INIT_iw2000.pdf
13. J. Jefferson. Implementación de VoIP sobre IPv6. Universidad Técnica Particular De Loja, 2009, pp. 76-83.
14. Y. Roman; W. Alexander; K. Ramesh y K. Gholam. A Comparison of VoIP Performance on IPv6 and IPv4 Networks. Towson University. [En línea]. Disponible en: http://triton.towson.edu/~karne/dosc/paper12/roman1.Pdf
15. U. Nadeem. Mean Opinion Score - A Measure Of Voice Quality. [En línea]. Disponible en: http://voip.about.com/od/voipbasics/a/MOS.htm
16. Miguel G. Tomás P. Modelo de servicios de colaboración basados en SIP. [En línea]. Disponible en: http://ciberia.ya.com/disenydonat/disenydonat/treballs/mgomez_t.pdf
17. D. Kaushik. VoIP - Next Generation of Voice & IPv6. En línea: [En línea]. Disponible en: http://www.ipv6.com/articles/voip/VOIP-IPV6.htm

---

Creation date: Junio de 2012