2.9.1. MGCP. El MGCP es, en esencia, un protocolo maestro/esclavo, donde se espera que los gateways ejecuten comandos enviados por el MGC. El Protocolo de Control de Media Gateway (MGCP) es usado para controlar los gateways de telefonía desde los elementos de control de llamadas externos llamados Media Gateways Controllers (MGC) o Gatekeepers. Un gateway de telefonía es un elemento de red que provee conversión entre las señales de audio transportadas sobre los circuitos telefónicos y los paquetes de datos transportados sobre la internet o sobre otra red de paquetes.
MGCP asume una arquitectura de control de llamada, donde la inteligencia del control de la llamada está fuera de los gateways y manejada por un elemento de control de llamada externo. El MGCP asume que estos elementos de control de llamadas o MGC, se sincronizarán entre sí para enviar comandos coherentemente a los gateways que están bajo su control.
Lo que se propuso con MGCP fue sacar el control de la señalización del propio gateway (GW), llevándolo a otro elemento, el "media gateway controller" MGC (que se conoce como "softswitch") que se encargará del control de los media gateways"(MGW). A nivel de sistemas lo que se ha hecho es desagregar el gatekeeper (GK) en sus equivalentes en el mundo SS7. Esta iniciativa surgió de varios fabricantes con el nombre de IPDC (Cisco, Alcatel, 3Com et al.) por un lado y SGCP (Telcordia) por otro; un esfuerzo que el IETF aglutinó bajo la denominación de MGCP y asignada a la responsabilidad del grupo de trabajo Megaco. MGCP es en la fecha de redacción de este documento un documento de trabajo. Tanto IETF como la ITU-T trabajan para llegar a un estándar, el primero bajo la responsabilidad de Megaco y como H.248 para el segundo.
En MGCP se puede decir que se ha separado la "inteligencia" (las funciones de control) de los datos (los contenidos: "the media"). Que se trata de un protoclo Maestro/Esclavo. El maestro es el MGC ("softswitch" o "call agent") y el esclavo es el MGW (que puede ser un GW de VoIP, un DSLAM, un router MPLS, un teléfono IP,…). Esta es precisamente la característica que más choca con la filosofía (P2P) de SIP. Otra característica interesante es que intenta reproducir el modelo de la PSTN/IN sobre IP (en la Figura 6 se ilustra el escenario típico para un despliegue tipo "Internet Telephony" que es la aplicación para la que se pensó, al menos en principio esta solución), en contra del modelo distribuido que propone SIP.
Figura 6 El Megaco pretende dar una solución basada en una visión propia de las Telcos tradicionales, una oficina central (Central Office, CO, en este caso IPCO) y una red de sucursales (Branch Offices, BO). Tal y como se observa en la Figura 7, SIP puede complementar a MGCP en un escenario donde tengamos varios MGC.
Figura 7 En la Figura 8 se detalla un poco más lo que sería un escenario integrado con la PSTN, pensando en prestar el servicio de telefonía sobre Internet.
Figura 8 Un tema de debate importante es la utilización de MGCP para controlar los terminales (los teléfonos IP por ejemplo); el problema que surge es que sólo soporta servicios básicos de red inteligente. El tema es que si se quieren desplegar servicios avanzados necesitamos montar SIP tanto en los terminales como sobre la red de señalización, realizando las funciones de control asociadas al servicio.
Ya se ha comentado más arriba que la visión de los partidarios de MGCP es que la inteligencia del servicio esté pegada a los MGC (softswitch), y de hecho en el corto plazo es un planteamiento adecuado puesto que el esfuerzo de convergencia se centrará en los puntos de interconexión entre la PSTN y la red IP, y pro tanto interesará que los servidores SIP estén junto a los MGC en la CO. Pero, según avancemos hacia un escenario más integrado, la atención se centrará en la infraestructura IP, con lo cual la función de los MGC se alejará de los puntos de interconexión. Finalmente, en un entorno IP puro, la función de creación de servicios se distribuirá por toda la red: se puede extender el modelo ASP para dar servicios de voz. Tanto los ASPs como los ISPs, o incluso los propios usuarios finales pueden crear sus propios servicios. Se puede pensar en un escenario basado en SIP, donde se utilice MGCP para controlar internamente un GW de Telefonía IP (TIP) y los servidores de aplicaciones SIP distribuirían servicios por la red a través de los servidores proxy SIP.
Como conclusión debemos extraer el hecho de que MGCP no se puede considerar como un competidor de SIP, puesto que ambos resultan complementarios en ciertos aspectos, mientras que son mutuamente excluyentes en otros.
Esta idea de dividir el Gateway de voz en varias entidades funcionales se ha propuesto también desde iniciativas como TIPHON (Telecommunications and Internet Protocol Harmonization Over Networks) de la ETSI, con la intención de proporcionar una arquitectura "escalable" que soporte el servicio de Telefonía IP con la necesaria capacidad para convivir con las redes tradicionales de conmutación de circuitos (SCN, Switched Circuit Networks) como la PSTN. Esta división es la que se ilustra en el Diagrama 2 (de la misma forma en la Figura 9 podemos ver los componentes e interfaces en cuya definición trabaja la ETSI en el ámbito de TIPHON).
Diagrama 2. Descomposición del Gateway e interacción con la PSTN
Figura 9
2.10. SIGTRAN. 2.10.1 ¿QUÉ ES EL SIGTRAN ? SIGTRAN (de signalling transport) es el nombre del grupo de trabajo del IETF encargado de definir una arquitectura para el transporte de señalización en tiempo real sobre redes IP. A raíz de ello, no sólo se creó una arquitectura, sino que se definió un conjunto de protocolos de comunicaciones para transportar mensajes SS7 sobre IP.
2.10.2 ARQUITECTURA DE LOS PROTOCOLOS SIGTRAN . La arquitectura definida por el Sigtran [RFC2719] consta de tres componentes:
• IP estándar como protocolo de red.
• Un protocolo común de transporte de señalización. Los protocolos definidos por el Sigtran se basan en un nuevo protocolo de transporte sobre IP, llamado SCTP (Stream Control Transmission Protocol).
• Capas de adaptación específicas para cada capa de la torre SS7 que se necesite transportar. El IETF ha definido las siguientes: M2PA, M2UA, M3UA, SUA, TUA e IUA. IP SCTP Capa de adaptación S7UP/S7AP
2.11. M2UA [RFC 3331].
M2UA son las siglas de MTP2 User Adaptation. El protocolo M2UA, al igual que M2PA, adapta MTP3 a SCTP, e igualmente gestiona asociaciones SCTP en lugar de enlaces MTP3. M2UA permite el intercambio de mensajes MTP3 entre dos puntos de señalización IP o entre un punto de señalización IP y una pasarela IP-SS7.
M2UA es un protocolo entre pares en caso de que la comunicación comience y termine en dos puntos de señalización IP, sin SGWs intermedios, tal como muestra la Figura 12.
Sin embargo, M2UA no es un protocolo entre pares si se implementa en una pasarela de señalización. En ese caso, M2UA no procesa las órdenes (primitivas del protocolo) que le llegan desde la capa superior (MTP3), sino que las envía tal cual hacia un nodo remoto, mediante SCTP.
Como M2UA no procesa las primitivas de MTP3, sino que las reenvía, en caso de que se utilice un SGW se debe entender este protocolo como un medio que comunica la capa MTP3 de un nodo IP con la capa MTP2 de un SGW, tal como muestra la Figura 13.
De esta forma, varios puntos de señalización IP con MTP3 sobre M2UA pueden acceder a la red SS7 tradicional a través de los mismos enlaces MTP2 físicos.
Es importante tener en cuenta que, debido a la propia naturaleza del protocolo, sólo puede existir un SGW M2UA en una misma comunicación MTP3, por lo que no se puede utilizar para transportar mensajes MTP3 entre dos nodos SS7 puros a través de una red IP. Si se utiliza M2UA, alguno de los extremos es un punto de señalización IP.
2.12. M3UA [RFC 3332]. M3UA son las siglas de MTP3-User Adaptation. M3UA es un protocolo que transporta mensajes procedentes de un usuario de MTP3 (ISUP, TUP o SCCP) a través de una red SCTP/IP hasta un nodo remoto.
De forma similar a M2UA, M3UA simplemente transporta los mensajes hasta el destino, pero no realiza por sí mismo las funciones de la capa MTP3. Esto significa que M3UA no dispone de tablas de encaminamiento basadas en puntos de señalización, ni realiza ninguna otra función propia de MTP3.
En general, M3UA se utilizará como medio de transporte de primitivas entre la capa usuaria de MTP-3 (SCCP o ISUP) de un punto de señalización IP y la capa MTP3 de un SGW remoto, tal como muestra la Figura 14.
2.12.1. UTILIZACIÓN DE M3UA. Como se ha visto, dado que M3UA transporta primitivas desde la capa ISUP o SCCP de un nodo hasta la capa MTP3 de otro (típicamente un SGW), este protocolo sólo puede utilizarse para conectar nodos con señalización IP a una red SS7. Por tanto, no se puede utilizar M3UA para descargar tráfico SS7 entre dos nodos TDM a través de red IP, a no ser que se utilicen SGWs con SCCP. Pero para esta aplicación es mucho más adecuado utilizar SGWs con M2PA, por los motivos indicados en el apartado 3.3.
2.13. CARACTERÍSTICAS PRINCIPALES DEL SIGTRAN. Debido a los inconvenientes mencionados de TCP y UDP, el SIGTRAN definió del protocolo SCTP, cuyas principales características son las siguientes:
• Es un protocolo punto a punto. Se establece intercambio de datos entre dos extremos conocidos.
• Define tiempos de reintento (time-outs) mucho menores que los de TCP.
• Proporciona transporte fiable de datos de usuario, detectando y reparando los datos erróneos o fuera de secuencia. • Se adapta a la tasa de transferencia, disminuyendo la velocidad de envío de datos en caso de congestión en la red.
• Permite definir en un mismo extremo SCTP en varios servidores físicos (multihoming). Un único extremo SCTP se puede definir en varias direcciones IP.Hacia cada una de ellas se encaminan los mensajes de forma independiente, de manera que si uno de los nodos físicos queda fuera de servicio, el resto de comunicaciones no se ven afectadas.
2.13.1. FUNCIONES DE SCTP. 2.13.2 ESTABLECIMIENTO Y LIBERACIÓN DE ASOCIACIONES Una asociación SCTP es una relación de comunicación de mensajes entre dos entidades SCTP (comunicación orientada a conexión). Las asociaciones SCTP se establecen a petición del usuario de nivel superior de este protocolo. Para proporcionar protección frente a ataques de denegación de servicio, se emplea un protocolo de establecimiento de asociaciones en cuatro pasos, basado en cookies [RFC2522].
2.13.3. ENTREGA ORDENADA DENTRO DEL STREAM DENTRO DEL SCTP. Dentro del protocolo SCTP, se utiliza el término stream para referirse a una secuencia de mensajes de usuario que debe entregarse al nivel superior de forma ordenada. El número de streams que se enviarán a través de una asociación se define en el establecimiento de la misma, de forma negociada entre ambos extremos de la comunicación. Los streams son unidireccionales, de forma que para una comunicación bidireccional se deberán definir al menos dos streams en una asociación SCTP.
Los mensajes de usuario se asocian a streams determinados, de forma que el extremo receptor SCTP entrega al nivel superior todos los mensajes de un mismostream en el mismo orden en que se enviaron. Sin embargo, no existen restricciones de entrega ordenada entre mensajes de distintos streams de la misma asociación. De esta forma, los mensajes de un stream se pueden seguir entregando aunque otro esté bloqueado esperando el siguiente mensaje. Adicionalmente, SCTP proporciona un mecanismo para no utilizar el servicio de entrega ordenada de mensajes, de forma que los mensajes enviados mediante dicho mecanismo se entregan al nivel superior del destino SCTP tan pronto como se reciben.
2.13.4. FORMATO DE PAQUETES SCTP. Un paquete SCTP se compone de una cabecera de 24 octetos y una serie de unidades de información, denominadas chunks. Estas unidades de información pueden contener datos de usuario, o instrucciones de control del propio protocolo SCTP (establecimiento y liberación de asociaciones, control de flujo, retransmisiones, etc). Los chunks tienen estructura propia, y presentan una serie de campos, dependiendo del tipo de chunk que sean.
En el ámbito de la planificación de una red SS7 sobre IP, el dato más relevante es el tamaño de las cabeceras de los datos de usuario. La cabecera de un chunk de datos de usuario mide 16 octetos, y pueden contener hasta 65520 octetos de información del nivel superior. Esto significa que, en principio, cualquier mensaje de cualquier operación MAP, ISUP o CAMEL cabe en un chunk de datos SCTP, incluyendo las cabeceras de los protocolos de adaptación intermedios.
Además, SCTP permite transportar varios mensajes de usuario en un único mensaje SCTP, mediante el uso de distintos chunks de datos dentro del mismo mensaje.
2.13.5. VALIDACIÓN DE PAQUETES. Dentro de la cabecera común de SCTP se incluye un campo de verificación obligatorio, aparte de otro campo de 32 bits con una suma de comprobación (checksum) frente a errores. El valor del campo de verificación obligatorio lo decide el extremo de la comunicación SCTP en el establecimiento de la asociación. De esta forma se consigue más protección frente a comunicaciones con suplantación de identidad. La suma de comprobación se calcula a partir de los datos de la propia cabecera SCTP y la protege frente a errores en la comunicación.
2.13.6. GESTIÓN DE CONEXIONES El usuario del nivel SCTP puede manipular el conjunto de direcciones de transporte destino de los mensajes. La función de gestión de conexiones de SCTP escoge la dirección de transporte destino para cada paquete SCTP que se envía, basándose en las instrucciones del usuario de SCTP y en las direcciones disponibles alcanzables para ese destino SCTP.
En periodos de inactividad, la función de gestión de conexiones monitoriza la disponibilidad de los extremos de la comunicación mediante mensajes de comprobación (heartbeats). Si SCTP percibe algún extremo como inalcanzable informa a su usuario de nivel superior.En el establecimiento de la asociación, se define un camino primario para cada extremo SCTP, que es el que se usa en el envío normal de paquetes.
En el extremo receptor, la gestión de conexiones se encarga de comprobar la existencia de una asociación SCTP válida a la que pertenece cada paquete SCTP recibido.
2.13.7. FRAGMENTACIÓN DE LOS DATOS DE USUARIO SCTP posee mecanismos de fragmentación y re-ensamblado de mensajes de usuario para adecuarlos al tamaño requerido por el nivel inferior (IP en el caso de SS7 sobre IP).
2.13.8 CONTROL DE ENTREGA DE MENSAJES. SCTP asigna un número de secuencia de transmisión (TSN) a cada mensaje de datos de usuario, fragmentado o no. El TSN es independiente del stream por el que se envía el mensaje. El extremo receptor envía acuses de recibo (ACK) de todos los TSNs recibidos, aunque no lleguen de forma ordenada. De esta forma, la fiabilidad en la entrega de los mensajes se mantiene funcionalmente separada de la entrega ordenada dentro del stream.
CAPITULO 3
Voz en conmutación de paquetes CXP
3. ¿QUÉ ES VOIP ?. VoIP o Voz sobre IP, es una red de paquetes de datos para transportar tráfico de voz en tiempo real. Esta consiste de hardware y software y permite a las compañías y a las personas realizar conversaciones telefónicas sobre la red de datos. También puede ser definida como la habilidad para hacer llamadas telefónicas y enviar fax sobre la red de datos basada en IP con una adecuada calidad de servicio (QoS) y a una relación costo/beneficio superior. Esto también es conocido como telefonía por internet. Sin embargo, este último término es usado en referencia a las llamadas hechas sobre la internet pública y la VoIP es frecuentemente usada para referirse a las llamadas hechas en una red privada.
La red de voz tradicional o PSTN, usa técnicas de conmutación de circuitos. Esto significa que una comunicación particular usa un enlace dedicado durante la duración de la llamada. Aunque esta provee una conexión muy confiable para la transmisión de voz, hace un uso muy ineficiente del ancho de banda. Por otro lado, la red de datos generalmente usa conmutación de paquetes. Aquí se usa Conmutación de celdas estadísticas (STDM) con la finalidad de proveer un ancho de banda dinámico a una particular cadena de datos, basada en sus requerimientos y en los requerimientos y demandas de otros datos de la red. Esta provee un uso más eficiente de ancho de banda pero puede crear problemas para el tráfico de voz, el cual es sensible al retardo, debido a que cada paquete es enrutado individualmente a través de la red; esta conmutación de paquetes hace a la red menos eficiente en el tráfico de voz y presenta mayores retos a la calidad de la transmisión de voz. Esto incluye: pérdida de paquetes, retardo (eco), Jitter (variación en la velocidad de transmisión de paquetes de datos) y la entrega de paquetes poco confiable y fuera de orden debido a la naturaleza no orientada a conexión de la red de paquetes.
3.1. ARQUITECTURA. Las llamadas de VoIP requieren al menos dos gateways de VoIP. Típicamente, un proveedor de servicios debería instalar gateways (o interactuar con otros proveedores de servicios y acceder a sus gateways) en todos los países o regiones hacia los cuales se realizan o se reciben llamadas. El resultado de la red de VoIP se compone de gateways, el acceso de la PSTN a cada gateway y la red IP que enlaza los gateways.
En la red telefónica IP, la información de señalización es intercambiada entre los siguientes elementos funcionales. Estos mismos se tomarán en cuenta para las configuraciones de red que se plantearán más adelante.
Media Gateway: la tecnología de VoIP permite que las llamadas originadas y terminadas en la PSTN, sean transportadas sobre la red IP, es decir, éste traduce TDM a paquetes. El gateway de VoIP sirve de puente entre la red PSTN y la red IP para ambos lados de origen y terminal de la llamada. Para realizar una llamada, el abonado llamante accederá el gateway mas cercano o por conexión directa o realizando una llamada sobre la red PSTN e ingresando el número telefónico de destino.
La tecnología de VoIP traduce el número telefónico de destino en la dirección de la red de datos ("dirección IP") asociada con el correspondiente gateway terminal mas cercano al número de destino. Usando el protocolo apropiado y la transmisión de paquetes sobre la red IP, el gateway terminal iniciará una llamada al número telefónico de destino sobre la red PSTN para completar el establecimiento de la comunicación en ambos sentidos con los extremos finales (punto a punto). A pesar de la conexión adicional requerida, el tiempo total del establecimiento de la llamada no es significativamente mas largo que con una llamada soportada por la PSTN.
Los gateways pueden emplear un protocolo común, por ejemplo, el H.323 o MGCP o un protocolo propietario, para soportar el estándar de señalización telefónico. Los gateways emulan las funciones de la PSTN en respuesta a los estados de cuelgue y descuelgue, recibiendo o generando dígitos DTMF y recibiendo o generando tonos de llamadas en progreso. Las señales identificadas son interpretadas y mapeadas para la transmisión del mensaje apropiado hacia el gateway con la finalidad de soportar el establecimiento de la llamada, mantenimiento, facturación y finalización de la llamada.
Media Gateway Controlador o Gatekeeper: un gatekeeper (GK) maneja los registros y la gestión de los recursos de los media gateways de manera que no se produzcan situaciones de saturación en la red. Un gatekeeper intercambia mensajes ISUP con las centrales telefónicas via un gateway de señalización. De esta forma el GK traduce direcciones telefónicas a direcciones IP.
La interpretación del número telefónico de destino en la dirección IP del media gateway terminal indicado es una función primordial del gatekeeper. La tabla de enrutamiento mantenida por el gatekeeper decide cual media gateway corresponde al número telefónico de destino con la finalidad de completar la llamada.
La funcionalidad del gatekeeper puede ser distribuída entre todos los media gateways de la red de VoIP o puede ser centralizada en una o varias localidades. Cuando las funciones del gatekeeper están implantadas en cada media gateway, todos los gateways de toda la red de VoIP actúan independientemente para coordinar sus acciones. Cuando un gatekeeper es centralizado, todos los media gateways de la red coordinan sus acciones con respecto al gatekeeper centralizado en lugar de que actúen independientemente.
Gateway de Señalización o Signaling Gateway: el gateway de señalización provee una traducción transparente de la señalización entre la conmutación de circuitos y la red IP. Un gateway de señalización puede señalizar en S7 (señalización Nº 7) o traducir y transmitir mensajes sobre una red IP a un media gateway controlador o a otro gateway de señalización. Debido a su rol crítico en la integración de la red de voz, los gateway de señalización son normalmente desarrollados en grupos de dos o más para asegurar alta disponibilidad.
La funcionalidad del media gateway, o gateway de señalización y/o media gatekeeper pueden estar separadas en dispositivos diferentes o integrados en una sola unidad.
Ejemplo de una configuración de red VoIP
3.2. CALIDAD DE SERVICIO (QOS). Esta función tiene primordial importancia en relación con la QoS experimentada por el usuario final. En esto influyen dos factores fundamentales:
• La calidad de la voz extremo a extremo, determinada por los sucesivos procesos de codificación – decodificación, y las pérdidas de paquetes en la red.
• La demora extremo a extremo, debido a las sucesivos procesos de codificación, decodificación, paquetización y "encolados". Afecta la interactividad en la conversación y por tanto a la QoS.
• Las redes IP son redes del tipo best-effort y por tanto no ofrecen garantía de QoS, pero las aplicaciones de telefonía IP si necesitan algún tipo de garantía de QoS en términos de demora, jitter y pérdida de paquetes.
La preparación de los medios en los terminales para ser enviados y transferidos por la red IP involucra varios procesos: digitalización, compresión y empaquetado en el extremo emisor, y los procesos inversos en el extremo receptor. Todo esto se lleva a cabo mediante un complejo procesamiento que sigue determinado algoritmo, lo cual a su vez se desarrolla en cierto intervalo de tiempo, esto es, implica demora de procesamiento y demora de empaquetado:
• Demora de procesamiento: demora producida por la ejecución del algoritmo de codificación, que entrega un stream de bytes listos para ser empaquetados.
• Demora de paquetización: es el tiempo que se requiere para formar un paquete de voz a partir de los bytes codificados. Debe señalarse que el resultado de esta codificación – paquetización incide directamente en la QoS, y también la forma en que se lleve a cabo. Así, cuando se reduce la velocidad de codificación los requerimientos de ancho de banda también se reducen, lo que posibilita de cara a la red poder manejar más conexiones simultáneas, pero se incrementa el retardo y la distorsión de la señales de voz. Lo contrario ocurre al aumentar la velocidad de codificación. Otro aspecto a considerar es el compromiso entre el retardo de paquetización y la utilización del canal (relación entre bytes de información y bytes de cabecera en cada paquete de voz), es decir, la búsqueda de mayor utilización del canal conduce a mayor demora de paquetización para cierto estándar de codificación. Claro está, según el estándar de codificación que se utilice será la demora resultante en relación con la utilización del canal, diferencias que se acentúan cuando la utilización del canal está por encima del 50 %, con un crecimiento de la demora en forma exponencial en el caso de los codecs de baja velocidad como el G.723.1. La demora de paquetización también puede ser reducida mediante multiplexación de varias conexiones de voz en el mismo paquete IP. A las demoras de procesamiento y empaquetado se suma también la demora que introduce el proceso de buffering en los terminales, y la demora de "encolado" en la red. Todo esto da una demora extremo a extremo que percibe el usuario final en mayor o menor medida. A continuación se resumen los aspectos que afectan la QoS en las redes de VoIP.
3.3. RETARDO. Se refiere sobre todo al tiempo de tránsito total, incluido el tiempo necesario para reconstituir el orden de los paquetes cuando se reciben y para compensar las fluctuaciones de los tiempos de tránsito (este tiempo de tránsito total debe ser inferior a 400 ms si se han de respetar las limitaciones de la conversación interactiva). Los excesivos retardos punto a punto hacen conversaciones difíciles y poco naturales. Cada componente en el camino de transmisión – emisor, red y receptor añaden retardo. ITU-TG.114 (tiempo de transmisión en un solo sentido) recomienda 150 mseg. como el máximo retardo deseado en un sentido para lograr alta calidad de la voz.
Retardo extremo a extremo El retardo causa dos problemas: eco y traslape del habla. El eco es causado por las señales reflejadas por el equipo telefónico del extremo distante que regresan al oído del hablante. El eco llega a ser un problema significativo cuando el retardo del viaje redondo llega a ser mas de 50 milisegundos. A medida que el eco se incremente, los sistemas de paquetes se ven en la necesidad de utilizar controles como la cancelación de eco.
El traslape del habla (cuando dos personas hablan casi al mismo tiempo) es significativo si el retardo en una sola vía es mayor de 250 milisegundos. Por lo tanto el retardo completo llega a ser mayor. Algunas de las fuentes de retardo en una sola vía para una llamada hecha con paquetes de voz se describen a continuación.
3.3.1. RETARDO ACUMULADO ( Retardo algorítmico). Es causado por la necesidad de recolectar un marco de muestras de voz para que sean procesados por el codificador de voz. Esto está relacionado con el tipo de codificador usado y varia de una sola muestra en el tiempo (.125 µsg) a muchos milisegundos.
Codificadores de voz y sus tiempos:
1. G.726 modulación adaptativa diferencial de pulsos codificados (ADPCM), 16, 24, 32, 40 Kbps = 0.125 µsg.
2. G.728 predicción lineal de excitación de código LD (CELP), 16 Kbps = 2.5 msg 3. G.729 CS-ACELP 8Kbps = 10 msg 4. G.723.1 codificador multitasa, 5.3, 6.3 Kbps = 30 msg.
3.3.2. RETARDO DE PROCESAMIENTO.
Es causado por el procesamiento de codificación y recolección de las muestras codificadas en paquetes para la transmisión sobre una red de paquetes. El retardo de codificación es una función del tiempo de ejecución del procesador y el tipo de algoritmo usado. A menudo se recolectan múltiples marcos de codificación de voz en un solo paquete para reducir la cabecera del paquete. Por ejemplo, 3 marcos de palabras codificadas en G.729 (equivalente a 30 milisegundos de habla) se recolectan y empacan en un solo paquete.
3.3.3. RETARDO DE RED. Es causado por el medio físico y los protocolos usados para transmitir los datos de voz y por los buffers usados para remover el jitter en el lado receptor. El retardo de red es una función de la capacidad de los enlaces en la red y del procesamiento que ocurre a medida que los paquetes transitan por esta. Los buffer para jitter agregan retardo, que es utilizado para remover la variación de retardo a la que están sujetos los paquetes a medida que transitan en una red de paquetes.
3.4. COLAS. S e definen como las que manejan el trafico mediante la asignación de distintas cantidades de espacio en la cola a las diversas clases de paquetes y a continuación dan servicio a las colas en la modalidad de ordenamiento cíclico. Aunque se puede asignar un mayor espacio en la cola a un protocolo, usuario o aplicación particular, ninguno de ellos podrá monopolizar nunca toda la anchura de la banda.
3.5. ECO. El eco es el tiempo que transcurre entre la transmisión de una señal y su regreso al transmisor. Por lo general, este problema aparece en el contexto de las comunicaciones de PC a teléfono, de teléfono a PC o de teléfono a teléfono, y es causado por los componentes electrónicos de las partes analógicas del sistema que reflejan una parte de la señal procesada Un eco menor que 50 milisegundos es imperceptible. Por encima de este valor, el hablante oirá su propia voz después de haber hablado. Si se desea ofrecer un servicio de telefonía IP, las pasarelas tendrán que procesar el eco generado por la transferencia de dos a cuatro hilos, de lo contrario, no será posible utilizar el servicio con equipos analógicos clásicos. Como solución, se están instalando compensadores de eco de alta calidad en la pasarela de la red. A medida que el eco se incremente, los sistemas de paquetes se ven en la necesidad de utilizar controles como la cancelación de eco.
3.5.1. COMPENSACIÓN DE ECO. El eco en una red telefónica, es causado por las reflexiones de señales generadas por un circuito híbrido que convierte de 4 hilos (un par para transmisión y uno para recepción) a 2 hilos (un solo hilo para transmisión y uno para recepción). Estas reflexiones de la voz del hablante son escuchadas por el oyente. El eco se presenta aún en las redes de conmutación de circuitos, sin embarco acá es aceptable ya que los retardos completos a través de la red son menores que 50 msg. Y el eco es enmascarado por el tono lateral que todo teléfono genera.
Existen dos (2) tipos de eco. Uno tiene alto nivel y poco retardo y se produce en el circuito híbrido de 2 a 4 hilos local; mientras que otro es de bajo nivel y gran retardo y se produce en el circuito separador híbrido remoto.
El eco es problema en una red de paquetes de voz cuando el retardo completo en la red es mayor que 50 msg, entonces se deben aplicar técnicas de cancelación de eco.El estándar G.165 de la UIT define el desempeño de los canceladores de eco, en la recomendación G.IEC se encuentran mas características.
El cancelador de eco compara los datos de voz recibidos de la red de paquetes con los datos de voz que están siendo transmitidos por la red de paquetes. Se construye mediante la técnica de ecualización transversal autoadaptativa. Consiste en usar una parte de la señal de transmisión para cancelar el eco producido por la desadaptación de impedancias en el circuito híbrido que convierte de 4 a 2 hilos.El eco del híbrido de la red de paquetes se remueve con un filtro digital en el camino de transmisión hacia la red de paquetes.
3.5.2. AMBIENTE DE PORTABILIDAD EN TIEMPO REAL. Provee un ambiente de operación para el software que reside en el DSP. Esto hace funciones de sincronización, tareas de gestión, gestión de memoria, y gestión de tiempos.
3.6. JITTER.
Cuantifica el efecto del retardo total en la red ocasionado por los paquetes que llegan al receptor. Los paquetes transmitidos a intervalos iguales desde el gateway de la izquierda llegan al gateway de la derecha a intervalos irregulares. El excesivo jitter hace que la voz sea entrecortada y con dificultades para entenderse. El jitter es calculado basado, en las horas de llegada entre paquete y paquete de los paquetes exitosos. Para una alta calidad de voz, el promedio de las horas de llegada entre los paquetes en el receptor debería ser casi igual a la diferencia entre los paquetes en el transmisor y el estándar de desviación debería ser bajo. El jitter buffer (el buffer mantiene paquetes entrantes por una determinada cantidad de tiempo) es usado para neutralizar los efectos de las fluctuaciones de la red y crear un fácil flujo de paquetes en la recepción.
Es tambien, la variación de tiempo entre los paquetes causada por la red. Remover el jitter requiere la recolección de paquetes y retención de estos el tiempo suficiente para que el paquete mas lento llegue a tiempo para ser interpretado en la secuencia correcta.
El conflicto que se produce al querer mezclar el retardo con la supresión del jitter, ha generado varios esquemas para adaptar el tamaño del buffer de jitter a los requerimientos de variaciones de tiempo de la red. Esta adaptación tiene la meta explícita de minimizar el tamaño y retardo del buffer de jitter mientras que al mismo tiempo previene el sobre flujo del buffer causado por el jitter.Se han hecho dos aproximaciones para adaptar el tamaño del buffer, la selección de la aproximación depende del tipo de red de paquetes usada.
La primera aproximación es medir la variación del nivel de paquetes en el buffer de jitter en un periodo de tiempo e incrementalmente adaptar el tamaño del buffer para que coincida con el jitter calculado. Esto funciona mejor con redes que tienen jitter constante en un periodo de tiempo, como las redes ATM La segunda aproximación es contar el número de paquetes que llegan tarde y crear una relación de estos paquetes al numero de paquetes que son procesados exitosamente. Esta relación es usada para ajustar el buffer de jitter a una relación permisible de paquetes tardíos predeterminada. Esto funciona mejor con redes que tengan intervalos de arribo de paquetes altamente variable, como las redes IP.Además de estas técnicas, la red debe estar configurada y gestionada para que tenga retardos y jitter mínimos, permitiendo así un alto QoS.
3.7. CONMUTACIÓN DE PAQUETES. Es un método de comunicación exclusivamente digital, en el que los mensajes que se transmiten se dividen en segmentos y que, junto a la información adicional necesaria para su encaminamiento en la red, se convierten en paquetes. Éstos son transferidos a través de la red mediante procesos de almacenamiento y reenvío sobre circuitos virtuales (circuitos no físicos), que permiten compartir los canales físicos de comunicaciones de la red, pues solamente los ocupan durante el tiempo de transmisión.
3.7.1. PÉRDIDA DE PAQUETES. Típicamente ocurre en ráfagas o periódicamente debido a una red regularmente congestionada. La pérdida periódica en exceso de 5-10% de todos los paquetes de voz transmitidos pueden degradar la calidad de voz significativamente. La pérdida ocasional de grupos de paquetes puede también hacer difícil la conversación.
3.7.2. COMPENSACIÓN DE PERDIDA DE PAQUETES.
La pérdida de paquetes puede ser un problema aún mayor dependiendo del tipo de red de paquetes que esté siendo usada. Ya que la red IP no garantiza el servicio, usualmente tiene mayor pérdida de paquetes que las redes ATM. En redes IP actuales, todos los marcos de voz son tratados como datos. Bajo congestión, los marcos de voz serán descartados al igual que los de datos, estos últimos sin embargo no son sensibles al tiempo, y los paquetes descartados pueden ser recuperados con la retransmisión, mientras que los paquetes de voz no pueden ser tratados de esta manera.
3.7.3. SOLUCIÒNES PARA CORREGIR LA PÉRDIDA DE PAQUETES DE VOZ • Interpolar los paquetes de voz perdidos al repetir el último paquete recibido durante el intervalo cuando el paquete perdido supuestamente debía ser analizado, este esquema es un método simple que llena el tiempo entre marcos de voz no continuos, trabaja bien cuando la incidencia de marcos perdido es poco frecuente; si el numero de paquetes pedidos en una fila o ráfaga es alta no trabaja muy bien.
• Enviar información redundante a expensas de la utilización del ancho de banda; esta aproximación hace una réplica y envía el n-ésimo paquete de voz con el (n+1)ésimo paquete; este método tiene la ventaja que poder corregir la pérdida del paquete exacto, sin embargo usa más ancho de banda e incrementa el retardo.
• Usar una aproximación híbirida con ancho de banda menor del codificador de voz para proporcionar información redundante que será llevada en el (n+1)ésimo paquete; esto reduce el problema de necesidad de ancho de banda extra pero falla en la resolución del problema de retardo.
3.7.4. ERRORES DE SECUENCIA. La congestión en la conmutación de paquetes de la red puede causar paquetes que toman diferentes rutas para alcanzar el mismo destino. Los paquetes pueden llegar fuera de orden resultando una conversación distorsionada.
3.7.5. COMPRESIÓN. Es usada en cualquier proporción de 1:1 hasta 12:1 en las aplicaciones de VoIP para consumir menos ancho de banda y dejar mas para los datos u otras comunicaciones de voz y fax. La calidad de la voz puede decrecer con el incremento en la proporción de la compresión.
3.7.6. REDES DE CONMUTACIÓN DE CIRCUITOS. Por conmutación de circuitos se entiende por el control o enrutamiento de señales en un circuito electrónico para transmitir datos o señales entre puntos específicos en una red; el circuito permanece establecido el tiempo que dure la llamada, quedando en este caso a disposición de otros usuarios para su utilización de igual forma. Esta red es considerada la red telefónica tradicional, la cual sirve de apoyo para extender otros servicios a innumerables usuarios, alcanzando hasta los lugares más recónditos.
3.7.7. ESTANDARES MAS USADOS EN COMPRESIÓN EN EL DOMINIO IP. • Recomendación G.711 La ITU ha estandarizado la Modulación de Código de Pulso Modulation como G.711, permite una señal de audio de calidad tarificada con un ancho de banda de 3.4 KHz que ha de ser codificado para la transmisión de índices de 56 Kbps o 64 Kbps. El G.711 utiliza A-law o Mu-law para una compresión simple de amplitud y es el requisito básico de la mayoría de los estándares de comunicación multimedia de la ITU.
PCM es un método de codificación de señal de audio analógica más popular y es ampliamente utilizado por la red telefónica pública. Sin embargo, el PCM no soporta compresión de ancho de banda, por lo que otras técnicas de codificación como el ADPCM utilizan estimaciones basándose en dos muestras cuantificadas consecutivas para reducir el ancho de banda.
• Recomendación G.728. G.728 codifica una señal de audio de calidad tarificada con un ancho de banda de 3.4 KHz para transmitir a 16 Kbps. Es utilizada en sistemas de videoconferencia que funcionan a 56 Kbps o 64 Kbps. Con un requisito de ordenador más alto, el G.728 proporciona la cualidad del G.711 a un cuarto del índice de datos necesario.
• Recomendación G.723.1. G.723.1 define cómo puede codificarse una señal de audio con un ancho de banda de 3.4 KHz para transmitirse a 5.3 Kbps y 6.4 Kbps. G.723.1 requiere un índice de transmisión muy bajo ofreciendo una calidad de audio cercana a la tarificada. G.723.1 ha sido seleccionada por el VoIP Forum como el codec básico para aplicaciones de telefonía IP de bajo índice de bits.
El codificador de habla G.723.1 opera con tramas de 30 m de señales de habla en ancho de banda de teléfono digitalizadas y de muestreo a 8 kHz. Las tramas se dividen en cuatro subtramas de 7,5 m de 60 muestras cada una. Cada trama con 240 muestras de entrada se transforma en una palabra de 12 16 bits de datos comprimidos a alta velocidad o palabras de 10 16 bits de datos comprimidos a baja velocidad. Las Detección de Actividad de Voz/Generación de Ruido Confortable (Voice Activity Detection/Comfort Noise Generation o VAD/CNG) especificado en el Anexo A se incorporan por completo al ITU-T G.723.1.
• Recomendaciones G.729 y G.729A. Estas recomendaciones codifican señales de audio cerca de la calidad tarificada con un ancho de banda de 3.4 KHz para su transmisión a una velocidad de 8 Kbps. G.729A requiere una potencia de ordenador más baja que G.729 y G.723.1. Tanto G.729 como G.729A tienen una latencia (el tiempo que necesita para convertir de analógico a digital) más baja que G.723.1. Se espera que G.729A tenga un impacto mayor en la compresión de voz para su transmisión sobre redes inalámbricas.
El codificador procesa tramas de muestreo de habla de 10 m a una velocidad de 8 kHz, que junto a una anticipación de 5 m se traduce en un retraso algorítmico total de 15 m. Para cada trama de 80 muestras de datos PCM lineales de 16bits, el codificador obtiene cinco palabras de 16bits. Las aplicaciones que utilizan el vocoder G.729 incluyen telefonía digital, comunicaciones vía satélite y wireless, y Voz sobre Frame Relay (VoFR).
3.7.8. TABLA COMPARATIVA DE CALIDAD.
3.7.9. PROCESO DE LLENADO DE PAQUETES.
• Conmutación de paquetes por datagramas. – La ruta se elige según una base paquete por paquete.
– Los distintos paquetes pueden seguir rutas diferentes.
– Los paquetes pueden no llegar en orden a su destino.
CAPITULO 4
Protocolos de transporte en VOIP
4- PROTOCOLO DE TRANSPORTE EN TIEMPO REAL ( RTP ). Es un protocolo que como su nombre lo indica, está orientado a la transmisión de información en tiempo real, como la voz o el video. Este es un protocolo de las capas superiores de usuario que funciona sobre UDP (user datagram protocol) , como mecanismo de transporte porque posee un menor retardo que TCP, y además porque el trafico de voz en la actualidad, sin importar que sean datos o señalización, toleran menos niveles de perdida y no tienen la facilidad de retransmisión, en el UDP se cambia confiabilidad por velocidad, lo cual es básico para manejo de transmisiones en tiempo real como la VoIP. El protocolo RTP tiene como objetivo asegurar una calidad de servicio QoS para servicios del tipo tiempo-real. Incluye: la identificación del payload, la numeración secuencial, la medición de tiempo y el reporte de la calidad (función del protocolo RTCP).El RTP trabaja en capa 4 y sobre UDP, de forma que posee un checksum para detección de error y la posibilidad de multiplexación de puertas (port UDP).Las sesiones de protocolo RTP pueden ser multiplexadas. Para ello se recurre a un doble direccionamiento mediante las direcciones IP y el número de port en UDP. Sobre RTP se disponen de protocolos de aplicación del tipo H.320/323 para vídeo y voz (H.32x forma una familia del ITU-T de normas para videoconferencia).
El RTP funciona en conjunto con RSVP (capa 3) para la reservación de ancho de banda y asegurar de esta forma la QoS del tipo Garantizada. La QoS del tipo Diferenciada se logra mediante la priorización de tráfico que puede adoptar dos alternativas. En IP se pueden asignar diversos alternativas de prioridad para formar una cola de espera en routers. Un algoritmo particular de gestión de prioridad de tráfico es el WFQ (Weighted Fair Queuing) que utiliza un modelo de multiplexación TDM para distribuir el ancho de banda entre clientes. Cada cliente ocupa un intervalo de tiempo en un Round-Robin.
El RTP además provee transporte para direcciones unicast y multicast. Por esta razón, también se encuentra involucrado el protocolo IGMP para administrar el servicio multicast. El paquete de RTP incluyen un encabezado fijo y el payload de datos; RTCP utiliza el encabeza del RTP y ocupa el campo de carga útil.No es lo suficientemente confiable por si solo, este proporciona "ganchos" con protocolos y aplicaciones de capas inferiores y recursos proporcionados por los switches y enrutador para garantizar confiabilidad.
Los paquetes RTP no contienen campo de longitud, ya que al funcionar sobre UDP, este protocolo es quien encapsula la voz comprimida en datagramas. Para la compresión RTP usa una aplicación llamada "vocoder" pudiendo reducir de 64 kbps hasta a 8 kbps la rata para digitalización y compresión de voz produciendo un desmejoramiento en la calidad de la voz poco perceptible, además de esto usa h.323 g.729 y otros protocolos más para transmisiones en tiempo real. RTP es capaz de correr sobre protocolos WAN de alta velocidad como ATM sin ningún problema, también en redes asimétricas como ADSL, cable-modem o por enlace satelital pero cumpliendo con ciertas características de ancho de banda para ambas direcciones y uso exclusivo para la aplicación RTP. Las herramientas de las que se vale RTP para lograr transmisiones en tiempo real son el RTCP, que proporciona un feedback a cerca de la calidad de distribución y la congestión, con esto, la empresa que ofrece el servicio puede monitorear la calidad y puede diagnosticar los problemas que pueda presentar la red.
4.1-CARACTERISTICAS GENERALES DEL PROTOCOLO ( RTP).
4.2.- FUNCIONES DEL PROTOCOLO ( RTP ). • Entre sus funciones se encuentran: la memorización de datos, la simulación de distribución interactiva, el control y mediciones de aplicaciones.
• La funcionalidad ToS (Tipo de Servicio) en IP puede determinar un ancho de banda específico para el cliente. Un servicio sensible al retardo requiere un ancho de banda superior. En IP además del ToS se puede utilizar la dirección de origen y destino IP, tipo de protocolo y número de socket para asignar una ponderación. En redes que disponen de switch de capa 2 se requiere extender la gestión de la calidad de servicio a dicha capa. Para ello la IEEE ha determinado el ToS sobre IEEE-802.
4.3. DIAGRAMA DEL PAQUETE DE TRANSPORTE RTP.
P = Padding , X = Extenciones tras CSRC(0), CC = CSRC Count(0) M = Marcador (SID Support), Nª Sec = Comienza en nª aleatorios Timestamp = Tick count tras la emisiòn del 1er paquete. 1tick =1/8000 SSRC = Origen del medio. Mismo origen, mismo tiempo y nuecero de secuencias.
4.4. PROTOCOLO RTCP (REAL-TIME CONTROL PROTOCOL). Se basa en la periódica transmisión de los paquetes de control a todos los participantes en sesión, utilizando el mismo mecanismo de distribución como dato paquete. El protocolo subyacente debe proveer de la multiplexación de los datos y de los paquetes del control.
4.5. CARACTERISTICAS GENERALES DEL PROTOCOLO ( RTCP). • Es una herramientas de las que se vale RTP para lograr transmisiones en tiempo real, que proporciona un feedback a cerca de la calidad de distribución y la congestión.
• RTCP sincroniza el audio y el video, conoce el número de usuarios presentes en una conferencia y con esto calcula la rata a la cual deben ser enviados los paquetes.
• Este protocolo permite completar a RTP facilitando la comunicación entre extremos para intercambiar datos y monitorear de esta forma la calidad de servicio y obtener información acerca de los participantes en la sesión. RTCP se fundamenta en la transmisión periódica de paquetes de control a todos los participantes en la sesión usando el mismo mecanismo de RTP de distribución de paquetes de datos. El protocolo UDP dispone de distintas puertas (UDP Port) como mecanismo de identificación de protocolos.
• La función primordial de RTCP es la de proveer una realimentación de la calidad de servicio. Se relaciona con el control de congestión y flujo de datos. El RTCP involucra varios tipos de mensajes, por ejemplo:
-Send report para emisión y recepción de estadísticas (en tiempo random) desde emisores activos. es uno de los más interesantes, disponen de 3 secciones bien diferenciadas:
1. Los primeros 8 Bytes se refieren a un encabezado común.
2. La segunda parte de 20 Bytes permite la evaluación de diferentes parámetros (retardo, jitter, eficiencia de datos, etc).
3. La tercera parte de 24 Bytes lleva reportes que han sido obtenidos desde el último reporte informado. Incluye los siguientes reportes: cantidad total de paquetes RTP perdidos y a la proporción de los mismos; la cantidad de paquetes recibidos y el jitter entre paquetes; el horario del último paquete recibido y el retardo de transmisión del mismo.
-Receiver Report para recepción estadísticas desde emisores no activos.
-Source Description para un identificador de nivel de transporte denominado CNAME (Canonical Name).
-Bye para indicar el final de la participación en la conexión.
-Application para aplicaciones específicas.
4.6. DIAGRAMA DEL PAQUETE DE TRANSPORTE RTCP. – PIMER CUERPO: • RC = Report Count PT: Carga util = 200 para SR.
• Longitud del reporte SSRC: que lo origina.
-SEGUNDO CUERPO: • NTP timestamp: segundos desde el 1/1/1900. entero y decimal.
• Instante de tiempo en que se envia el reporte (32 +32 ).
• RTP timestamp: el mismo enstante en ticks de RTP (equivalencia.
• Paquetes y octetos enviados desde el inicio de la sesiòn por (SSRC).
-TERCER CUERPO: • Conjunto de RR, uno por cada fuente escuchada.
4.7. DIAGRAMA DE PAQUETE COMPLETO DE TRANSPORTE. Los destinatarios de los paquetes RTP devuelven información sobre de la calidad de recepción, utilizando diferentes formas de paquetes RTCP, según si ellos mismos son emisores de contenido o no. Los dos tipos, SR y RR, contienen ninguno, uno o varios bloques de informe de receptor, previstos para la sincronización de las fuentes de las cuales el receptor ha recibido un paquete de contenido RTP desde el último informe. La evaluación de la calidad de recepción no es sólo útil para el emisor, sino también para el receptor y cualquier supervisor de red que pudiera existir. El emisor puede modificar su transmisión de acuerdo con la información recibida; el receptor puede inferir si las dificultades de recepción que observa son de origen local, regional o más amplio. El supervisor recibirá solamente los paquetes RTCP, con lo cual podrá evaluar la calidad de funcionamiento de la red.
La investigación sobre VoIP, nos permite ajustarnos de una forma más segura y sencilla al incremento del tráfico que vaya surgiendo como producto de las nuevas migraciones que se hagan hacia la plataforma de VoIP.
La rentabilidad en la utilización de soluciones IP se basa en el desarrollo de nuevos servicios, VoIP significa rapidez en la instalación si se compara con una red similar usando tecnología de circuitos conmutados.
Está claro que el escenario actual seguirá evolucionando hacia la convergencia tecnológica efectiva: la tendencia es ir a un escenario final donde dispondremos de una red de multiservicios que integre todo tipo de contenidos (voz, vídeo y datos) y que nos permita entregarlos de forma personalizada a cualquier tipo de usuario, en cualquier tipo de terminal, con la calidad requerida e independientemente de la ubicación de aquél.
En el estado actual de esta evolución, la tecnología adecuada parece ser la VoIP como soporte del servicio de Telefonía IP (TIP); y como primera propuesta para disponer de un mecanismo de señalización y control para las necesidades que plantea el servicio de TIP, se ha desarrollado la recomendación H.323 de la ITU-T, y todos los protocolos asociados que han surgido del mundo tradicional.
Sin embargo, parece que ante un escenario basado en redes y servicios IP, ha ganado muchos puntos la sencillez, flexibilidad y robustez de SIP; y se perfila como la apuesta clara de futuro (que por otra parte se veía venir como contrapartida desde el mundo de Internet ante las iniciativas del mundo institucional).
Evidentemente, a nadie se escapa que, inmersos como estamos en un esfuerzo de integración y convivencia entre tecnologías, que parten de planteamientos, en principio divergentes, no debemos buscar soluciones excluyentes; de manera que no hay que olvidarse de iniciativas como la de MGCP, o esfuerzos dirigidos a buscar mecanismos de interoperabilidad como el proyecto TIPHON de la ETSI.
Si tenemos que quedarnos con una idea, debe ser la siguiente. Ante la creciente demanda de servicios de multiconferencia multimedia en tiempo real, con funcionalidades de colaboración, parece que son los desarrollos ligados a SIP los que dan una respuesta más satisfactoria a los retos que presenta la implementación de tales servicios. Además en un mundo IP, con la Web como canal de comunicación por defecto, y una oferta cada vez mayor de tecnologías de acceso y soluciones de movilidad, tiene sentido apostar decididamente por SIP.
Se puede concluir diciendo que VoIP es una tecnología que tiene todos los elementos para su rápido desarrollo. Como muestra se puede ver que compañías como Cisco, la han incorporado a su catálogo de productos, los teléfonos IP están ya disponibles y los principales operadores mundiales, así como Telefónica, están promoviendo activamente el servicio IP a las empresas, ofreciendo calidad de voz a través del mismo. Por otro lado se tiene ya un estándar que nos garantiza interoperabilidad entre los distintos fabricantes.
Después de haber realizado el estudio de la integración de IP sobre redes ópticas vemos que nos ha proporcionado una descripción de diversos protocolos y soluciones hardware para los paquetes IP de transporte sobre una red WDM/DWDM.
La mejor opción para IP sobre WDM/DWDM en las futuras redes. Se ha visto que se precisan algunos cambios en las configuraciones del hardware para hacer los routers capaces de manejar los paquetes a velocidades de Gigabit, así como el uso de switch fabricados en vez de buses. También se ve que el uso de MPLS es el relevo a la carga de las largas tablas de búsqueda en los routers, y además realiza las funcionalidades de la red.
El trabajo ha mostrado algunas de las posibilidades de las cuales WDM puede dar en términos de funcionalidad. La posibilidad de conexión cruzada y enrutar los flujos IP con la ayuda de las longitudes de onda y de tal modo de conseguir una menor laténcia en la red. Por otra parte se ve las diversas formas de realizar la protección de la conmutación de la longitud de onda y cómo esto se compara en términos de velocidad con la redundancia en los interfaces de los routers.
Las tendencias que prevalecen en IP sobre WDM son interfaces de routers más rápidos, incremento del número de las longitudes de onda, el movimiento del enrutamiento a las capas más bajas, los nuevos protocolos adaptados a IP sobre WDM y protocolos menores de conversión entre las particiones de la red. En el resumen, estas tendencias representan la conducción de las fuerzas detrás del movimiento de hacer las redes más simples y más rentables usando IP sobre WDM.
Considerando los costes de gestión de hoy en día, las soluciones de gestión integrada para entregar servicios extremos a extremo eficientemente en un ambiente de múltiples capas heterogéneos de la red constituyen un factor dominante para la introducción de las nuevas arquitecturas de red, tecnologías, y servicios.
CANTV, VoIP. Informe 2001 o CANTV, Plan inicial de Evaluación de VoIP. 2001 http://www.cesga.es/ga/default.html?Recetga/Proxrecet.html&2 o http://www.monografias.com/trabajos3/voip/voip o http://www.hi-teck.com/ip_telephony/benef_home.jsp o http://www.comtest.com/tutorials/VoIP.html o http://intranet.upb.edu/laboISTEC/Articulos/Articulo%20VoIP%20_eng.pdf o http://www.pt.com/tutorials/iptelephony/tutorial_voip_signaling.html o http://www.networkcomputing.com/netdesign/1109voip.html o http://www.protocols.com/voip/architecture.htm o http://www.comunicaciones.unitronics.es/tecnologia/H.323.html#Gatekeeper o http://www.comunicaciones.unitronics.es/tecnologia/voip.htm o http://www.aui.es/biblio/libros/mi99/19voz_ip.htm o http://www.avaya.es/Informacion_de_la_empresa/Sala_de_Prensa/Notas_d e_Prensa/prensa30.asp o http://www.recursosvoip.com/protocolos/megaco.php o http://www.commworks.com/Spanish/Softswitch/Softswitch_Components/Se ssion_Agents/H.323_SIP/ o http://neutron.ing.ucv.ve/revista/e/No7/Russomanno%5Cvoz%20sobre%20I P.html o http://www.protocols.com/pbook/VoIP.htm#MGCP o http://www.monografias.com/trabajos11/descripip/descripip o http://www.protocols.com/voip/testing.htm o http://www.aui.es/biblio/libros/mi99/19voz_ip.htm o http://www.gbm.net/bluetech/Edicion14.4/telefoniaip o http://eia.udg.es/~atm/tcp-ip/tema_4_6_1.htm
Concepto de IP en las nuevas redes Integradas.
UNIVERSIDAD CENTRAL DE VENEZUELA FACULTAD DE INGENIERIA ELECTRICA S.C.A.D.A.(ESPECIALIZACION) Sistemas de telecomunicaciones Caracas, Marzo 2006.
Autor:
Ing. Cardozo F. Joel.
C.I.: 6.682.161
| Página siguiente |