Étudions le moteur VoIP Mediastreamer2. Partie 8

Le contenu de cet article est tiré de ma chaîne Zen.

Structure du paquet RTP

Dans le passé, article nous avons réalisé TShark la capture des paquets RTP échangés entre notre récepteur et notre émetteur. Dans cette section, nous allons colorer les éléments du paquet de différentes couleurs et discuter de leur fonction.

Regardons le même paquet, mais avec des champs colorés et des annotations explicatives :

Dans la partie inférieure de la liste, les octets constituant le paquet RTP sont colorés, et celui-ci est à son tour la charge utile du paquet UDP (son en-tête est entouré d'une ligne noire). Les arrière-plans colorés indiquent les octets de l'en-tête RTP, et la zone verte met en évidence le bloc de données qui contient la charge utile du paquet RTP. Les données y sont présentées au format hexadécimal. Dans notre cas, il s'agit d'un signal sonore compressé selon la loi u (loi mu), c'est-à-dire qu'un échantillon a une taille de 1 octet. Étant donné que nous avons utilisé la fréquence d'échantillonnage par défaut (8000 Hz), avec une fréquence de paquets de 50 Hz, chaque paquet RTP doit contenir 160 octets de charge utile. C'est ce que nous allons constater en comptant les octets dans la zone verte, qui devrait contenir 10 lignes.

Selon la norme, la quantité de données dans la charge utile doit être un multiple de quatre, ou en d'autres termes, doit contenir un nombre entier de mots de quatre octets. Si par hasard votre charge utile ne respecte pas cette règle, il faudrait alors ajouter des octets de valeur nulle à la fin de la charge utile et activer le bit Padding (Complément). Ce bit se trouve dans le premier octet de l'en-tête RTP, il est coloré en turquoise. Notez que tous les octets de la charge utile ont une valeur de 0xFF — c'est à quoi ressemble le silence au format u-law.

L'en-tête du paquet RTP est composé de 12 octets obligatoires, mais dans deux cas, il peut être plus long :

• Lorsque le paquet transporte un signal sonore résultant du mélange de signaux provenant de plusieurs sources (flux RTP), une table avec la liste des identifiants de sources dont les charges utiles ont été utilisées pour créer la charge utile de ce paquet est placée après les 12 premiers octets de l'en-tête. Dans ce cas, les quatre bits inférieurs du premier octet de l'en-tête (champ Nombre d'identifiants de sources contributrices) indique le nombre de sources. La taille du champ est de 4 bits, la table peut donc contenir jusqu'à 15 identifiants de sources. Chacun occupe 4 octets. Cette table est utilisée lors de l'organisation de la conférence.

• Lorsque l'en-tête a une extension. Dans ce cas, le premier octet de l'en-tête a un bit défini X. Dans l'en-tête étendu, après la table des participants (s'il y en a), se trouve l'en-tête d'extension d'une taille d'un mot, suivi des mots d'extension. L'extension est un ensemble d'octets que vous pouvez utiliser pour transmettre des données supplémentaires. La norme ne spécifie pas le format de ces données — il peut être quelconque. Par exemple, cela peut être des paramètres supplémentaires pour l'appareil qui reçoit les paquets RTP. Pour certaines applications, des normes d'en-tête étendu ont néanmoins été développées. C'est le cas, par exemple, pour les moyens de communication dans la norme ED-137 (Normes d'interopérabilité pour les composants VoIP ATM).

Examinons maintenant les champs de l'en-tête plus en détail. Ci-dessous, une image canonique de la structure de l'en-tête RTP, que j'ai également coloriée dans les mêmes couleurs.

VER — numéro de version du protocole (version actuelle 2);

redicted Frame) — un drapeau qui est défini dans les cas où le paquet RTP est complété par des octets vides à la fin;

X — un drapeau indiquant que l'en-tête est étendu;

CC — contient le nombre d'identifiants CSRC suivant l'en-tête fixe (après les mots 1..3), dans l'image la table n'est pas montrée;

M — marqueur de début de cadre ou de présence de parole dans le canal (si un détecteur de pauses dans la parole est utilisé). Si le récepteur ne contient pas de détecteur de pauses dans la parole, ce bit doit être constamment défini;

PTYPE — indique le format de la charge utile;

Numéro de séquence — numéro de paquet, utilisé pour restaurer l'ordre de lecture des paquets, car en réalité, il peut y avoir des cas où les paquets atteignent le récepteur dans un ordre différent de celui dans lequel ils ont été envoyés. La valeur initiale doit être aléatoire, cela permet, si le flux RTP est crypté, de rendre son décryptage plus difficile. Ce champ permet également de détecter les paquets manquants;

Horodatage — horodatage. Le temps est mesuré en échantillons de signal, c'est-à-dire que si le paquet contient 160 échantillons, l'horodatage du paquet suivant sera supérieur de 160. La valeur initiale de l'horodatage doit être aléatoire;

SSRC — identifiant de la source du paquet, il doit être unique. Il vaut mieux le générer de manière aléatoire avant de démarrer le flux RTP.

Si vous développez votre propre émetteur ou récepteur de paquets RTP, vous aurez à plusieurs reprises à examiner vos paquets. Pour améliorer votre productivité, je vous recommande de maîtriser l'utilisation du filtrage de paquets dans TShark, cela vous permet de capturer uniquement les paquets qui vous intéressent. Dans un environnement où des dizaines d'appareils RTP fonctionnent, c'est très précieux. Dans la ligne de commande TShark, les paramètres de filtrage sont définis par l'option "-f". Nous avons utilisé cette option lorsque nous souhaitions capturer des paquets du port 8010 :
-f "udp port 8010"
Les paramètres de filtrage sont essentiellement un ensemble de critères auxquels doit correspondre le paquet à "capturer". Une condition peut vérifier l'adresse, le port, la valeur d'un certain octet dans le paquet. Les conditions peuvent être combinées avec des opérations logiques "ET", "OU", etc. C'est un outil très puissant.

Si vous souhaitez visualiser la dynamique des champs dans les paquets, vous devrez dupliquer la sortie TShark dans un fichier, comme cela a été montré dans l'article précédent, en transférant la sortie TShark en entrée tee. Ensuite, en ouvrant le fichier journal avec less, vim ou un autre outil capable de travailler rapidement avec de grands fichiers texte et d'effectuer des recherches de chaînes, vous pourrez comprendre tous les détails du comportement des champs de paquets dans le flux RTP.

Si vous devez écouter le signal transmis par le flux RTP, vous devez utiliser la version TShark avec interface graphique Wireshark. Avec quelques manipulations simples de la souris, vous pouvez écouter et voir l'oscillogramme du signal. Mais à une condition — s'il est codé au format u-law ou a-law.

Dans la prochaine article nous allons créer un dispositif de communication duplex. Munissez-vous de deux casques et d'un interlocuteur.

Source : habr.com