DSP oneagain … exotisme… le CAC / RSVP

Dans un précédent article nous avons vu comment utiliser les DSPs pour la gestion des codecs. Il y a d’autres utilisations un peu plus exotiques qui font aussi partie du “bleu print” du ccie voice :

Le contrôle de flux par RSVP (pour la gestion du CAC: gestion du nombre de communication en fonction de la bande passante disponible et réservée).

Le CUCM lui-même ne peut pas gérer le RSVP, ce protocole ne peut être échangé qu’entre deux passerelles voix. Pour réaliser le contrôle par CUCM, il est nécessaire de mettre en place une terminaison MTP sur les deux passerelles qui doivent être controllées. Elles échangeront le protocole RSVP.

Note : ne cherchez pas ici les configurations sur le CUCM elles feront éventuellement l’objet d’un autre article

Le CUCM va communiquer avec les passerelles en utilisant le protocole classique SCCP (Skinny). Heureusement, le flux n’a pas besoin de transcodage tout se passe dans le logiciel cette configuration ne consomme donc pas de ressources DSP !

Regardons la configuration nécessaire :

dspfarm profile 3 transcode

codec g711a la liste des codecs qui peuvent être controllés

codec g711u

codec g729ab il y a plus de chance de trouver un G729 sur du WAN

rsvp eh oui c’est cette ligne qui change tout !

maximum session software 5

associate application SCCP et ça c’est c’est pour communiquer avec le CUCM

no shut (inspensable)

Nous avons aussi à configurer (je ne présente pas ici le reste de la confguration, voir l’article sur les DSPs):

sccp ccm group1

associate profile 3 register XCDCAFE00000001 <- à votre avis combien de tasse avant le lab. ?

Cette configuration doit être appliquée aussi sur la passerelle distante, parce que le protocole RSVP a lieu entre deux passerelles voix.

Mais attention à ne pas oublier :

Sur chaque interface (dans le DLCI pour une interface Frame-relay):

ip rsvp bandwidth (en théorie : 96 pour G711, 40 pour G729)

en pratique : prévoir un flux de setup et les autres en normal

setup : 40kbps; normal: 24kbps

Pour les 5 flux G729 ont a donc a configurer : 40 + (4*24) = 136 (ip rsvp bandwidth 136)

De même l’utilisation de codec passthrough peut être problémpatique si le négociation des codecs échoue, il faut alors prévoir un codec de repli par exemple G729 …

Vérification :

show dspfarm dsp active : montre les dsp en communication et le type de service (ici transcode)

show ip rsvp reservation : montre l’état de RSVP (source , destination, bande passante)

show ip rsvp installed : montre si la réservation a été faite de manière réussie

debug ip rsvp reservation

debug ip rsvp signaling

Pour finir, comment calculer la bande passante prise par un flux ?

Cela dépend du type de codec et de la fréquence d’envoi des paquets du flux voix RTP. La période d’échantillonage du codec est généralement de 10 ou de 20 millisecondes.

On ne prends pas en compte pour ces calculs de l’overhead de Niveau 2 (ce qui sera nécessaire quand on calculera les bande passante pour la QoS WAN).

Taille entête IP : 20 octets

Taille entête UDP : 12 octets

Taille entête RTP : 8 octets

Total : 40 octets

G711 : (50 paquets par secondes/échantillonnage 20 ms soit 160 octets/paquet )

40 d’entêtes

160 taille en octets des paquets

50 nb de paquets par secondes

8 nb de bits par octets

Pour un total de : (40+160)* 50 * 8 = 80.000 / 80kpbs

G729 : (50 paquets par secondes/échantillonnage 20 ms soit 20 octets/paquet)

(40+20) * 50 * 8 bits = 24.000 bps / 24kbps

Mais dans le cas d’un échantillionnage à 10ms pour le G729

G729 : (100 paquets par secondes/échantillonnage 10 ms soit 10 octets/paquet)

(40+10) * 100 * 8 bits = 40.000 bps / 40kbps

  • LinkedIn
  • MySpace
  • Viadeo
  • Yahoo Bookmarks
  • Facebook
  • Ping
  • Twitter
  • Blogger Post
  • Windows Live Favorites
  • Jamespot
  • Technorati Favorites
  • Yoolink
  • Google Bookmarks
  • Share/Save/Bookmark
This entry was posted in VoIP/ToIP/Collaboration/Social and tagged , , , , . Bookmark the permalink.

Comments are closed.