Voix : H.323

Définition et déploiement d'un protocole VoIP sur RNIS

18 juin 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (19 décembre 2015) | Commentaires


Contenu


Introduction

La voix sur ip (VoIP) au-dessus du réseau numérique à intégration de services (le RNIS) est parfois une combinaison desirable, particulièrement dans les réseaux d'entreprise utilisant la Téléphonie sur IP. Les caractéristiques exigées pour fournir le Qualité de service (QoS) nécessaire pour le VoIP, le Fonction Low Latency Queuing (LLQ), la mise en file d'attente pondérée basée par classe (CBWFQ), et le Fonction Link Fragmentation and Interleaving (LFI), sont prises en charge pour le RNIS et les travaux de combinaison. Cependant, il y a des considérations significatives de conception à prendre en considération. Ce document discute les mises en garde et les limites impliquées en utilisant ces caractéristiques de QoS associées par VoIP avec le RNIS, et fournit quelques configurations d'échantillon testées.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

  • LE RNIS

  • Protocole point à point (PPP)

  • Multilink PPP (MLPPP)

  • LFI

  • LLQ

  • CBWFQ

  • Protocole CRTP (Compressed Real-Time Protocol)

Ce document ne fournit pas la formation en technologie sur ces sujets mais plutôt une explication de la façon dont ces Technologies fonctionnent ensemble dans un réseau VoIP. Voyez la section « de l'information relative » pour plus d'informations sur ces sujets.

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

  • Version de logiciel 12.2 de½ du¿Â du Cisco IOSïÂ

  • Logiciel Cisco IOS version 12.2(2)T à 12.2(10)T

  • Version du logiciel Cisco IOS 12.2(12)T et plus tard

Ces options de conception sont présentées dans ce document et ont été testées avec les versions logicielles remarquables de Cisco IOS :

L'essai a été réalisé utilisant le matériel suivant. Ces Routeurs ont été connectés directement à travers le RNIS. Pagent a été utilisé pour simuler le trafic et l'oversubscribe de RTP la connexion.

  • Routeur de Cisco 7200 avec l'interface PRI

  • Routeur de Cisco 2600 avec l'interface BRI

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Questions de conception

Il y a trois questions qui exigent la considération spéciale quand vous concevez des réseaux de VoIP sur RNIS. Ceux-ci sont décrits brièvement dans cette table et au moment alors développés.

Question Description
Bande passante variable La bande passante de liaison RNIS varie pendant que des canaux B sont ajoutés ou abandonnés.
Réarrangement de paquet provoqué par LFI Quand des paquets de RTP sont intercalés ils peuvent arriver en panne une fois transmis à travers de plusieurs canaux B.
Limites du contrôle d'admission d'appel de Cisco CallManager (CAC) Le contrôle d'admission des appels basé sur l'emplacement géographique de Cisco CallManager n'est pas actuellement topologie avertie.

Bande passante variable

Le RNIS permet des canaux B à ajouter ou être abandonnés en réponse à la demande de la bande passante. Le fait que la bande passante d'un lien varie au fil du temps présente un défi spécial aux mécanismes de mise en file d'attente CBWFQ et LLQ du Cisco IOS. Jusqu'au Logiciel Cisco IOS version 12.2(2)T, un policy-map qui a mis en application LLQ ou CBWFQ pourrait seulement être assigné une quantité déterminée de bande passante. Par défaut, la bande passante assignée peut seulement consommer 75% de la bande passante disponible. Sur une interface RNIS, CBWFQ et LLQ suppose que seulement les 64 Kbits/s est disponible, quoique l'interface ait le potentiel de fournir 1.544 ou 2.408 Mbits/s de bande passante. Par conséquent, seulement 75% de 64 Kbits/s, ou de 48 Kbps, peut être alloué par un policy-map sur n'importe quelle interface RNIS. Ceci limite le nombre d'appels VoIP qui peuvent être portés. Si plus de bande passante est allouée, alors un message d'erreur est généré quand le policy-map est appliqué à l'interface RNIS.

Considérez cette utilisation de policy-map comme exemple :

La commande policy-map
policy-map isdn-qos
  class VoIP-RTP
  priority 64
  class VoIP-Sig
  bandwidth 10

Quand il est appliqué à une interface BRI, la commande de policy-map est rejetée parce que plus de 75% d'un canal B (48 Kbps) est réservé :

La commande de sortie de service-stratégie

!--- 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 solution à ce problème a été introduite dans le Logiciel Cisco IOS version 12.2(2)T. En date de cette release, il est possible de réserver un pourcentage de bande passante disponible au lieu d'une quantité parfaite de bande passante. Afin de réserver des 64 Kbits/s pour le RTP et 8 Kbps pour signaler sur une interface BRI avec deux canaux B que le total 128 Kbps et un canal D de 8 Kbps, la service-stratégie est :

La commande policy-map
policy-map isdn-qos
  class VoIP-RTP
  priority percent 50
  class VoIP-SIG
  bandwidth 8

En conséquence, il y a de 32 Kbps de disponible pour le RTP quand la première Manche est soulevée, et de 64 Kbits/s disponibles quand le deuxième canal est soulevé. En outre, le Cisco IOS n'enlève jamais la service-stratégie de l'interface due au surabonnement, puisqu'un surabonnement peut ne jamais se produire.

Réarrangement de paquet provoqué par LFI

Quand vous exécutez le VoIP sur RNIS, MLPPP est utilisé pour LFI. LFI divise de grands paquets de données en plus petits fragments et les transmet en parallèle à travers tous les canaux B dans le paquet. En même temps des paquets vocaux sont intercalés entre les fragments et leur retard est réduit. Les paquets intercalés ne sont pas sujets à l'encapsulation MLPPP, ils sont encapsulés en tant que paquets PPP réguliers. Par conséquent, ils n'ont aucun numéro de séquence MLPPP et ne peuvent pas être commandés à nouveau si ils arrivent en panne. La possibilité pour commander à nouveau est vraie. La profondeur des diverses files d'attente de lien dans le paquet peut différer, qui fait se rattraper des paquets de RTP en raison de la différence dans le retard de mise en file d'attente. Les divers canaux B peuvent également prendre des différents chemins par le réseau RNIS et finir par avec différents retards de transmission.

Généralement, ce réarrangement des paquets n'est pas un problème pour des paquets de RTP. Les tampons d'élimitation d'instabilité sur les appareils voip de réception commandent à nouveau les paquets basés sur les numéros de séquence de RTP. Cependant, le réarrangement devient un problème si le cRTP est utilisé. L'algorithme de cRTP suppose que des paquets de RTP sont compressés et décompressés dans la même commande. S'ils obtiennent commandé à nouveau, alors la décompression ne se produit pas correctement. Il n'est pas actuellement sûr d'utiliser le cRTP s'il y a plus d'un canal B dans le paquet MLPPP. La même restriction s'applique pour MLPPP au-dessus d'atmosphère ou de Relais de trames. Dans ce cas, le cRTP n'est pas possible s'il y a plus d'un circuit virtuel (circuit virtuel) dans le paquet.

Une solution au problème de réarrangement est offerte par le PPP à liaisons multiples multiclasse (MCMP). MCMP donne aux paquets intercalés une petite en-tête avec un numéro de séquence. Ceci permet les paquets intercalés à commander à nouveau par l'extrémité du paquet, avant que la décompression de cRTP ait lieu. Le support MCMP est prévu dans la version du logiciel Cisco IOS 12.2(12)T. Référez-vous à RFC 2686 et à ID de bogue Cisco CSCdv46666 (clients enregistrés seulement) pour de plus amples informations.

Limites du Cisco CallManager CAC

Les clients de l'entreprise avec des réseaux de branchement utilisent souvent le RNIS pour la sauvegarde des données. Quand la Téléphonie sur IP est déployée, les clients aiment utiliser le lien de sauvegarde RNIS pour la Voix, aussi bien que des données. Cette configuration est possible mais il y a quelques mises en garde à observer.

La Téléphonie sur IP dans des réseaux de branchement est typiquement basée sur le modèle centralisé de Traitement des appels, et emploie le contrôle d'admission des appels basé sur l'emplacement géographique pour limiter le nombre d'appels à travers le WAN. Le CAC géolocalisé n'a actuellement aucun mécanisme pour dépister des changements de topologie du réseau. Le Cisco CallManager ne se rend pas compte si la liaison principale à un branchement descend et la sauvegarde RNIS lance. Pour cette raison, il est essentiel que le lien de sauvegarde RNIS prenne en charge le même nombre d'appels VoIP que la liaison principale. Autrement, le CAC pourrait oversubscribe la liaison de sauvegarde.

La bande passante réelle de la liaison principale et de la liaison de sauvegarde n'a pas besoin d'être identique. Les liens doivent juste pouvoir porter le même nombre d'appels VoIP. Par exemple, la liaison de sauvegarde peut utiliser le cRTP alors que la liaison principale ne fait pas. Dans ce cas, moins de bande passante est exigée sur la liaison de sauvegarde pour porter le même nombre d'appels que la liaison principale.

Options de conception

Il y a de diverses larges options de conception disponibles au créateur de réseau basé sur la version logicielle de Cisco IOS utilisée. Ces options sont :

La discussion en chaque option suit comprenant les exemples de configuration répertoriés ici.

Voix et données coexistant sur un canal B simple avec ou sans le cRTP

Dans le Logiciel Cisco IOS version 12.2, la bande passante dans un policy-map peut seulement être spécifiée comme quantité fixe jusqu'à un maximum par défaut de 75% de la bande passante de lien. En outre, on assume que toujours le RNIS fournit des 64 Kbits/s de bande passante indépendamment du nombre de canaux B utilisés sur une interface BRI ou PRI. Par conséquent, 48 Kbps est le maximum par défaut de bande passante qui peut être réservée dans le policy-map pour le RNIS.

Ces limites signifient qu'il semble seulement raisonnable d'utiliser un canal B pour les paquets de transport de RTP. Basé sur les conditions requises, vous pouvez choisir de porter des données et la Voix sur le même canal B. Alternativement, vous pouvez utiliser le deuxième canal B d'un BRI pour des données seulement. Dans chacun des deux options de conception, il est sûr d'utiliser le cRTP car tous les paquets de RTP voyagent en bas d'un canal B simple, et ne peut pas arriver en panne.

Cette option de conception envoie tout le trafic voix et de données en bas d'un canal B simple. Puisque la Voix et les données concurrencent pour le même lien, vous avez besoin de LFI, de LLQ, et de CBWFQ. Vous pouvez également sans risque utiliser le cRTP puisqu'il n'y a aucune occasion pour que les paquets de RTP deviennent commandé à nouveau.

Par défaut, une service-stratégie ne peut pas réserver plus de 48 Kbps (75% de 64 Kbits/s) pour le RTP et la signalisation VoIP. La quantité minimum que vous pouvez assigner à la classe de signalisation VoIP est de 8 Kbps. Avec les 40 Kbps demeurant disponibles à l'usage du RTP, vous pouvez produire cette table qui affiche le nombre maximal d'appels qui peuvent être portés par un BRI simple.

Dimension de l'échantillon (octets) PPS cRTP Longueur de paquet (octets) Bande passante (Kbps) Appels par BRI
20 50 Non 66 26.4 1
20 50 Oui 28 11.2 3
30 33 Non 76 20.1 1
30 33 Oui 38 10.0 3
40 25 Non 86 17.2 2
40 25 Oui 48 9.6 4

Cette sortie affiche une configuration d'échantillon pour la Voix et des données sur le même canal B.

Configuration pour la Voix et données sur un canal B simple avec le 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.

Voix et données sur des canaux B Separate avec ou sans le cRTP

Cette conception est également possible au moyen du Logiciel Cisco IOS version 12.2. Cependant, afin de faire une meilleure utilisation des canaux RNIS B disponibles, la Voix et les données sont séparées. L'exemple choisi convient pour une configuration de débit de base où les paquets de RTP utilisent un canal B, et l'usage de signalisation de données et de Voix le deuxième canal B. Les concepts semblables s'appliquent pour une configuration de débit primaire où plus de canaux peuvent être utilisés pour des données.

Puisque les paquets de RTP ne concurrencent aucune donnée, LFI et LLQ sur le canal vocal ne devraient pas être exigés. Cependant, enable d'il est conseillé de il de toute façon. Le Protocole CDP (Cisco Discovery Protocol) et les mises à jour de routage peuvent être activés par erreur, ou une attaque du déni de service (DOS) peut inonder le canal vocal. Sur la voie de transmission de données, aucun LFI n'est exigé. Mais CBWFQ est exigé pour protéger la signalisation VoIP contre des données générales. Conduisant des mises à jour sur la nécessité de canal vocal d'être supprimé pour éviter le trafic qui est conduit à travers cette interface. Dans son endroit, la stratégie d'utilisation a basé le routage pour forcer des paquets de RTP à travers le canal vocal. Vous pouvez sans risque utiliser le cRTP puisqu'il n'y a aucune occasion pour que les paquets de RTP deviennent commandé à nouveau.

Par défaut une service-stratégie ne peut pas réserver plus de 48 Kbps (75% de 64 Kbits/s) pour le RTP et la signalisation VoIP. Cependant, il est sûr d'augmenter le pourcentage à 90% avec cette conception, car il n'y a aucun autre trafic sur le canal vocal. Ce maximum accru peut être spécifié avec la commande de max-reserved-bandwidth.

Basé sur 57 Kbps pour le RTP, vous pouvez produire cette table qui affiche le nombre maximal d'appels qu'un BRI simple peut porter.

Dimension de l'échantillon (octets) PPS cRTP Longueur de paquet (octets) Bande passante (Kbps) Appels par BRI
20 50 Non 66 26.4 2
20 50 Oui 28 11.2 5
30 33 Non 76 20.1 2
30 33 Oui 38 10.0 5
40 25 Non 86 17.2 3
40 25 Oui 48 9.6 5

Cette table affiche une configuration d'échantillon pour la Voix et des données sur les canaux B distincts.

Configuration pour la Voix et données sur des canaux B Separate avec le 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

Voix et données coexistant sur de plusieurs canaux B sans cRTP

Cette conception tire profit du fait qui en date du Logiciel Cisco IOS version 12.2(2)T, vous peut spécifier la bande passante dans le policy-map comme pourcentage au lieu d'un nombre absolu. Cette capacité te permet pour s'appliquer une stratégie de service à un paquet avec de plusieurs canaux B. En conséquence, des paquets de RTP peuvent être portés à travers de plusieurs canaux B. Le compromis est que l'implémentation des plusieurs chemins signifie que le cRTP n'est pas sûr pour utiliser en raison du réarrangement potentiel des paquets de RTP.

Le Cisco IOS fournit deux mécanismes pour que vous contrôliez comment des canaux B supplémentaires sont apportés en réponse à la demande. Le premier mécanisme désigné généralement sous le nom du routage sur demande de cadran (DDR). Le DDR exige d'un seuil de charge d'être spécifié comme fraction de bande passante disponible. Quand la circulation dépasse ce nombre de seuil, un canal supplémentaire est ajouté au paquet. Le seuil est calculé comme moyenne courante, et il y a certain retard à évoquer les canaux B supplémentaires quand le chargement augmente. Ce retard n'est pas un problème avec des données. Cependant, avec la Voix, il n'est pas acceptable si un utilisateur fait un appel téléphonique, et cela prend des minutes pour évoquer la bande passante exigée pour prendre en charge le QoS pour l'appel.

Vous pouvez réduire le retard pour porter les canaux supplémentaires à environ 30 secondes avec la commande de load-interval sur l'interface physique RNIS. Cependant, même 30 secondes est trop longue pour qu'un appel aille sans QoS exigé. La solution est d'avoir la commande de dialer load-threshold réglée à une valeur qui assure la bande passante suffisante dans la réserve pour prendre en charge au moins un appel supplémentaire VoIP avec QoS approprié.

Puisque le problème existe toujours si deux appels sont évoqués dans l'intervalle 30-second, une deuxième et plus robuste solution est préférée. La solution est d'évoquer tous les canaux B immédiatement et de les garder tant que le service RNIS est prié. Vous pouvez utiliser le ppp multilink links minimum de commande de spécifier cette action.

Avec deux canaux B disponibles, la service-stratégie peut maintenant réserver 96 Kbps (75% de 128 Kbps) pour le RTP et la signalisation VoIP. Vous avez besoin de 8 Kbps pour la signalisation VoIP, ainsi ceci laisse 88 Kbps pour le RTP. Basé sur l'utilisation de deux canaux B, cette table affiche le nombre maximal d'appels qui peuvent être portés sur le BRI.

- - -
Dimension de l'échantillon (octets) PPS cRTP Longueur de paquet (octets) Bande passante (Kbps) Appels par BRI
20 50 Non 66 26.4 3
20 50 Oui 28 11.2
30 33 Non 76 20.1 4
30 33 Oui 38 10.0
40 25 Non 86 17.2 5
40 25 Oui 48 9.6

Cette sortie affiche une configuration d'échantillon pour la Voix et les données qui coexistent sur de plusieurs canaux B sans cRTP.

Configuration pour la Voix et données coexistant sur de plusieurs canaux B sans 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

Voix et données coexistant sur de plusieurs canaux B avec le cRTP

Avec l'introduction de MCMP dans la version du logiciel Cisco IOS 12.2(12)T, le cRTP commandant à nouveau la question est résolu, et il est possible d'avoir canaux B d'utilisation de Voix de plusieurs et de faire toujours le cRTP. Les conceptions de bases pour ceci sont identiques à celle discutées dans la Voix et les données coexistant sur de plusieurs canaux B sans section de cRTP, avec la seule différence étant que vous pouvez maintenant activer le cRTP. Cette table ajoute le nombre maximal d'appels qui peuvent être portés sur le BRI, basé sur l'utilisation du cRTP sur deux canaux B.

Dimension de l'échantillon (octets) PPS cRTP Longueur de paquet (octets) Bande passante (Kbps) Appels par BRI
20 50 Non 66 26.4 3
20 50 Oui 28 11.2 7
30 33 Non 76 20.1 4
30 33 Oui 38 10.0 8
40 25 Non 86 17.2 5
40 25 Oui 48 9.6 9

Pour ce scénario la configuration pour la Voix et les données coexistant sur de plusieurs canaux B sans cRTP s'applique. L'exception est que maintenant MCMP est activé et le cRTP est sur quand vous ajoutez cette sortie à l'interface de numérotation.

Configuration multiclasse de ppp multilink d'échantillon

!--- 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

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 25610