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

Quienes lean este documento deben tener conocimiento de lo siguiente:

• Configuración básica de voz de paquete (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 los 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. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). 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. Sin nada que llene 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 variablemente). A veces, la detección de actividad de voz (VAD) añade recorte 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 introducción de una fluctuación mínima en la red de voz.

Requisito de ancho de banda

Antes de plantearse aplicar medidas para minimizar la fluctuación, aprovisione 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 el 20%). Los requisitos de ancho de banda varían en función del 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 al requisito de ancho de banda. Si se utiliza la compresión de encabezado (cRTP) del protocolo en tiempo real (RTP), se puede reducir aún más el requisito de ancho de banda.

Por ejemplo, el ancho de banda necesario para una llamada de voz que utiliza el códec G.729 (carga útil predeterminada de 20 bytes) con cRTP es similar a lo siguiente:

• Carga útil de voz + comprimida (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 a la hora de priorizar la voz. La primera es clasificar y marcar el tráfico de voz interesante. La segunda es priorizar el tráfico de voz marcado como interesante. Las dos subsecciones aquí discuten 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 realizarse lo más alejada posible del 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):

Differentiated Services (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. Reemplaza el byte ToS en IP V4 para tomar decisiones de comportamiento por salto (PHP) sobre la clasificación de paquetes y las funciones de condicionamiento del tráfico, como la medición, la marcación, el modelado y la regulación. Además de los RFC mencionados anteriormente, RFC 2597 define las clases de reenvío asegurado (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 = Prioridad 7

• 110 = Control entre redes = Prioridad 6

• 101 = CRITIC/ECP = Precedencia 5

• 100 = Invalidación de Flash = Prioridad 4

• 011 = Flash = Prioridad 3

• 010 = Inmediato = Prioridad 2

• 001 = Prioridad = Prioridad 1

• 000 = Rutina = Precedencia 0

000XXX00 Los bits 3, 4, 5 (DS2, DS1, DS0) son bits de retraso, rendimiento y fiabilidad.

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

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

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

000000XX Bits 6, 7: ECN

En estas dos secciones se analizan dos maneras de llevar a cabo la clasificación y la marcación.

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

Con los gateways VoIP de Cisco, generalmente 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 Precedencia IP 5. Esto significa que los tres bits más significativos del byte ToS 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 de reenvío acelerado (EF) 101110. Todos los paquetes de señalización están configurados 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 del IOS® de Cisco. La precedencia IP ya no está disponible en la versión 12.2T del software del IOS de Cisco. Sin embargo, lo mismo se logra con el comando ip qos dscp. La precedencia IP 5 (101) se asigna a IP DSCP 101000. Para obtener más información, consulte Clasificación de la Señalización 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. Se trata de un método de configuración basado en plantillas que separa la clasificación de la política. Esto permite que varias funciones de QoS se configuren juntas para varias clases. Utilice un comando class-map para clasificar el tráfico en función de varios criterios de coincidencia y un comando policy-map para determinar lo que debe ocurrir con cada clase. Aplique la política al tráfico entrante o saliente en una interfaz mediante la ejecución del comando service-policy. Este ejemplo de configuración muestra cómo utilizar la CLI de QoS modular para clasificar y marcar 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 "class voip" y se establece con la Precedencia IP 5. Esto significa que los tres bits más significativos del byte ToS IP se establecen en 101. ACL 100 coincide con los puertos UDP comunes utilizados por VoIP. De manera similar, la ACL 101 coincide con el tráfico de señalización H.323 (puerto 1720 del Protocolo de control de transmisión (TCP)). El resto del tráfico se establece con Precedencia IP 0. La política se denomina "mqc". Se aplica al tráfico entrante en Ethernet 0/0.

Establecimiento de prioridad

Después de que cada salto en la red es 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 proporcionan a cada paquete VoIP con la QoS requerida. En ese momento, configure técnicas especiales para proporcionar colas de prioridad para asegurarse de que los paquetes de datos de gran tamaño no interfieran con la transmisión de datos de voz. Esto suele ser necesario en los enlaces WAN más lentos en los que existe una gran posibilidad de congestión. Una vez que todo el tráfico interesante se coloque 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 de manera efectiva le dé 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 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 de modo 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 la cola para determinar cuándo el router necesita descartar paquetes si hay demasiados paquetes que esperan en una 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. El class-default se configura con un comando fair-queue. Esto significa que a cada flujo no clasificado se le da una proporción aproximadamente igual del ancho de banda restante.

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

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 otorga 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. La clase data2 coincide con el tráfico Telnet (puerto TCP 23 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 prioritario para todas las clases deben ser inferiores al 75% del ancho de banda de la interfaz. Modifique este porcentaje ejecutando el comando max-reserved bandwidth interface.

Esta tabla compara diferentes mecanismos de 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 salen de la cola exactamente en 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 troceo 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 de paquete, la unidad de transmisión máxima (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 realizar ningún servicio prioritario. 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 servicio prioritario.	El tráfico de mayor prioridad priva de ancho de banda a las colas de menor prioridad. 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 realizar ningún servicio prioritario.3
Cola prioritaria de cola equilibrada ponderada (PQ-WFQ), también denominada prioridad IP RTP	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.	No existe 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 aplicaciones puede introducir fluctuación.4

1. No apto para voz.

2. Necesita ancho de banda garantizado para voz.

3. Necesita ocuparse de la latencia.

4. Suficiente para la voz.

Demora de serialización

Incluso si la colocación en cola funciona mejor y prioriza el 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 en función de su peso configurado. Si un paquete de voz prioritario llega a la cola de salida mientras estos paquetes están siendo atendidos, 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 que es tan grande como 1500 bytes, en un link más lento, esto se traduce en una demora enorme. 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 tiene que 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 otro lado, otro paquete de voz tiene que esperar solo 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 generalmente 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 garantice que el tamaño de una unidad de transmisión sea inferior a 10 ms. Cualquier paquete que tenga un retraso de serialización superior a 10 ms debe fragmentarse en fragmentos de 10 ms. Un fragmento o fragmento de 10 ms es el número de bytes que se envían a través del 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 la fragmentación de paquetes nunca debe ser inferior al tamaño del paquete VoIP. No fragmente 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 intercalación y fragmentación 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. Esta tabla enumera sus ventajas y limitaciones:

Mecanismo de fragmentación e intercalación 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 sólo los reensambla la aplicación receptora. Por lo tanto, el uso de la red es ineficiente. Sólo los paquetes IP con el bit Do not Fragment (DF) no configurado pueden manejar bien la fragmentación. Uso intensivo del procesador. No recomendado.
Multilink Point-to-Point Protocol (MLPPP) LFI	En los links seriales punto a punto, primero se debe configurar MLPPP y 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 40 o 50% de silencio. 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 en la conversación. Sustituye esos huecos por ruido de comodidad (ruido de fondo). Por lo tanto, se ahorra una cantidad de ancho de banda. Sin embargo, es un equilibrio. Hay un tiempo pequeño (en orden de milisegundos) antes de que los códecs detecten la actividad de voz seguida 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 se detenga la voz antes de que se detenga la transmisión. Al reiniciar la transmisión, incluye los 5 ms anteriores de voz junto con la conversación 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, desactive el VAD.

Parámetros VAD para la puesta a punto

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

music-threshold

Se decide un umbral inicial que rige cuando VAD debe 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 Decibelios por milivatio (dBm) a -30 dBm. El valor predeterminado 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 (cercano a -30 dBm) hace que VAD se active incluso para una pequeña caída en la potencia de la señal de voz. Activa la reproducción para reproducir paquetes de ruido de comodidad con más frecuencia. Sin embargo, esto a veces conduce a pequeños recortes de 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 de ruido de fondo y 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 250 mseg, 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 continúa 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 30 a 35 por ciento de ahorro de ancho de banda deseado.

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 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. PVC 100 se utiliza para transportar datos y voz. PVC 200 se utiliza solamente para transportar datos. Existe un máximo de cuatro llamadas de voz simultáneas en un momento dado. Configure la fragmentación en ambos PVC basándose en la CIR del PVC de voz de ancho de banda más bajo (PVC que transporta voz). Según los ejemplos de este documento, esto significa que el tamaño de la fragmentación se decide en función de la CIR de PVC 100 (que es 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, LLQ / Prioridad 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 sobre 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 fraccional punto a punto (que tiene doce canales). Existe un máximo de cuatro llamadas de voz simultáneas en un momento dado. La tarea de configuración implica configurar esta interfaz serial con encapsulación PPP, hacerla parte de un grupo de links múltiples, crear una interfaz de links múltiples (que pertenece al mismo grupo de links múltiples) y configurar 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 más demoras 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 suministra para que el mecanismo de reproducción sea más eficaz. Este es un diagrama funcional del mecanismo de emisió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 retrasa más allá de la capacidad de retención 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 ningún paquete de voz disponible, el control de reproducción intenta ocultarlo (predice el paquete perdido). Si VAD está activado, se reproduce 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 controlan mediante la alineación temporal de los paquetes de voz con fluctuaciones, la reproducción de ruido de comodidad (si se ha configurado VAD) o incluso la regeneración de tonos de multifrecuencia de tono dual (DTMF) para que se reproduzcan 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 velocidad 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 dar lugar potencialmente a una mala ocultación de la predicción. El ocultamiento de predicción comienza cuando hay retrasos bajos e infrecuentes o un menor número de pérdidas 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 demoras altas y más cantidad de pérdida de paquetes. Demasiado silencio oculto conduce a una calidad de voz entrecortada. 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 observando un incremento en la llegada de paquetes tardíos, aumenta la marca de agua alta. Este valor de 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 la cantidad de paquetes tempranos 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 adaptable", 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 el retraso recibido estimado ( vea la sección show voice call <port-number> de este documento).

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

Identificación de retardo y fluctuación

Esta sección describe cómo identificar la fluctuación en su red.

show call active voice

El comando show call active voice brief brinda una gran cantidad de 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

En 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 Telephony (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 llegan a tiempo.

Esta salida del comando show call active voice (sin la palabra clave "brief"), apunta 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á conectado a una gateway mediante Telnet, 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 esta salida, el valor de Rx Delay Est (ms) es 71. Éste es el valor actual del búfer de fluctuación. En este caso 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 observa en el resultado, las caídas de ocultación de predicción están cerca de 250 ms, mientras que la ocultación de silencio está cerca de 30 ms. Siempre hay un mayor valor para la ocultación de predicción, ya que la ocultación de silencio es solo un peor escenario de ocultación de predicción. Para cada caída de ocultamiento de predicción, hay un incremento en el descarte de desbordamiento de memoria.

Si ve el descarte del búfer, no significa necesariamente que observe 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, debe haber un flujo continuo de paquetes tardíos. Esto produce un aumento del búfer de fluctuación. En el resultado, esta tendencia está presente. 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 se trata de paquetes tardíos esporádicos, que no forman una tendencia.

Desde la salida del comando show call active voice, busque paquetes perdidos. Por cada paquete perdido, verá dos paquetes que están fuera de secuencia. Esto se observa en la salida Rx Non-Seq Pkts. 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, tiene cero Rx Comfort Pkts, lo que significa que el otro extremo habla continuamente.

Compare aquí el resultado con el resultado del comando anterior. Hay un aumento en el número de paquetes tardíos de Rx (de 14 a 26). Sin embargo, no se produce ningún incremento en el valor máximo de la marca de agua. Esto indica que los 12 paquetes se retrasan esporádicamente. El descarte de desbordamiento de búfer se aumenta a 910 ms. Sin embargo, al no observarse ninguna tendencia, la marca de agua elevada no aumenta.

En el resultado que se muestra a continuación, se muestra un Rx Early Pkts: 3. Esto significa que un paquete llega mucho antes de lo esperado. Como se observa en la salida aquí, el búfer de fluctuación se ha estirado para acomodar paquetes más tempranos al reducir 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 un gateway

Las pautas de QoS que se tratan en este documento se ocupan del problema de calidad de voz entrecortada o deteriorada. La configuración del búfer de demora de reproducción es una solución alternativa para la implementación incorrecta de QoS en la red. Utilice esto solo como solución de problema 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 valor nominal. 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 mseg. Un tema con el máximo valor de configuración es la introducción del retardo de extremo a extremo. Elija el valor de retardo de reproducción máximo para que no se produzca 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 la demora de reproducción, se ignora cuando se configura para el modo fijo. En el modo fijo, el valor de la marca de agua superior o el valor de la marca de agua inferior 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 el retraso recibido estimado es cercano a 100 ms, es el valor de la marca de agua alta y la marca de agua baja se establece para toda la duración de 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 Entrelazado de Links 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