Voz : H.323

VoIP de diseño y que despliega sobre el ISDN

16 Enero 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (13 Noviembre 2015) | Comentarios


Contenido


Introducción

La voz sobre IP (VoIP) sobre Integrated Service Digital Network (ISDN) es a veces una combinación recomendable, especialmente en las redes para empresas que utilicen telefonía IP. Las características requeridas para facilitar la Calidad de Servicio (QoS) necesaria para VoIP, Low Latency Queuing (LLQ), Class Based Weighted Fair Queuing (CBWFQ) y Link Fragmentation and Interleaving (LFI) se soportan en ISDN y su combinación funciona bien. Sin embargo, hay diversos aspectos importantes sobre diseño que se deben tener en cuenta. Este documento describe las excepciones y limitaciones que implica el uso de estas características de QoS con ISDN relativas a VoIP y facilita algunas configuraciones de muestra probadas.

prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

  • ISDN

  • Point-to-Point Protocol (PPP)

  • Multilink PPP (MLPPP)

  • LFI

  • LLQ

  • CBWFQ

  • Protocolo de transporte en tiempo real comprimido (cRTP)

Este documento no proporciona la capacitación acerca de la tecnología en estos temas sino bastante una explicación de cómo estas Tecnologías trabajan juntas en una red VoIP. Vea la sección de la “información relacionada” para más información sobre estos temas.

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

  • Software Release 12.2 del � del Cisco IOS

  • Cisco IOS Software Release 12.2(2)T a 12.2(10)T

  • Cisco IOS Software Release 12.2(12)T y Posterior

Estas opciones del diseño se presentan en este documento y se han probado con las versiones de Cisco IOS Software conocidas:

La prueba fue realizada usando el equipo siguiente. Este Routers fue conectado directamente a través del ISDN. Pagent fue utilizado para simular el tráfico y el oversubscribe RTP la conexión.

  • Cisco 7200 Router con la interfaz PRI

  • Cisco 2600 Router con la interfaz BRI

La información que contiene este documento se creó a partir de los dispositivos en 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 cualquier comando.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Problemas de diseño

Hay tres problemas que requieren la Consideración especial cuando usted diseña el VoIP sobre las redes ISDN. Éstos se describen abreviadamente en esta tabla y después se amplían sobre.

Problema Descripción
Ancho de banda variable El ancho de banda del link ISDN varía mientras que se agregan o se caen los Canales B.
El reordenar del paquete causado por el LFI Cuando se interpolan los paquetes RTP pueden llegar fuera de servicio cuando están transmitidos a través de los Canales B múltiples.
Limitaciones del control de admisión de llamadas del Cisco CallManager (CAC) El CAC basado en la ubicación del Cisco CallManager no es actualmente topología enterada.

Ancho de banda variable

El ISDN permite que caens los Canales B sean agregados o en respuesta a la demanda para el ancho de banda. El hecho de que el ancho de banda de un link varíe en un cierto plazo presenta un desafío especial a los Mecanismos para formar la cola CBWFQ y LLQ del Cisco IOS. Hasta el Cisco IOS Software Release 12.2(2)T, un directiva-mapa que implementó LLQ o el CBWFQ se podría asignar solamente una cantidad fija de ancho de banda. Por abandono, el ancho de banda asignado puede consumir solamente el 75% del ancho de banda disponible. En una interfaz de ISDN, el CBWFQ y el LLQ asume que solamente 64 kbps están disponibles, aunque la interfaz tiene el potencial para proporcionar 1.544 o el 2.408 Mbps del ancho de banda. Por lo tanto, el solamente 75% de 64 kbps, o de 48 kbps, se pueden afectar un aparato por un directiva-mapa en cualquier interfaz de ISDN. Esto restringe el número de llamadas VoIP que puedan ser llevadas. Si se afecta un aparato más ancho de banda, después se genera un mensaje de error cuando el directiva-mapa se aplica a la interfaz de ISDN.

Considere este uso del directiva-mapa como un ejemplo:

El comando policy-map
policy-map isdn-qos
  class VoIP-RTP
  priority 64
  class VoIP-Sig
  bandwidth 10

Cuando se aplica a una interfaz BRI, rechazan al comando policy-map porque más el de 75% de un Canal B (48 kbps) es reservado:

El comando service-policy output

!--- Note the highlighted error message when the policy 
!--- is applied to the dialer interface
.

router(config)# interface dialer 0
  router(config-if)# service-policy output isdn-qos
  I/f Dialer0 class VoIP-RTP requested bandwidth 64 (kbps) Available only 47 (kbps)

La solución a este problema fue introducida en el Cisco IOS Software Release 12.2(2)T. A partir de esta versión, es posible reservar un porcentaje de ancho de banda disponible en vez de un monto total de ancho de banda. Para reservar 64 kbps para el RTP y 8 kbps para señalar en una interfaz BRI con dos Canales B que es el kbps del total 128 y un canal D de 8 kbps, la servicio-directiva:

El comando policy-map
policy-map isdn-qos
  class VoIP-RTP
  priority percent 50
  class VoIP-SIG
  bandwidth 8

Como consecuencia, hay 32 kbps disponibles para el RTP cuando sube el primer Canal B, y 64 kbps disponibles cuando sube el segundo canal. Además, el Cisco IOS nunca quita la servicio-directiva de la interfaz debido al oversubscription, puesto que un oversubscription puede nunca ocurrir.

El reordenar del paquete causado por el LFI

Cuando usted realiza el VoIP sobre el ISDN, el MLPPP se utiliza para el LFI. El LFI divide los paquetes de datos grandes en fragmentos más pequeños y los transmite paralelamente a través de todos los Canales B en el conjunto. Al mismo tiempo los paquetes de voz se interpolan entre los fragmentos y se reduce su retardo. Los paquetes entrelazados no están conforme a la encapsulación MLPPP, ellos se encapsulan como paquetes PPP regulares. Por lo tanto, no tienen ningún número de secuencia MLPPP y no pueden ser reordenados si llegan fuera de servicio. La posibilidad de reordenar es real. La profundidad de las diversas colas de administración del tráfico del link en el conjunto puede diferenciar, que hace los paquetes RTP alcanzarse como resultado de la diferencia en el retardo de colocación en cola. Los diversos Canales B pueden también tomar diversas trayectorias a través de la red ISDN y terminar para arriba con diversos retrasos de la transmisión.

Generalmente, este los reordenamientos de paquetes no son un problema para los paquetes RTP. Memorias intermedias para eliminar fluctuación en los dispositivos de VoIP de recepción reordenan los paquetes basados en los números de secuencia RTP. Sin embargo, el reordenar se convierte en un problema si se utiliza el cRTP. El algoritmo cRTP asume que los paquetes RTP son comprimidos y descomprimidos en la misma orden. Si consiguen reordenados, después la descompresión no ocurre correctamente. No es actualmente seguro utilizar el cRTP si hay más de un Canal B en el conjunto MLPPP. La misma restricción solicita el MLPPP over ATM o el Frame Relay. En este caso, el cRTP no es posible si hay más de un virtual circuit (VC) en el conjunto.

Una solución al problema que reordena es ofrecida por el Multilink PPP multiclase (MCMP). El MCMP da a paquetes entrelazados una pequeña encabezado con un número de secuencia. Esto permite que los paquetes entrelazados sean reordenados por el otro extremo del conjunto, antes de que ocurra la descompresión de cRTP. El soporte MCMP se espera en el Cisco IOS Software Release 12.2(12)T. Refiera al RFC 2686 y al Id. de bug Cisco CSCdv46666 (clientes registrados solamente) para más información.

Limitaciones CAC del Cisco CallManager

Los clientes de Enterprise con las redes derivadas utilizan a menudo el ISDN para el backup de los datos. Cuando se despliega la Telefonía IP, los clientes les gusta utilizar el link del backup ISDN para la Voz, así como los datos. Esta configuración es posible pero hay algunas advertencias a observar.

La Telefonía IP en las redes derivadas se basa típicamente en el modelo centralizado del procesamiento de llamadas, y utiliza el CAC basado en la ubicación para limitar el número de llamadas a través de WAN. El CAC basado en la ubicación no tiene actualmente ningún mecanismo para seguir los cambios de la topología en la red. El Cisco CallManager no es consciente si va el link principal a una bifurcación abajo y el backup ISDN activa. Por este motivo, es crítico que el link del backup ISDN soporta el mismo número de llamadas VoIP que el link principal. Si no, el CAC podría oversubscribe el link de backup.

El ancho de banda real del link principal y del link de backup no necesita ser idéntico. Los links apenas necesitan poder llevar el mismo número de llamadas VoIP. Por ejemplo, el link de backup puede utilizar el cRTP mientras que no hace el link principal. En este caso, menos ancho de banda se requiere en el link de backup para llevar el mismo número de llamadas que el link principal.

Opciones del diseño

Hay opciones de diseño amplio diversas disponibles para el diseñador de red basado en la versión de Cisco IOS Software usada. Estas opciones son:

La discusión sobre cada opción sigue incluyendo los ejemplos de configuración enumerados aquí.

Voz y datos que coexisten en un solo Canal B con o sin el cRTP

En el Cisco IOS Software Release 12.2, el ancho de banda en un directiva-mapa se puede especificar solamente como cantidad fija hasta un máximo predeterminado del 75% del ancho de banda de link. Además, el ISDN se asume siempre para proporcionar 64 kbps del ancho de banda con independencia del número de Canales B usados en una interfaz BRI o PRI. Por lo tanto, 48 kbps son el máximo predeterminado del ancho de banda que se puede reservar en el directiva-mapa para el ISDN.

Estas limitaciones significan que tiene solamente sentido de utilizar un Canal B para los paquetes RTP que llevan. De acuerdo con los requisitos, usted puede elegir llevar los datos y la Voz en el mismo Canal B. Alternativamente, usted puede utilizar el segundo Canal B de un BRI para los datos solamente. En ambas opciones del diseño, es seguro utilizar el cRTP como todos los paquetes RTP viajan abajo de un solo Canal B, y no puede llegar fuera de servicio.

Esta opción del diseño envía todo el tráfico de voz y de datos abajo de un solo Canal B. Puesto que la Voz y los datos compiten para el mismo link, usted necesita el LFI, el LLQ, y el CBWFQ. Usted puede también utilizar con seguridad el cRTP puesto que no hay oportunidad para los paquetes RTP de reordenarse.

Por abandono, una servicio-directiva no puede reservar más de 48 kbps (el 75% de 64 kbps) para el RTP y la señalización VoIP. La cantidad mínima que usted puede asignar a la clase de la señalización VoIP es 8 kbps. Con los 40 kbps restante disponibles para uso del RTP, usted puede producir esta tabla que muestre el número máximo de llamadas que se puedan llevar por un solo BRI.

Ejemplo de tamaño (bytes) PPS cRTP Longitud del paquete (bytes) Ancho de banda (kbps) Llamadas por el BRI
20 50 No 66 26.4 1
20 50 28 11.2 3
30 33 No 76 20.1 1
30 33 38 10.0 3
40 25 No 86 17.2 2
40 25 48 9.6 4

Esta salida muestra una configuración de muestra para la Voz y los datos sobre el mismo Canal B.

Configuración para la Voz y datos sobre un solo Canal B con el cRTP

!--- This section shows only relevant parts of the configuration.


class-map match-all VoIP-RTP
 match ip dscp ef
 
!--- RTP packets.

class-map match-all VoIP-SIG
 match ip dscp af31
 
!--- VoIP signaling packets.


policy-map voice-and-data
 class VoIP-RTP
  priority 40
 
!--- 40 Kbps available for voice.

 class VoIP-SIG
  bandwidth 8
  
!--- 8 Kbps is the minimum value allowed by Cisco IOS.


interface BRI0/0
 encapsulation ppp
 dialer pool-member 1
 ppp authentication chap

interface Dialer1
 encapsulation ppp
 bandwidth 64
 
!--- Increase the bandwidth from 56 to 64 Kbps
. 
 dialer pool 1
 dialer remote-name routerB-dialer1
 dialer-group 1
 dialer string 12345678
 service-policy output voice-and-data
 
!--- The service policy.

 ppp authentication chap
 ppp chap hostname routerA-dialer1
 ppp chap password cisco
 ppp multilink
 ppp multilink fragment-delay 10
 
!--- THe LFI delay equals 10 msec.

 ppp multilink interleave
 
!--- Enable LFI.

 ip rtp header-compression
 
!--- RTP header compression is OK.

Voz y datos sobre los Canales B Separate con o sin el cRTP

Este diseño es también posible por medio del Cisco IOS Software Release 12.2. Sin embargo, para hacer un mejor uso de los canales B ISDN disponibles, se separan la Voz y los datos. El ejemplo elegido es conveniente para una configuración de la velocidad básica donde los paquetes RTP utilizan un Canal B, y el uso de los datos y de la señalización de voz el segundo Canal B. Los conceptos similares solicitan una configuración de la velocidad primaria donde más canales se pueden utilizar para los datos.

Porque los paquetes RTP no compiten con ningunos datos, el LFI y el LLQ en el canal de voz no deben ser requeridos. Sin embargo, es una práctica adecuada habilitarla de todos modos. El Cisco Discovery Protocol (CDP) y las actualizaciones de ruteo se pueden habilitar por el error, o un ataque de Negación de servicio (DoS) puede inundar el canal de voz. En el canal de datos, no se requiere ningún LFI. Pero el CBWFQ se requiere para proteger la señalización VoIP contra los datos generales. Las actualizaciones de ruteo en el canal de voz necesitan ser suprimidas para evitar el tráfico que se rutea a través de esta interfaz. En su lugar, utilice la encaminamiento basada directiva para forzar los paquetes RTP a través del canal de voz. Usted puede utilizar con seguridad el cRTP puesto que no hay oportunidad para los paquetes RTP de reordenarse.

Por abandono una servicio-directiva no puede reservar más de 48 kbps (el 75% de 64 kbps) para el RTP y la señalización VoIP. Sin embargo, es seguro aumentar el porcentaje hasta el 90% con este diseño, pues no hay otro tráfico en el canal de voz. Este máximo creciente se puede especificar con el comando max-reserved-bandwidth.

De acuerdo con 57 kbps para el RTP, usted puede producir esta tabla que muestre el número máximo de llamadas que un solo BRI pueda llevar.

Ejemplo de tamaño (bytes) PPS cRTP Longitud del paquete (bytes) Ancho de banda (kbps) Llamadas por el BRI
20 50 No 66 26.4 2
20 50 28 11.2 5
30 33 No 76 20.1 2
30 33 38 10.0 5
40 25 No 86 17.2 3
40 25 48 9.6 5

Esta tabla muestra una configuración de muestra para la Voz y los datos sobre los Canales B separados.

Configuración para la Voz y datos sobre los Canales B Separate con el cRTP

!--- This section shows only relevant parts of the configuration.



Class-map match-all VoIP-RTP
 match ip dscp ef
class-map match-all VoIP-SIG
 match ip dscp af31 

policy-map voice-only
 class VoIP-RTP
  priority 57

policy-map data-and-signaling
 class VoIP-SIG
  bandwidth 8

interface BRI0/0
 encapsulation ppp
 dialer pool-member 1
 ppp authentication chap

interface Dialer1
 encapsulation ppp
 bandwidth 64
 
!--- Increase the bandwidth from 56 to 64 Kbps.

 dialer pool 1
 dialer remote-name routerB-dialer1
 max-reserved-bandwidth 90
 
!--- Allow 90% of the bandwidth to be reserved.

 dialer-group 1
 dialer string 12345678
 service-policy output voice-only
 
!--- RTP packets only.

 ppp authentication chap
 ppp chap hostname routerA-dialer1
 ppp chap password cisco
 ppp multilink
 ppp multilink fragment-delay 10
 ppp multilink interleave 
 ip rtp header-compression

interface Dialer2
 encapsulation ppp
 dialer pool 1
 dialer remote-name routerB-dialer2
 dialer-group 1
 dialer string 12345678
 service-policy output data-and-signaling
 
!--- Data and VoIP signaling.

 ppp authentication chap
 ppp chap hostname routerA-dialer2
 ppp chap password cisco

router eigrp 1
 passive-interface dialer 1
 
!--- Suppress routing on the voice channel.


interface fastethernet 0/1
 ip policy route-map ip-rtp
 
!--- Policy route RTP packets.


route-map ip-rtp permit 10
 match ip address 100
 set interface dialer 1
 
!--- Route RTP packets out dialer 1.


access-list 100 permit udp any range 16384 32768
  any range 16384 32768 dscp ef

Voz y datos que coexisten en los Canales B múltiples sin el cRTP

Este diseño se aprovecha del hecho que a partir del Cisco IOS Software Release 12.2(2)T, usted puede especificar el ancho de banda en el directiva-mapa como porcentaje en vez de un número absoluto. Esta capacidad permite que usted aplique una política de servicio a un conjunto con los Canales B múltiples. Como consecuencia, los paquetes RTP se pueden llevar a través de los Canales B múltiples. El equilibrio es que la implementación de los trayectos múltiples significa que el cRTP no es seguro utilizar debido al reordenamiento potencial de los paquetes RTP.

El Cisco IOS proporciona dos mecanismos para que usted controle cómo los Canales B adicionales se traen en respuesta a la demanda. El primer mecanismo se refiere comúnmente como On-Demand Routing del dial (DDR). El DDR requiere un umbral de carga ser especificado como una parte de ancho de banda disponible. Cuando el flujo de tráfico excede número de umbral, un canal adicional se agrega al conjunto. Se calcula el umbral pues una media corriente, y allí es cierto retardo en sacar a colación los Canales B adicionales cuando la carga aumenta. Este retardo no es un problema con los datos. Sin embargo, con la Voz, no es aceptable si un usuario hace las llamadas telefónicas, y tardan los minutos para sacar a colación el ancho de banda necesario para soportar el QoS para la llamada.

Usted puede reducir el retardo para sacar a colación los canales adicionales a alrededor 30 segundos con el comando load-interval en la interfaz de ISDN física. Sin embargo, incluso 30 segundos son demasiado largos para que una llamada vaya sin el QoS requerido. La solución es tener el comando dialer load-threshold fijado a un valor que asegure el ancho de banda suficiente en la reserva para soportar por lo menos una llamada VoIP adicional con QoS apropiado.

Puesto que todavía existe el problema si dos llamadas se sacan a colación dentro del intervalo 30-second, se prefiere un segundo y una solución más drástica. La solución es sacar a colación todos los Canales B inmediatamente y guardarlos para arriba mientras requieran al servicio ISDN. Usted puede utilizar el comando ppp multilink links minimum de especificar esta acción.

Con dos Canales B disponibles, la servicio-directiva puede ahora reservar 96 kbps (el 75% del kbps 128) para el RTP y la señalización VoIP. Usted necesita 8 kbps para la señalización VoIP, así que ésta deja 88 kbps para el RTP. De acuerdo con el uso de dos Canales B, esta tabla muestra el número máximo de llamadas que se puedan llevar en el BRI.

— — —
Ejemplo de tamaño (bytes) PPS cRTP Longitud del paquete (bytes) Ancho de banda (kbps) Llamadas por el BRI
20 50 No 66 26.4 3
20 50 28 11.2
30 33 No 76 20.1 4
30 33 38 10.0
40 25 No 86 17.2 5
40 25 48 9.6

Esta salida muestra una configuración de muestra para la Voz y los datos que coexisten en los Canales B múltiples sin el cRTP.

Configuración para la Voz y datos que coexisten en los Canales B múltiples sin el cRTP

!--- This section shows only relevant parts of the configuration.



Class-map match-all VoIP-RTP
 match ip dscp ef
class-map match-all VoIP-SIG
 match ip dscp af31 

policy-map voice-and-data
 class VoIP-RTP
  priority percent 65
  
!--- This is 65% of 64/128K for RTP.

 class VoIP-SIG
  bandwidth percent 10
  
!--- This is 10% of 64/128K for VoIP signaling.


interface BRI0/0
 encapsulation ppp
 dialer pool-member 1
 ppp authentication chap

interface Dialer1
 encapsulation ppp
 dialer pool 1
 dialer remote-name routerB-dialer1
 dialer-group 1
 dialer string 12345678
 service-policy output voice-and-data
 ppp authentication chap
 ppp chap hostname routerA-dialer1
 ppp chap password cisco
 ppp multilink
 ppp multilink fragment-delay 10
 ppp multilink interleave 
 ppp multilink links minimum 2
 
!--- Bring up two B-channels immediately.

 no ip rtp header-compression
 
!--- cRTP is not safe

Voz y datos que coexisten en los Canales B múltiples con el cRTP

Con la introducción de MCMP en el Cisco IOS Software Release 12.2(12)T, el cRTP que reordena el problema se soluciona, y es posible tener Canales B múltiples del uso de la Voz y todavía hacer el cRTP. Los principios de diseño para esto son idénticos a ése discutidos en la Voz y los datos que coexisten en los Canales B múltiples sin la sección del cRTP, con la única diferencia siendo que usted puede ahora habilitar el cRTP. Esta tabla agrega el número máximo de llamadas que se puedan llevar en el BRI, sobre la base del uso del cRTP en dos Canales B.

Ejemplo de tamaño (bytes) PPS cRTP Longitud del paquete (bytes) Ancho de banda (kbps) Llamadas por el BRI
20 50 No 66 26.4 3
20 50 28 11.2 7
30 33 No 76 20.1 4
30 33 38 10.0 8
40 25 No 86 17.2 5
40 25 48 9.6 9

Para este escenario la configuración para la Voz y los datos que coexisten en los Canales B múltiples sin el cRTP se aplica. La excepción es que ahora el MCMP está habilitado y el cRTP está en cuando usted agrega esta salida a la interfaz del dialer.

Configuración multiclase del multilink ppp de la muestra

!--- This command is available with Cisco IOS Software Release 12.2(12)T.
 
interface Dialer1 ppp multilink multiclass
	  
!--- Enable MCMP.

 ip rtp header-compression
    
!--- Support cRTP on the bundle

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 25610