Resolución de problemas de voz irregular de QoS

Introducción

Para que los paquetes de voz sean un reemplazo realista para los servicios de telefonía de red telefónica conmutada pública (RTCP), la calidad de recepción de los paquetes de voz debe ser comparable a la de los servicios básicos de telefonía. Esto significa transmisiones de voz de alta calidad de manera consistente. Como otras aplicaciones en tiempo real, los paquetes de voz tienen un ancho de banda amplio y son sensibles al retardo. Para que las transmisiones de voz sean inteligibles (no se entrecorten) para el receptor, los paquetes de voz no se pueden perder, retardarse mucho ni sufrir retardos variables (conocidos también como fluctuaciones). Este documento describe varias consideraciones de calidad de servicio (QoS) que ayudan a solucionar los problemas de voz entrecortada. Los motivos principales de problemas de voz entrecortada son los paquetes perdidos o demorados.

Prerequisites

Requirements

Los lectores de este documento deben tener conocimiento de lo siguiente:

• Configuración básica de Voz de Paquetes (VoIP, Voz sobre Frame Relay (VoFR) o Voz sobre ATM (VoATM) según sus requisitos).

• Comprensión básica de priorización de voz, fragmentación, diferentes códecs y sus requerimientos de ancho de banda.

Componentes Utilizados

La información de este documento se aplica a todas las versiones de software y hardware de gateways de voz de Cisco.

La información que se presenta en este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. All of the devices used in this document started with a cleared (default) configuration. Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Convenciones

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Causas de la voz irregular

La calidad de voz entrecortada la causan los paquetes de voz que están retrasados de diversas formas o perdidos en la red. Cuando un paquete de voz se retrasa al alcanzar su destino, la gateway de destino sufre una pérdida de información de tiempo real, En este caso, el gateway de destino debe predecir cuál puede ser el contenido del paquete perdido. La predicción lleva a que la voz recibida no tenga las mismas características que la voz transmitida. Esto lleva a una voz recibida que suena robótica. Si un paquete de voz se demora más allá de la capacidad de predicción de una gateway de recepción, esta última deja vacío el intervalo de tiempo real. Al no tener nada que llenar ese vacío en el extremo receptor, parte del discurso transmitido se pierde. Esto da como resultado una voz entrecortada. Muchos de los problemas de voz entrecortada se resuelven asegurándose de que los paquetes de voz no se retrasan mucho (y más que eso, no se retrasan de forma variable). A veces, la detección de actividad de voz (VAD) añade recorte de extremo frontal a una conversación de voz. Esta es otra causa de voz entrecortada (o recortada).

Las diversas secciones de este documento muestran cómo minimizar la instancia de voz entrecortada. La mayoría de estas medidas requieren la garantía de la introducción de fluctuación mínima en la red de voz.

Requisito de ancho de banda

Antes de considerar la posibilidad de aplicar medidas para minimizar la fluctuación, proporcione un ancho de banda de red suficiente para admitir el tráfico de voz en tiempo real. Por ejemplo, una llamada VoIP G.711 de 80 kbps (carga útil de 64 kbps + encabezado de 16 kbps) suena mal en un enlace de 64 kbps porque se descartan al menos 16 kbps de los paquetes (que es del 20%). Los requisitos de ancho de banda varían según el códec utilizado para la compresión. Códecs diferentes tienen cargas útiles y requisitos de encabezamiento diferentes. El uso de VAD también afecta el requisito de ancho de banda. Si se utiliza la compresión de encabezado (cRTP) del protocolo en tiempo real (RTP), puede reducir aún más el requisito de ancho de banda.

Por ejemplo, el ancho de banda requerido para una llamada de voz utilizando el códec G.729 (carga útil predeterminada de 20 bytes) con cRTP es el siguiente:

• Carga útil de voz + comprimido (encabezado RTP + encabezado UDP (protocolo de datagramas de usuario) + encabezado IP) + encabezado de capa 2

Esto equivale a:

• 20 bytes + comprimidos (12 bytes + 8 bytes + 20 bytes) + 4 bytes

Esto equivale a:

• 28 bytes, ya que la compresión del encabezado reduce el encabezado IP RTP a un máximo de 4 bytes. Esto produce un resultado de 11.2 kbps a una velocidad de códec de 8 kbps (50 paquetes por segundo).

Para obtener más información, consulte Voz sobre IP – Consumo de ancho de banda por llamada.

Prioridad del tráfico de voz

Hay dos componentes importantes para priorizar la voz. La primera es clasificar y marcar el tráfico de voz interesante. La segunda es priorizar el marcado tráfico de voz interesante. Las dos subsecciones aquí analizan diversos enfoques para clasificar, marcar y priorizar la voz.

Clasificación y marcado

Para garantizar el ancho de banda para los paquetes VoIP, un dispositivo de red debe ser capaz de identificar los paquetes en todo el tráfico IP que fluye a través de él. Los dispositivos de red usan la dirección IP de origen y destino en el encabezado IP o los números de puerto UDP de origen y destino en el encabezado UDP para identificar los paquetes VoIP. Este proceso de identificación y agrupación se denomina clasificación. Es la base para proporcionar cualquier QoS.

La clasificación de paquetes puede requerir un uso intensivo del procesador. Por lo tanto, la clasificación debe hacerse lo más lejos posible hacia el perímetro de la red. Como cada salto todavía necesita tomar una determinación sobre el tratamiento que debe recibir cada paquete, debe tener un método de clasificación más simple y eficaz en el núcleo de la red. Esta clasificación más simple se logra mediante el marcado o configuración del byte de Tipo de servicio (ToS) en el encabezado de la IP. Los tres bits más significativos del byte ToS se denominan bits de precedencia IP. La mayoría de las aplicaciones y de los proveedores soportan actualmente la configuración y el reconocimiento de estos tres bits. El marcado se lleva a cabo para que los seis bits más significativos del byte ToS, llamados Differentiated Services Code Point (DSCP), puedan usarse. Consulte la Solicitud de comentarios (RFC):

Servicios diferenciados (DiffServ) es un nuevo modelo en el que el tráfico es tratado por sistemas intermedios con prioridades relativas basadas en el campo ToS. Definido en RFC 2474 y RFC 2475 , el estándar DiffServ reemplaza la especificación original para definir la prioridad del paquete descrita en RFC 791. DiffServ aumenta el número de niveles de prioridad definibles al reasignar los bits de un paquete de IP para que se les haga una marcación prioritaria. La arquitectura DiffServ define el campo DiffServ. Sustituye al byte ToS en IP V4 para tomar decisiones de comportamiento por salto (PHB) sobre la clasificación de paquetes y las funciones de condicionamiento del tráfico, como la medición, el marcado, el modelado y la regulación. Además de los RFC mencionados anteriormente, RFC 2597 define las clases Assured Forwarding (AF). Este es un desglose de los campos DSCP. Para obtener más información sobre DSCP, consulte Implementación de políticas de calidad de servicio con DSCP.

Byte ToS - P2 P1 P0 T3 T2 T1 T0 CU

Precedencia de IP: tres bits (P2-P0), ToS (Tipo de Servicio): cuatro bits (T3-T0), CU: un bit

Campo DiffServ - DS5 DS4 DS3 DS2 DS1 DS0 ECN ECN

DSCP: seis bits (DS5-DS0), ECN: dos bits

XXX00000 bits 0, 1, 2 (DS5, DS4, DS3) son bits de precedencia, donde:

• 111 = Control de red = Precedencia 7

• 110 = Control entre redes = Precedencia 6

• 101 = CRÍTICO/ECP = Precedencia 5

• 100 = Sustitución de Flash = Precedencia 4

• 011 = Flash = Precedencia 3

• 010 = Inmediato = Precedencia 2

• 001 = Prioridad = Precedencia 1

• 000 = Rutina = Precedencia 0

000XXX00 Bits 3, 4, 5 (DS2, DS1, DS0) son bits de retardo, rendimiento y confiabilidad.

• Bit 3 = Retraso [D] (0 = Normal; 1 = Baja)

• Bit 4 = Rendimiento [T] (0 = Normal; 1 = alto)

• Bit 5 = Fiabilidad [R] (0 = Normal; 1 = alto)

00000XX Bits 6, 7: ECN

En estas dos secciones se examinan dos formas de clasificar y marcar.

Pares de marcación de voz para clasificar los paquetes marcados

Con los gateways VoIP de Cisco, normalmente utiliza pares de marcado de voz para clasificar los paquetes VoIP y marcar los bits de precedencia IP. Esta configuración muestra cómo marcar los bits de precedencia IP:

dial-peer voice 100 voip
destination-pattern 100
session target ipv4:10.10.10.2
ip precedence 5

En el ejemplo anterior, cualquier llamada VoIP que coincida con el comando dial-peer voice 100 voip tiene todos sus paquetes de carga útil de voz configurados con IP Precedence 5. Esto significa que los tres bits más significativos del byte ToS de IP están configurados en 101.

dial-peer voice 100 voip
destination-pattern 100
session target ipv4:10.10.10.2
ip qos dscp ef media
ip qos dscp af31 signaling

En el ejemplo anterior, cualquier llamada VoIP que coincida con el comando dial-peer voice 100 voip tiene todos sus paquetes de carga útil de medios (paquetes de voz) configurados con el patrón de bits 101110 de Reenvío acelerado (EF). Todos los paquetes de señalización se configuran con el patrón de bits AF 011010.

Nota: El comando ip qos dscp se soporta desde la versión 12.2(2)T del software Cisco IOS®. La precedencia IP ya no está disponible en la versión 12.2T del software del IOS de Cisco. Sin embargo, se logra lo mismo con el comando ip qos dscp. La precedencia IP 5 (101) se asigna al IP DSCP 101000. Para más información consulte Clasificación de señalización de VoIP y medios con DSCP para QoS.

Modular QoS CLI para clasificar y marcar paquetes

La clasificación recomendada y el método de marcado para utilizar es la CLI de QoS modular. Este es un método de configuración basado en plantillas que separa la clasificación de la política. Esto permite configurar varias funciones de QoS juntas para varias clases. Utilice un comando class-map para clasificar el tráfico basado en varios criterios de coincidencia y un comando policy-map para determinar qué debe suceder con cada clase. Aplique la política al tráfico entrante o saliente en una interfaz ejecutando el comando service-policy. Este ejemplo de configuración muestra cómo utilizar la CLI de QoS modular para clasificar y marcar los paquetes:

access-list 100 permit udp any any range 16384 32767
access-list 101 permit tcp any any eq 1720
!
class-map match-all voip
match access-group 100
class-map match-all control
match access-group 101
!
policy-map mqc
class voip
set ip precedence 5
class control
set ip precedence 5
class class-default
set ip precedence 0
!
interface Ethernet0/0
service-policy input mqc

En este ejemplo de configuración, cualquier tráfico que coincida con la lista de control de acceso (ACL) 100 se clasifica como "clase voip" y se establece con la precedencia IP 5. Esto significa que los tres bits más significativos del byte ToS de IP están configurados en 101. ACL 100 coincide con los puertos UDP comunes utilizados por VoIP. De forma similar, la ACL 101 coincide con el tráfico de señalización H.323 (puerto TCP 1720 del protocolo de control de transmisión). El resto del tráfico se configura con la precedencia IP 0. La política se llama "mqc". Se aplica al tráfico entrante en Ethernet 0/0.

Establecimiento de prioridad

Después de que cada salto en la red sea capaz de clasificar e identificar los paquetes VoIP (ya sea a través de la información de puerto/dirección o a través del byte ToS), esos saltos luego proporcionan a cada paquete VoIP la QoS requerida. En ese momento, configure técnicas especiales para proporcionar colas de prioridad para asegurarse de que los paquetes de datos grandes no interfieran con la transmisión de datos de voz. Esto suele ser necesario en links WAN más lentos donde existe una alta posibilidad de congestión. Una vez que todo el tráfico interesante se coloca en clases de QoS en función de sus requisitos de QoS, proporcione garantías de ancho de banda y servicio de prioridad a través de un mecanismo de cola de salida inteligente. Se requiere una cola de prioridad para VoIP.

Nota: Utilice cualquier mecanismo de colocación en cola que dé de forma efectiva alta prioridad a VoIP. Sin embargo, se recomienda la cola de baja latencia (LLQ) porque es flexible y fácil de configurar.

LLQ utiliza el método de configuración modular QoS CLI para proporcionar prioridad a ciertas clases y para proporcionar un ancho de banda mínimo garantizado para otras clases. Durante los períodos de congestión, la cola de prioridad se controla a la velocidad configurada para que el tráfico de prioridad no utilice todo el ancho de banda disponible. (Si el tráfico prioritario monopoliza el ancho de banda, evita que se cumplan las garantías de ancho de banda para otras clases). Si aprovisiona LLQ correctamente, el tráfico que entra en la cola de prioridad nunca debe exceder la velocidad configurada.

LLQ también permite que se especifiquen las profundidades de cola para determinar cuándo el router necesita descartar paquetes si hay demasiados paquetes que esperan en cualquier cola de clase determinada. También hay un comando class-default que se utiliza para determinar el tratamiento de todo el tráfico no clasificado por una clase configurada. La clase predeterminada se configura con un comando fair-queue. Esto significa que a cada flujo no clasificado se le da un porcentaje aproximadamente igual del ancho de banda restante.

Este ejemplo muestra cómo configurar LLQ. Para obtener más información, consulte Colocación en cola de latencia baja:

access-list 100 permit udp any any range 16384 32000
access-list 101 permit tcp any any eq 1720
access-list 102 permit tcp any any eq 80
access-list 103 permit tcp any any eq 23
!
class-map match-all voip
match access-group 100
class-map match-all voip-control
natch access-group 101
class-map match-all data1
match access-group 102
class-map match-all data2
match access-group 103
!
policy-map llq
class voip
priority 32
class voip-control
bandwidth 8
class data1
bandwidth 64
class data2
bandwidth 32
class class-default
fair-queue
!
interface Serial1/0
bandwidth 256
service-policy output llq

En este ejemplo, cualquier tráfico que coincida con ACL 100 se clasifica como "class voip" (que significa tráfico de voz). Se le da una prioridad alta de hasta 32 kbps. ACL 100 coincide con los puertos UDP comunes utilizados por VoIP. La lista de acceso 101 coincide con el tráfico de señalización H.323 (puerto TCP 1720). La clase data1 coincide con el tráfico web (puerto TCP 80 como se ve en la lista de acceso 102) y garantiza 64 kbps. Class data2 coincide con el tráfico Telnet (puerto TCP 23 tal como se ve en ACL 103) y garantiza 32 kbps. La clase predeterminada se configura para conceder la misma porción del ancho de banda restante a los flujos no clasificados. La política se llama "llq". Se aplica al tráfico saliente en Serial1/0, que tiene un ancho de banda total de 256 kbps.

Nota: De forma predeterminada, el ancho de banda total garantizado y el ancho de banda de prioridad para todas las clases deben ser inferiores al 75 por ciento del ancho de banda de la interfaz. Modifique este porcentaje ejecutando el comando max-reserved bandwidth interface.

Esta tabla compara diferentes mecanismos de colocación en cola de software con sus respectivas ventajas y limitaciones.

Mecanismo de cola de software	Descripción	Beneficios	Limitaciones
Primero en entrar, primero en salir (FIFO)	Los paquetes llegan y dejan la cola en exactamente el mismo orden.	Configuración simple y rápida operación.	No es posible el servicio de prioridad ni las garantías de ancho de banda.1
Weighted Fair Queueing (WFQ)	Algoritmo de hash que fluye en colas separadas donde se utilizan pesos para determinar cuántos paquetes se atienden a la vez. Para definir los pesos, establezca los valores de precedencia IP y DSCP.	Configuración simple Predeterminada en links de menos de 2 Mbps	No es posible el servicio de prioridad ni las garantías de ancho de banda.1
Cola personalizada (CQ)	El tráfico se clasifica en colas múltiples con límites de cola configurables. Los límites de cola se calculan en función del tamaño medio del paquete, la unidad máxima de transmisión (MTU) y el porcentaje de ancho de banda que se va a asignar. Los límites de cola (en número de bytes) se quitan de la cola para cada cola. Por lo tanto, proporciona el ancho de banda asignado estadísticamente.	Ha estado disponible durante algunos años. Permite la asignación aproximada de ancho de banda para diferentes colas.	No es posible prestar servicios de prioridad. Las garantías de ancho de banda son aproximadas. Hay un número limitado de colas. La configuración es relativamente difícil.1
Cola prioritaria (PQ)	El tráfico se clasifica en colas de prioridad alta, media, normal y baja. Primero se atiende el tráfico de alta prioridad, seguido por el tráfico de prioridad media, normal y baja.	Ha estado disponible durante algunos años. Proporciona servicios prioritarios.	El tráfico de mayor prioridad deja de tener las colas de menor prioridad de ancho de banda. No es posible garantizar el ancho de banda.2
Class-Based Weighted Fair Queuing (CBWFQ)	Modular QoS CLI se usa para clasificar el tráfico. El tráfico clasificado se coloca en colas de ancho de banda reservado o en una cola predeterminada no reservada. Un planificador atiende las colas teniendo en cuenta los pesos, de esta manera se cumplen las garantías del ancho de banda	Similar a LLQ, a excepción de que no hay una cola prioritaria. Configuración simple y capacidad de proporcionar garantías de ancho de banda.	No es posible prestar servicios prioritarios.3
Priority Queue Weighted Fair Queuing (PQ-WFQ), también denominada IP RTP Priority	Un comando de interfaz única se utiliza para proporcionar servicio prioritario a todos los paquetes UDP destinados a números de puerto iguales dentro de un rango especificado.	Configuración de un comando, simple Proporciona servicio prioritario a paquetes RTP.	El resto del tráfico se trata con WFQ. No se prioriza el tráfico de Protocolo de conferencia en tiempo real (RTCP). No se garantiza la capacidad de ancho de banda 4
LLQ, anteriormente conocido como Class-Based Weighted Fair Queueing (PQCBWFQ)	La CLI de QoS modular con cola de prioridad se utiliza para clasificar el tráfico. El tráfico clasificado se coloca en una cola de prioridad, colas de ancho de banda reservado o en una cola no reservada predeterminada. Un planificador se ocupa de las colas basándose en el peso para que el tráfico de prioridad sea enviado primero (hasta un cierto límite regulado durante la congestión) y para que se cumplan las garantías del ancho de banda.	Configuración simple Capacidad de otorgar prioridad a distintas clases de tráfico y ofrece más límites sobre la utilización del ancho de banda prioritario. También puede configurar clases garantizadas de ancho de banda y una clase predeterminada.	Ningún mecanismo para proporcionar varios niveles de prioridad todavía, todo el tráfico de prioridad se envía a través de la misma cola de prioridad. Las clases de prioridad separadas pueden tener límites de ancho de banda de prioridad superior separados durante la congestión. Sin embargo, el uso compartido de la cola de prioridad entre las aplicaciones puede potencialmente introducir fluctuación.4

1. No es adecuado para voz.

2. Necesita ancho de banda garantizado para voz.

3. Necesita que se cuide la latencia.

4. Suficiente para la voz.

Demora de serialización

Incluso si la colocación en cola funciona en su mejor momento y da prioridad al tráfico de voz, hay momentos en que la cola de prioridad está vacía y se atiende un paquete de otra clase. Los paquetes de las clases de ancho de banda garantizadas deben ser atendidos según su peso configurado. Si un paquete de voz prioritario llega a la cola de salida mientras se atienden estos paquetes, el paquete de voz puede esperar una cantidad significativa de tiempo antes de ser enviado. Los paquetes de voz experimentan demora en la serialización cuando deben aguardar detrás de paquetes de datos más grandes.

La demora de serialización puede introducir la peor forma de fluctuación para los paquetes de voz. Si los paquetes de voz tienen que esperar detrás de un paquete de datos de hasta 1500 bytes, en un link más lento, esto se traduce en un enorme retraso. La demora de serialización es muy diferente si el paquete de datos es de 80 bytes, como se muestra en este ejemplo:

• Retraso de serialización en un link de 64 kbps debido a un paquete de 1500 bytes = 1500*8/64000 = 187,5 ms.

• Retraso de serialización en un link de 64 kbps debido a un paquete de 80 bytes = 80*8/64000 = 10 ms.

Por lo tanto, un paquete de voz potencialmente debe esperar hasta 187.5 ms antes de ser enviado si se atasca detrás de un solo paquete de 1500 bytes en un link de 64 kbps. Por otra parte, otro paquete de voz debe esperar sólo 10 ms en el gateway de destino. Esto resulta en una gran fluctuación que se produce como consecuencia de la variación del retraso entre los paquetes. En el gateway de origen, los paquetes de voz se envían normalmente cada 20 ms. Con un presupuesto de demora de extremo a extremo de 150 ms y con requerimientos de fluctuaciones estrictos, es inaceptable una brecha de 180 ms.

Introducir un mecanismo de fragmentación que asegure que el tamaño de una unidad de transmisión sea inferior a 10 ms. Todos los paquetes que tienen un retraso de serialización de más de 10 ms deben fragmentarse en fragmentos de 10 ms. Un fragmento o fragmento de 10 ms es el número de bytes que se envía sobre el link en 10 ms. Calcule el tamaño utilizando la velocidad del link, como se muestra en este ejemplo:

• Tamaño de fragmentación = (0.01 segundos * 64,000 bps) / (8 bits/byte) = 80 bytes

Lleva 10 ms enviar un paquete o fragmento de 80 bytes por un link de 64 kbps.

En caso de varias ATM o Circuitos virtuales permanentes Frame Relay (PVC) en una interfaz sola física, configure los valores de fragmentación (en todos los PVC) basados en el PVC que tenga disponible el menor ancho de banda. Por ejemplo, si hay tres PVC que tienen un ancho de banda garantizado de 512 kbps, 128 kbps y 256 kbps, configure los tres PVC con un tamaño de fragmento de 160 bytes (la velocidad más baja es 128 kbps que requiere un tamaño de fragmento de 160 bytes). Estos valores se recomiendan para diferentes velocidades de link:

Link Speed (kbps)         Fragmentation Size (bytes) 
56                                  70 
64                                  80 
128                                 160 
256                                 320 
512                                 640 
768                                 960 
1024                                1280 
1536                                1920

Nota: No se requiere fragmentación si el tamaño del fragmento es mayor que el tamaño de MTU del link. Por ejemplo, para un link T1 con una MTU de 1500 bytes, el tamaño del fragmento es de 1920 bytes. Por lo tanto, no se requiere fragmentación. El tamaño de fragmentación de paquetes nunca debe ser menor que el tamaño del paquete VoIP. No fragmente los paquetes VoIP. La fragmentación de estos paquetes ocasiona muchos problemas de calidad y configuración de las llamadas.

Actualmente hay disponibles tres mecanismos de fragmentación y entrelazado de enlaces. Para obtener más detalles acerca de los distintos retardos introducidos en una red de paquetes, consulte Introducción al Retardo en redes de voz en paquetes. En esta tabla se enumeran sus ventajas y limitaciones:

Mecanismo de fragmentación y entrelazado de enlaces (LFI)	Descripción	Beneficios	Limitaciones
Fragmentación de MTU con WFQ	Comando de nivel de interfaz para cambiar el tamaño de MTU o el tamaño de MTU de IP. Utilizado para fragmentar paquetes IP grandes a un tamaño MTU especificado. LFI usa WFQ para entrelazar paquetes en tiempo real entre los fragmentos.	Configuración simple	Los fragmentos se vuelven a ensamblar sólo mediante la aplicación receptora. Por lo tanto, el uso ineficiente de la red. Sólo los paquetes IP con el bit Do not Fragment (DF) no configurado pueden gestionar bien la fragmentación. Gran uso del procesador. No recomendado.
Multilink Point-to-Point Protocol (MLPPP) LFI	En los links seriales punto a punto, se debe configurar MLPPP primero, luego se debe establecer un tamaño de fragmentación en ms. También se debe habilitar el entrelazado en la interfaz de links múltiples.	Se fragmentan los paquetes en un extremo del link y se vuelven a ensamblar en el otro. Es posible combinar varios links para que funcionen como un gran conducto virtual.	Únicamente disponible en links configurados para PPP. Las soluciones para PPP sobre Frame Relay o PPP sobre ATM también se soportan en Cisco IOS Software Release 12.1(5)T o posterior.
Fragmentación de Frame Relay (FRF.12)	En los PVC de Frame Relay, el comando frame-relay traffic-shaping debe ser habilitado y el tamaño de la fragmentación establecido en la clase de asociador.	Se fragmentan los paquetes en un extremo del PCV y se vuelven a ensamblar al otro.	Sólo disponible en PVC de Frame Relay con el comando frame-relay traffic-shaping activo.

VAD

Una conversación de voz común incluye varios momentos de silencio. Una conversación de voz típica consiste en un silencio del 40% al 50%. Dado que no se transmite ninguna voz a través de la red durante el 40 por ciento de una llamada de voz, se puede ahorrar parte del ancho de banda mediante la implementación de VAD. Con VAD, la puerta de enlace busca lagunas de voz. Sustituye esos huecos por el ruido de fondo (ruido de fondo). Por lo tanto, se ahorra una cantidad de ancho de banda. Sin embargo, es un equilibrio. Hay un poco de tiempo (en orden de milisegundos), antes de que los códecs detecten actividad de voz seguido de un período de silencio. Este breve tiempo produce el recorte por parte del procesador frontal de la voz recibida. Para evitar la activación durante pausas muy cortas y compensar el recorte, VAD espera aproximadamente 200 ms después de que el discurso se detiene antes de que se detenga la transmisión. Al reiniciar la transmisión, incluye los 5 ms de voz anteriores junto con la actual. VAD se inhabilita automáticamente durante una llamada si el ruido del ambiente no le permite diferenciar entre la voz y el ruido de fondo. Sin embargo, si el ancho de banda no es un problema, apague el VAD.

Parámetros VAD para la puesta a punto

Hay dos parámetros que dictan el funcionamiento del VAD. Estos son los comandos music-threshold y voice vad-time.

music-threshold

Se decide un umbral inicial que rige cuando VAD necesita activarse. Esto se controla mediante la definición del comando music-threshold threshold_value en un puerto de voz, como se muestra en este ejemplo. El rango para esto es de -70 decibeles por milivatio (dBm) a -30 dBm. El valor predeterminado para esto es -38 dBm. La configuración de un valor inferior (hacia -70 dBm) hace que VAD se vuelva activo con una fuerza de señal mucho más baja (el volumen debe disminuir en gran medida para ser considerado silencio). La configuración de un valor más alto (cerca de -30 dBm) hace que VAD se vuelva activo incluso para una pequeña caída en la intensidad de la señal de voz. Impulsa la reproducción para reproducir paquetes de ruido de comodidad con más frecuencia. Sin embargo, esto a veces lleva a un recorte menor del audio.

3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#music-threshold ?
WORD Enter a number b/w (-70 to -30)
3640-6(config-voiceport)#music-threshold -50
3640-6(config-voiceport)#end
3640-6#
3640-6#show run | be voice-portvoice-port 3/0/0 music-threshold -50

voice vad-time

Una vez que el VAD se activa, el componente del ruido de fondo y del ruido de comodidad se controla mediante la configuración del comando voice vad-time timer_value en la configuración global, como se muestra en este ejemplo. Este es el tiempo de retardo en milisegundos para la detección y supresión de silencio de la transmisión de paquete de voz. El valor predeterminado para el tiempo de mantenimiento es de 250 mseg. Esto significa que dentro de los 250 milisegundos comienza el ruido de comodidad. El rango para este temporizador es de 250 ms a 65536 ms. Si se configura un valor alto para esto, el ruido de comodidad entra en juego mucho más tarde (el ruido de fondo sigue reproduciéndose). Si se configura en 65536 mseg, se apaga el ruido de comodidad. Se requiere un valor superior para este temporizador a fin de lograr una transición más fluida entre el ruido de fondo y el ruido confortable. La desventaja de configurar el comando voice vad-time a un nivel alto es que no logra el ahorro deseado de ancho de banda del 30% al 35%.

3640-6#
3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice vad-time ?
<250-65536> milliseconds
3640-6(config)#voice vad-time 750
3640-6(config)#end
3640-6#
3640-6#
3640-6#
3640-6#show run | be vad-time voice vad-time 750

Ejemplos de configuración típica para QoS

Un escenario típico para configurar llamadas VoIP es a través de un link de Frame Relay o a través de un link PPP. Estos son ejemplos de configuración para estos escenarios.

Ejemplo de Configuración de VoIPoFR - QoS

En este ejemplo (que contiene sólo secciones relevantes de la configuración), se supone que la velocidad del circuito de Frame Relay es de 256 kbps. La Velocidad de información comprometida (CIR) garantizada en PVC 100 es de 64 kbps y en PVC 200 es de 192 kbps. El PVC 100 se utiliza para transportar datos y voz. El PVC 200 se utiliza solamente para transportar datos. Existe un máximo de cuatro llamadas de voz simultáneas en cualquier momento. Configure la fragmentación en ambos PVC basándose en el CIR del PVC de voz de ancho de banda más bajo (PVC con voz portadora). A partir de los ejemplos de este documento, esto significa que el tamaño de fragmentación se decide en función del CIR de PVC 100 (que es de 64 kbps). Como se muestra en la tabla de la sección Retraso de serialización, para un link de 64 kbps, se requiere un tamaño de fragmentación de 80 bytes. Se debe configurar el mismo tamaño de fragmentación para el PVC 200.

Para obtener más detalles sobre la configuración de VoIP sobre Frame Relay, refiérase a VoIP sobre Frame Relay con Calidad de Servicio (Fragmentación, Modelado de Tráfico, Prioridad LLQ / IP RTP).

3660-1#show run
Building configuration...
!
class-map match-any voip
match ip rtp 16384 16383
match ip dscp 26 46
class-map match-all voip-control
match access-group 101
!
!
policy-map VoIPoFR
class voip
priority 48
class voip-control
bandwidth 8
class class-default
fair-queue
!
voice call send-alert
voice rtp send-recv
!
!
interface Serial4/0:0
bandwidth 256
no ip address
encapsulation frame-relay
frame-relay traffic-shaping
!
interface Serial4/0:0.1 point-to-point
bandwidth 64
ip address 10.10.10.10 255.255.255.0
frame-relay ip rtp header-compression
frame-relay interface-dlci 100
 class voice
!
interface Serial4/0:0.2 point-to-point
bandwidth 192
ip address 20.20.20.20 255.255.255.0
frame-relay interface-dlci 200
class data
!
map-class frame-relay data
frame-relay fragment 80
frame-relay adaptive-shaping becn
frame-relay cir 256000
frame-relay bc 32000
frame-relay be 0
frame-relay mincir 192000
frame-relay fair-queue
!
map-class frame-relay voice
frame-relay fragment 80
no frame-relay adaptive-shaping
frame-relay cir 64000
frame-relay bc 640
frame-relay be 0
frame-relay mincir 64000
service-policy output VoIPoFR
!
!
access-list 101 permit tcp any any eq 1720
!
!
voice-port 3/1/0
!
voice-port 3/1/1
!
!
dial-peer voice 10 voip
incoming called-number .
destination-pattern 1408.......
session target ipv4:10.10.10.11
dtmf-relay h245-signal h245-alphanumeric
no vad
!
dial-peer voice 20 pots
destination-pattern 1234
port 3/1/0
!
dial-peer voice 21 pots
destination-pattern 5678
port 3/1/1

Ejemplo de Configuración de VoIP Over PPP - QoS

En este ejemplo (que contiene sólo secciones relevantes de la configuración), se supone que la QoS debe configurarse para un controlador T1 fraccionario punto a punto (que tiene doce canales). Existe un máximo de cuatro llamadas de voz simultáneas en cualquier momento. La tarea de configuración implica configurar esta interfaz serial con encapsulación PPP, haciéndola parte de un grupo de links múltiples, creando una interfaz de links múltiples (que pertenece al mismo grupo de links múltiples) y configurando toda la QoS en la interfaz de links múltiples. Para obtener más detalles sobre la configuración de VoIP sobre PPP, consulte VoIP sobre links PPP con calidad de servicio (LLQ / prioridad IP RTP, LFI, cRTP).

3660-1#show run
Building configuration...
!
class-map match-any voip
match ip rtp 16384 16383
match ip dscp 26 46
class-map match-all voip-control
match access-group 101
!
!
policy-map VoIPoPPP
class voip
priority 48
class voip-control
bandwidth 8
class class-default
fair-queue
!
voice call send-alert
voice rtp send-recv
!
!
interface Multilink7
bandwidth 768
ip address 10.10.10.10 255.255.255.0
ip tcp header-compression iphc-format
service-policy output VoIPoPPP
no cdp enable
ppp multilink
ppp multilink fragment-delay 10
ppp multilink interleave
multilink-group 7
ip rtp header-compression iphc-format
!
!
interface Serial4/0:0
bandwidth 768
no ip address
encapsulation ppp
no fair-queue
ppp multilink
multilink-group 7
!
!
access-list 101 permit tcp any any eq 1720
!
voice-port 3/1/0
!
voice-port 3/1/1
!
!
dial-peer voice 10 voip
incoming called-number .
destination-pattern 1408.......
session target ipv4:10.10.10.11
dtmf-relay h245-signal h245-alphanumeric
no vad
!
dial-peer voice 20 pots
destination-pattern 1234
port 3/1/0
!
dial-peer voice 21 pots
destination-pattern 5678
port 3/1/1
!

Mecanismo de fluctuación y reproducción completa

Siempre hay algunas entidades no controladas en una red que contribuyen a mayores retrasos y fluctuaciones en los paquetes de voz recibidos. Al modificar el búfer de fluctuación en el gateway de terminación, la fluctuación no controlada se resuelve en la red de voz.

Mecanismo de reproducción completa

El búfer de fluctuación es un búfer de tiempo. El gateway de terminación lo proporciona para que el mecanismo de transmisión sea más efectivo. Este es un diagrama funcional del mecanismo de transmisión:

Cuando el control de transmisión recibe un paquete de voz, el mismo analiza el sello de fecha y hora de RTP. Si el paquete de voz se demora más allá de la capacidad de espera del búfer de fluctuación, el paquete se descarta inmediatamente. Si el paquete se encuentra dentro de la capacidad de almacenamiento de memoria intermedia, se lo ubica en la memoria intermedia de fluctuación. La ubicación de este paquete en la memoria intermedia de fluctuación depende de la indicación de fecha y hora de RTP que se calcula para ese paquete. En caso de que no haya paquetes de voz disponibles, el control de transmisión intenta ocultarlo (predice el paquete perdido). Si se activa VAD, se reproducirá el ruido de comodidad.

La responsabilidad del control de transmisión es administrar los eventos de los paquetes perdidos, duplicados, defectuosos y fuera de secuencia. Estos eventos se gestionan alineando el tiempo de los paquetes de voz fluctuados, reproduciendo el ruido de comodidad (si se configura VAD) o incluso regenerando los tonos de multifrecuencia de tono dual (DTMF) que se van a reproducir en el host.

El encubrimiento de un paquete de voz se realiza mediante un encubrimiento de predicción o mediante un encubrimiento de silencio. El ocultamiento de la predicción está basado en el paquete anterior y en el paquete posterior (si están disponibles). Funciona mejor con códecs de baja tasa de bits (de 5 kbps a 16 kbps). La pérdida de paquetes de voz para un códec de alta velocidad de bits (de 32 kbps a 64 kbps) puede potencialmente resultar en un ocultamiento de predicción deficiente. El ocultamiento de predicciones comienza cuando hay retrasos bajos y poco frecuentes o un menor número de pérdida de paquetes. El ocultamiento de la predicción en exceso puede causar una calidad de voz robótica. El ocultamiento de silencio es la peor forma de ocultamiento de predicción. Entra en juego cuando no hay información disponible para predecir. Es simplemente un ocultamiento de fondo. Comienza cuando hay grandes retrasos y más pérdida de paquetes. Demasiado ocultamiento de silencio lleva a una calidad de voz irregular. El ocultamiento de la predicción es bueno durante 30 milisegundos, después de que el ocultamiento del silencio entra en juego.

Memoria intermedia para fluctuación

La memoria intermedia de fluctuación está limitada por una marca de agua alta y una marca de agua baja. La marca de agua máxima es el tiempo máximo dentro del cual se espera que llegue un paquete para una transmisión a tiempo. Los paquetes que llegan después de la marca de agua alta son marcados como paquetes tardíos o como paquetes perdidos. La marca de agua baja es el tiempo mínimo dentro del cual se espera que llegue un paquete para una transmisión completa puntual. Los paquetes que llegan antes de la marca de agua baja se consideran paquetes tempranos (todavía se pueden reproducir a tiempo).

Si el gateway de terminación continúa viendo un incremento en la llegada de los paquetes tardíos, aumenta la marca de agua alta. Este valor para la marca de agua alta permanece igual durante toda la llamada. Esto se incrementa hasta un máximo definido en la configuración. De manera similar, el gateway de terminación observa el número de paquetes iniciales recibidos. Si estos paquetes comienzan a frecuentar el gateway, reduce la marca de agua baja. Este valor permanece igual durante toda la llamada. Este modo de búfer de fluctuación se denomina "modo adaptativo", donde el gateway de terminación adapta su búfer de fluctuación en función del patrón de tráfico. El otro modo es "modo fijo". En el modo fijo, hay un valor inicial para la marca de agua baja y la marca de agua alta. Este valor se basa en la demora recibida estimada (consulte la sección show voice call <port-number> de este documento).

Para obtener más detalles sobre el búfer de fluctuación, consulte Introducción a la fluctuación en las redes de voz de paquetes (plataformas Cisco IOS).

Identificación de retardo y fluctuación

En esta sección se describe cómo identificar la fluctuación en la red.

show call active voice

El comando show call active voice brief proporciona mucha información sobre una conversación en curso. Este resultado muestra algunos puntos importantes que se aprenden de este comando:

11E4 : 2170927hs.1 +600 pid:10 Answer 1000 active
dur 00:08:43 tx:26157/522967 rx:7044/139565
Tele 3/0/0:9: tx:151310/755/0ms g729r8 noise:-62 acom:0 i/0:-56/-48 dBm
11E4 : 2171198hs.1 +329 pid:20 Originate 2000 active
dur 00:08:43 tx:7044/139565 rx:26165/523127
IP 30.30.30.29:18682 rtt:51ms pl:148590/290ms lost:0/0/15 delay:65/60/132ms g729r8

Desde la salida del comando show call active voice brief, verá que lo que se reciba en el tramo de telefonía (rx:7044) se transmite al tramo IP (tx:7044). Lo mismo se aplica a los paquetes recibidos en los tramos IP (26165) que se reenvían al tramo de telefonía (26157). La diferencia en el número de paquetes recibidos en el tramo IP frente al número de paquetes transmitidos en el tramo de Telefonía se contribuye a los paquetes tardíos que no lo hacen a tiempo.

Esta salida del comando show call active voice (sin la palabra clave "brief"), señala a más detalles sobre los parámetros que identifican directamente la fluctuación.

GapFillWithSilence=850 ms
GapFillWithPrediction=9230 ms
GapFillWithInterpolation=0 ms
GapFillWithRedundancy=0 ms

show voice call <número de puerto>

El comando show voice call port-number brinda información útil. Asegúrese de estar consolado en el gateway, o si está Telneted en un gateway, asegúrese de haber ejecutado el comando terminal monitor desde el nivel exec.

Nota: Este comando no está disponible en las plataformas AS5x00/AS5x50.

En este resultado, el valor para Rx Delay Est (ms) es 71. Este es el valor actual del búfer de fluctuación. Se deduce un valor para la marca de agua alta y la marca de agua baja. Un valor inicial promedio para la marca de agua alta es 70 milésimas de segundo, mientras que para la marca de agua baja es de 60 milésimas de segundo. Una vez que se especifica un valor inicial, el gateway realiza el seguimiento de cualquier paquete anticipado o tardío que se reciba. Como se ve en el resultado, las caídas de ocultamiento de predicción son de cerca de 250 ms, mientras que el ocultamiento de silencio es de 30 ms. Siempre hay un mayor valor para el ocultamiento de predicciones, ya que el ocultamiento de silencio es sólo un peor escenario de ocultamiento de predicciones. Para cada caída de ocultamiento de predicción, hay un incremento en el descarte de desbordamiento de memoria.

Si ve descarte del búfer, no significa necesariamente que vea un aumento en la marca de agua alta. La marca de agua alta es el límite superior del búfer de fluctuación. Sólo cambia si se observa una tendencia. En otras palabras, debería haber un flujo continuo de paquetes tardíos. Esto da como resultado un aumento del búfer de fluctuación. En el resultado, existe esa tendencia. Por lo tanto, la marca de agua alta se incrementa de 70 mseg a 161 mseg. Si este valor no se cambia (y si todavía ve 14 paquetes tardíos), implica que son paquetes tardíos esporádicos, sin formar una tendencia.

Desde el resultado del comando show call active voice, busque los paquetes perdidos. Por cada paquete perdido, verá dos paquetes que están fuera de secuencia. Esto se ve en el resultado de Pkts Rx Non-Seq. Dado que no es un valor positivo, se concluye que tampoco ha habido pérdidas de paquetes.

3640-6# ***DSP VOICE TX STATISTICS***
Tx Vox/Fax Pkts: 195, Tx Sig Pkts: 0, Tx Comfort Pkts: 10
Tx Dur(ms): 192070, Tx Vox Dur(ms): 388, Tx Fax Dur(ms): 0
***DSP VOICE RX STATISTICS***
Rx Vox/Fax Pkts: 9604, Rx Signal Pkts: 0, Rx Comfort Pkts: 0
Rx Dur(ms): 192070, Rx Vox Dur(ms): 191560, Rx Fax Dur(ms): 0
Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0
Rx Early Pkts: 0, Rx Late Pkts: 14
***DSP VOICE VP_DELAY STATISTICS***
Clk Offset(ms): 0, Rx Delay Est(ms): 71
Rx Delay Lo Water Mark(ms): 60, Rx Delay Hi Water Mark(ms): 161
***DSP VOICE VP_ERROR STATISTICS***
Predict Conceal(ms): 250, Interpolate Conceal(ms): 0
Silence Conceal(ms): 30, Retroact Mem Update(ms): 0
Buf Overflow Discard(ms): 500, Talkspurt Endpoint Detect Err: 0
***DSP LEVELS***
TDM Bus Levels(dBm0): Rx -49.9 from PBX/Phone, Tx -41.7 to PBX/Phone
TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +11.1
TDM Bgd Levels(dBm0): -58.9, with activity being voice
***DSP VOICE ERROR STATISTICS***
Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0

Observe el Tx Comfort Pkts y el Rx Comfort Pkts. A partir de las salidas de ejemplo, se concluye que el teléfono conectado a este router en su mayoría se mantiene en silencio, ya que tiene muchos paquetes Tx Comfort. Al mismo tiempo, no dispone de paquetes Rx Comfort, lo que significa que el otro extremo habla continuamente.

Compare el resultado aquí con el resultado del comando anterior. Hay un mayor número de Rx Late Pkts (de 14 a 26). Sin embargo, no hay incremento en el valor de la marca de agua alta. Esto indica que los 12 paquetes se retrasan esporádicamente. El descarte de desbordamiento de búfer se aumenta a 910 msecs. Sin embargo, como no se observa ninguna tendencia, la marca de agua elevada no aumenta.

En el resultado aquí, tiene un Rx Early Pkts: 3. Esto significa que un paquete llega mucho antes de que se espere. Como se ve en la salida aquí, el búfer de fluctuación se ha estirado para alojar paquetes más tempranos reduciendo la marca de agua baja de 60 a 51.

3640-6# ***DSP VOICE TX STATISTICS***
Tx Vox/Fax Pkts: 209, Tx Sig Pkts: 0, Tx Comfort Pkts: 11
Tx Dur(ms): 337420, Tx Vox Dur(ms): 416, Tx Fax Dur(ms): 0
***DSP VOICE RX STATISTICS***
Rx Vox/Fax Pkts: 16843, Rx Signal Pkts: 0, Rx Comfort Pkts: 1
Rx Dur(ms): 337420, Rx Vox Dur(ms): 335920, Rx Fax Dur(ms): 0
Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0
Rx Early Pkts: 3, Rx Late Pkts: 26
***DSP VOICE VP_DELAY STATISTICS***
Clk Offset(ms): 0, Rx Delay Est(ms): 72
Rx Delay Lo Water Mark(ms): 51, Rx Delay Hi Water Mark(ms): 161
***DSP VOICE VP_ERROR STATISTICS***
Predict Conceal(ms): 510, Interpolate Conceal(ms): 0
Silence Conceal(ms): 70, Retroact Mem Update(ms): 0
Buf Overflow Discard(ms): 910, Talkspurt Endpoint Detect Err: 0
***DSP LEVELS***
TDM Bus Levels(dBm0): Rx -51.5 from PBX/Phone, Tx -44.1 to PBX/Phone
TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +11.9
TDM Bgd Levels(dBm0): -61.3, with activity being voice
***DSP VOICE ERROR STATISTICS***
Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0

Configuración del búfer de fluctuación en una puerta de enlace

Las pautas de QoS tratadas en este documento se ocupan del problema de calidad de voz irregular o deteriorada. La configuración del búfer de demora de reproducción es una solución alternativa para la implementación inadecuada de QoS en la red. Utilice esto únicamente como solución de interrupción o como herramienta para solucionar y reducir los problemas de fluctuación introducidos en la red.

Modo retardo de reproducción completa

El búfer de fluctuación se configura para el modo fijo o el modo adaptable. En el modo adaptable, la gateway le permite configurar un valor mínimo, uno nominal y otro máximo de oscilación de la memoria intermedia. El búfer de fluctuación espera que los paquetes lleguen dentro del rango de valores nominales. El valor nominal debe ser igual a o mayor que el mínimo, e igual a o menor que el máximo. El búfer se expande hasta el valor máximo configurado. Esto puede extenderse hasta 1700 ms. Un tema con el máximo valor de configuración es la introducción del retardo de extremo a extremo. Elija el valor del retardo máximo de reproducción de modo que no introduzca un retardo no deseado en la red. Este resultado es un ejemplo del búfer de fluctuación configurado para el modo adaptable:

3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#playout-delay mode adaptive
3640-6(config-voiceport)#playout-delay maximum 400
3640-6(config-voiceport)#playout-delay nominal 70
3640-6(config-voiceport)#playout-delay minimum low
3640-6(config-voiceport)#^Z
3640-6#
3640-6#
3640-6#show run | begin 3/0/0
voice-port 3/0/0
playout-delay maximum 400
playout-delay nominal 70
playout-delay minimum low
playout-delay mode adaptive
!

En el modo fijo, el gateway tiene en cuenta el valor configurado de nominal. Aunque le permite configurar el valor mínimo y máximo para el retardo de reproducción, se ignora cuando se configura para el modo fijo. Cuando se encuentra en modo fijo, el valor de la marca de agua alta o el valor de la marca de agua baja siempre permanece constante. Se basa en el valor nominal y en el valor de Rx Delay Est (ms). Por lo tanto, es posible que, en el modo fijo, configure el valor como 200 mseg. Sin embargo, si la demora recibida estimada es cercana a los 100 ms, es a eso a lo que se configuran la marca de agua alta y la marca de agua baja durante toda la llamada.

3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#playout-delay mode fixed
3640-6(config-voiceport)#playout-delay nominal 70
3640-6(config-voiceport)#^Z
3640-6#
3640-6#
3640-6#show run | begin 3/0/0
voice-port 3/0/0
playout-delay mode fixed
playout-delay nominal 70
!

Para más detalles acerca de la configuración de retardo de reproducción completa, consulte Optimización del retardo de reproducción completa para voz sobre IP.

Información Relacionada

• Implementación de políticas de calidad del servicio (QoS) con DSCP
• Cola de tiempo de latencia bajo
• Comparación de los comandos bandwidth y priority de una política de servicio de QoS
• Configuración de la fragmentación y el entrelazado de link para circuitos virtuales ATM y Frame Relay
• Configuración de la Fragmentación y el Intercalado de Link para PPP Multilink
• Soporte de tecnología de voz
• Soporte de Productos de Voice and Unified Communications
• Troubleshooting de Cisco IP Telephony
• Soporte Técnico - Cisco Systems

Historial de revisiones