RTP : protocole de transport - RFC

RFC 3550 page - 6 - Schulzrinne & autrescomposée de trois sessions RTP point à point séparées. Si chaque participant fournit un retour RTCP sur sa réception d'unautre participant aux deux autres participants, la conférence est alors composée d'une session RTP multi-parties. Ce derniercas simule le comportement qui surviendrait avec une communication IP en diffusion groupée entre les trois participants.Le cadre RTP permet les variations définies ici, mais un protocole de contrôle particulier ou un concept d'application vagénéralement imposer des contraintes à ces variations.source de synchronisation (SSRC) : La source d'un flux de paquets RTP, identifiée par un identifiant de SSRC de 32 bitsporté dans l'en-tête RTP de façon à ne pas dépendre de l'adresse réseau. Tous les paquets provenant d'une source desynchronisation font partie du même espace de synchronisation et de numéro de séquence, de sorte qu'un receveur groupeles paquets par source de synchronisation pour la réexécution (play-back). Dans les exemples de source de synchronisationon trouve l'envoyeur d'un flux de paquets dérivés d'une source de signaux comme un microphone ou une caméra, ou unmixeur RTP (voir ci-dessous). Une source de synchronisation peut changer son format de données, par exemple, le codageaudio, au fil du temps. L'identifiant de SSRC est une valeur choisie au hasard destinée à être unique au monde au seind'une session RTP particulière (voir la Section 8). Un participant n'a pas besoin d'utiliser le même identifiant de SSRC pourtoutes les sessions RTP dans une session multimédia ; la liaison des identifiants de SSRC est fournie au moyen de RTCP(voir au paragraphe 6.5.1). Si un participant génère plusieurs flux dans une seule session RTP, par exemple à partir dedifférentes caméras vidéo, chacun DOIT être identifié par un SSRC différent.source contributive (CSRC) : Une source d'un flux de paquets RTP qui a contribué au flux combiné produit par un mixeurRTP (voir ci-dessous). Le mixeur insère une liste des identifiants de SSRC des sources qui ont contribué à la générationd'un paquet particulier dans l'en-tête RTP de ce paquet. Cette liste est appelée liste de CSRC. Un exemple d'applicationserait une conférence audio où un mixeur indique tous les orateurs dont le discours est combiné pour produire le paquetsortant, permettant au receveur d'indiquer l'orateur actuel, même si tous les paquets audio contiennent le même identifiantde SSRC (celui du mixeur).système terminal : Une application qui génère le contenu à envoyer dans les paquets RTP et/ou consomme le contenu despaquets RTP reçus. Un système terminal peut agir comme une ou plusieurs sources de synchronisation dans une sessionRTP particulière, mais normalement comme une seule.mixeur : Un système intermédiaire qui reçoit des paquets RTP d'une ou plusieurs sources, change éventuellement le formatdes données, combine les paquets d'une certaine manière puis transmet un nouveau paquet RTP. Comme la synchronisationentre ces sources d'entrées multiples ne sera généralement pas assurée, le mixeur va faire les ajustements desynchronisation entre les flux et générer sa propre synchronisation du flux combiné. Et donc, tous les paquets de donnéesoriginaires d'un mixeur seront identifiés comme ayant le mixeur comme source de synchronisation.traducteur : Un système intermédiaire qui transmet les paquets RTP avec leur identifiant de source de synchronisationintact. Comme exemples de traducteurs on a des appareils qui convertissent les codages sans mixage, des duplicateurs dediffusion groupée en envoi individuel, et des filtres de niveau application dans les pare-feu.Moniteur : Une application qui reçoit les paquets RTCP envoyés par les participants dans une session RTP, en particulierles rapports de réception, et estime la qualité de service actuelle pour la distribution de la surveillance, des diagnostics defautes et des statistiques à long terme. La fonction de surveillance sera vraisemblablement construite dans la ou lesapplications participant à la session, mais peut aussi être une application distincte qui ne participe pas par ailleurs etn'envoie ni ne reçoit de paquets de données RTP (puisque elle est sur un accès séparé). Ceux-ci sont appelés des moniteurstiers. On peut aussi accepter qu'un moniteur tiers reçoive les paquets de données RTP mais n'envoie pas de paquets RTCPou ne soit pas autrement compté dans la session.moyens non RTP : Les protocoles et mécanismes qui peuvent être nécessaires en plus de RTP pour fournir un serviceutilisable. En particulier, pour les conférences multimédia, un protocole de contrôle peut distribuer des adresses dediffusion groupée et des clés de chiffrement, négocier l'algorithme de chiffrement à utiliser, et définir les transpositionsdynamiques entre les valeurs de type de charge utile RTP et les formats de charge utile qu'elles représentent pour lesformats qui n'ont pas une valeur prédéfinie de type de charge utile. Des exemples de tels protocoles sont le protocoled'initialisation de session (SIP) (RFC 3261 [13]), la Recommandation UIT-T H.323 [14] et les applications qui utilisentSDP (RFC 2327 [15]), telles que RTSP (RFC 2326 [16]). Pour les applications simples, la messagerie électronique ou unebase de données de conférence peuvent aussi être utilisées. La spécification de tels protocoles et mécanismes sort dudomaine d'application du présent document.4. Ordre des octets, alignement, et format de l'heureTous les champs d'entiers sont portés dans l'ordre des octets du réseau, c'est-à-dire, l'octet de plus fort poids en premier. Cet