Groupe de travail Réseau	J. Lennox,Vidyo	
Request for Comments : 5576	J. Ott, Helsinki University of Technology	
Catégorie : Sur la voie de la normalisation	T. Schierl, Fraunhofer HHI	
Traduction Claude Brière de L'Isle	juin 2009	

Attributs de supports spécifiques de source dans le protocole de description de session (SDP)

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. 

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.

Résumé
Le protocole de description de session (SDP, Session Description Protocol) fournit des mécanismes pour décrire les attributs des sessions multimédia et des flux de supports individuels (par exemple, des sessions du protocole de transport en temps réel (RTP, Real-time Transport Protocol)) au sein d'une session multimédia, mais ne fournit aucun mécanisme pour décrire les sources individuelles de supports au sein d'un flux de supports. Le présent document définit un mécanisme pour décrire les sources de supports RTP, qui sont identifiées par leurs identifiants de source de synchronisation (SSRC, Synchronization Source) dans SDP, pour associer les attributs à ces sources, et pour exprimer les relations entre les sources.  Il définit aussi plusieurs attributs de niveau source qui peuvent être utilisés pour décrire les propriétés des sources des supports.
Table des matières
1. Introduction	2
2. Terminologie	2
3. Vue d'ensemble	2
4. Attributs de support	3
4.1 Attribut de support "ssrc"	3
4.2 Attribut de support "ssrc-group"	4
5. Usage des identifiants de source identifiés dans RTP	4
6. Attributs de source	5
6.1 Attribut de source "cname"	5
6.2 Attribut de source "previous-ssrc"	6
6.3 Attribut de source "fmtp"	6
6.4 Autres attributs de source	6
7. Exemples	6
8. Usage avec le modèle d'offre/réponse	7
9. Rétro compatibilité	7
10. Grammaire formelle	8
11. Considérations sur la sécurité	9
12. Considérations relatives à l'IANA 	9
12.1 Nouveaux attributs SDP de niveau support	9
12.2 Registre des attributs de niveau source	9
12.3 Registre des sémantiques de groupement de source	10
13. Références	10
13.1 Références normatives	10
13.2 Références pour information 	11
Adresse des auteurs	11

 	1.	Introduction

Le protocole de description de session (SDP, Session Description Protocol) fournit des mécanismes pour décrire les attributs des sessions multimédia et les flux de supports (par exemple, des sessions du protocole de transport en temps réel (RTP, Real-time Transport Protocol) [RFC3550]) au sein d'une session multimédia, mais ne fournit aucun mécanisme pour décrire les sources individuelles de supports au sein d'un flux de supports.

Plusieurs protocoles récemment proposés, notamment la diffusion groupée RTP d'une seule source [RFC5760], ont trouvé utile de décrire des sources de support spécifiques dans les messages SDP. La diffusion groupée d'une seule source, en particulier, a besoin de s'assurer que les identifiants de source de synchronisation (SSRC, Synchronization Source) RTP des receveurs n'entrent pas en collision avec ceux des envoyeurs des supports, car la spécification RTP [RFC3550] exige que les sources en collision changent leurs valeurs de SSRC après la détection d'une collision. Des travaux antérieurs ont utilisé des mécanismes spécifiques de chaque protocole pour décrire les sources individuelles d'une session RTP.

De plus, alors que le protocole de transport en temps réel (RTP, Real-time Transport Protocol) [RFC3550] est défini comme permettant plusieurs sources dans une session RTP (par exemple, si un utilisateur a plus d'une caméra) SDP n'a pas de mécanisme existant pour qu'un point d'extrémité indique qu'il va utiliser plusieurs sources ou pour décrire leurs caractéristiques individuelles.

Pour traiter ces problèmes, le présent document définit un mécanisme pour décrire les sources RTP, identifiées par leur identifiant de source de synchronisation (SSRC) dans SDP, pour associer des attributs à ces sources, et pour exprimer les relations entre les sources individuelles. Il définit aussi un certain nombre de nouveaux attributs SDP qui s'appliquent aux sources individuelles (attributs de "niveau source") décrit comment un certain nombre d'attributs de flux de supports existants ("niveau support") peuvent aussi être appliqués au niveau de la source, et établit des registres de l'IANA pour les attributs de niveau source et la sémantique du groupement de sources.

 	2.	Terminologie

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans la [RFC2119] et indiquent les niveaux d’exigence pour les mises en œuvre conformes.

 	3.	Vue d'ensemble

Dans le protocole de transport en temps réel (RTP) [RFC3550], une association entre un groupe de participants communicants est appelée une session RTP. Une session RTP est normalement associée à une seule adresse de transport (dans le cas de diffusion groupée) ou flux de communication (dans le cas d'envoi individuel) bien que des traducteurs RTP et la diffusion groupée à une seule source [RFC5760] puissent rendre la situation plus complexe. Les topologies RTP sont discutées plus en détails dans la [RFC5117].

Dans une session RTP, la source d'un seul flux de paquets RTP est appelée une source de synchronisation (SSRC). Chaque source de synchronisation est identifiée par un identifiant numérique de 32 bits. De plus, les receveurs (qui ne peuvent jamais envoyer de paquets RTP) ont aussi des identifiants de source, qui sont utilisés pour identifier leurs rapports et autres messages de rétroaction de receveur du protocole de contrôle de RTP (RTCP).

Les messages du protocole de description de session (SDP) [RFC4566], appelés des descriptions de session, décrivent des sessions multimédia. Une session multimédia est un ensemble de d'envoyeurs et receveurs multimédia ainsi que de flux de données s'écoulant des envoyeurs aux receveurs. Une session multimédia contient un certain nombre de flux de supports, qui sont les sessions RTP individuelles ou autres chemins des supports sur lesquels un type de données multimédia est porté. Les informations qui s'appliquent à une session multimédia entière sont appelées des informations de niveau session, tandis que les informations qui relèvent d'un flux de supports sont appelée des informations de niveau support. La collection de toutes les informations qui décrivent un flux de supports est appelée une description de support. (Les descriptions de supports sont aussi parfois appelées de façon informelle des lignes "m" SDP, d'après la syntaxe SDP qui commence une description de support.) Plusieurs éléments d'information standard sont définis au niveau session et au niveau support. Des informations étendues peuvent être incluses aux deux niveaux par l'utilisation d'attributs.

(Le terme "flux de supports" n'apparaît pas dans la spécification SDP elle-même, mais est utilisé par un certain nombre d'extensions à SDP, par exemple, l'établissement de connexité interactive (ICE, Interactive Connectivity Establishment) [RFC5245], pour noter l'objet décrit par une description de support SDP. Ce terme est malheureusement un peu trompeur, parce que la spécification RTP [RFC3550] utilise le terme "flux de supports" pour se référer à un flux de source de support individuel ou flux de paquets RTP, identifié par un SSRC, tandis qu'un flux de supports SDP décrit une session RTP entière, qui peut contenir un nombre quelconque de sources RTP. Dans le présent document, le terme "flux de supports" signifie un flux de supports SDP, c'est-à-dire, la chose décrite par une description de supports SDP, tandis que "source de supports" est utilisé pour une seule source de paquets de supports, c'est-à-dire, un flux de supports RTP.)

Le cœur de la spécification SDP n'a aucun moyen de décrire les sources de supports individuelles, en particulier les sources de synchronisation RTP, au sein d'un flux de supports. Pour traiter ce problème, on introduit dans le présent document un troisième niveau d'informations, appelé les informations de niveau source. Syntaxiquement, les informations de niveau source sont décrites par un nouvel attribut SDP de niveau support, "ssrc", qui identifie des sources de synchronisation spécifiques au sein d'une session RTP et agit comme informations de niveau source de transposition de méta-attribut pour ces sources.

Le présent document définit aussi un attribut SDP de niveau support, "ssrc-group", qui peut représenter les relations entre les sources de supports au sein d'une session RTP à peu près de la même façon que l'attribut "group" [RFC3388] représente les relations entre les flux de supports au sein d'une session multimédia.

 	4.	Attributs de support

Cette section définit deux attributs de niveau support, "ssrc" et "ssrc-group".

 	4.1	Attribut de support "ssrc"
a=ssrc:<ssrc-id> <attribut>
a=ssrc:<ssrc-id> <attribut>:<valeur>

L'attribut de support SDP "ssrc" indique une propriété (appelée un "attribut de niveau source") d'une source de supports (flux RTP) au sein d'une session RTP. <ssrc-id> est l'identifiant de source de synchronisation (SSRC) de la source décrite, interprétée comme un entier non signé de 32 bits dans l'ordre des octets du réseau et représenté en décimal. <attribut> ou <attribut>:<valeur> représente l'attribut de niveau source spécifique de la source de supports donnée. L'attribut de niveau source suit la syntaxe de ligne "a=" SDP. Il consiste donc soit en un seul nom d'attribut (un fanion) soit en un nom et valeur d'attribut, par exemple, "cname:user@exemple.com". Aucun attribut du premier type n'est défini par le présent document.

Au sein d'un flux de supports, les attributs "ssrc" avec la même valeur de <ssrc-id> décrivent les différents attributs des mêmes sources de supports. À travers un flux de supports, les valeurs de <ssrc-id> ne sont pas corrélées (sauf si la corrélation est indiquée par le groupement de flux de supports ou quelque autre mécanisme) et PEUVENT être répétées.

Chaque attribut de support "ssrc" spécifie un seul attribut de niveau source pour le <ssrc-id> donné. Pour chaque source mentionnée dans SDP, l'attribut de niveau source "cname", défini au paragraphe 6.1, DOIT être fourni. Un nombre quelconque d'autres attributs de niveau source pour la source PEUT aussi être fourni.

L'attribut de support "ssrc" PEUT être utilisé pour tout transport de supports fondé sur RTP. Il n'est pas défini pour d'autres transports.

Si d'autres attributs SDP mentionnent aussi des valeurs de SSRC RTP (par exemple, du chiffrement Internet multimédia (MIKEY, Multimedia Internet KEYing) [RFC3830], [RFC4567]) les valeurs utilisées DOIVENT être cohérentes. (Ces attributs PEUVENT fournir des informations supplémentaires sur une source décrite par un attribut "ssrc" ou PEUVENT décrire des sources supplémentaires.)

Bien que les attributs de niveau source spécifiés par la propriété ssrc suivent la même syntaxe que les attributs de niveau session et supports, ils sont définis de façon indépendante. Tous les attributs de niveau source DOIVENT être enregistrés auprès de l'IANA, en utilisant le registre défini au paragraphe 12.2.

La Figure 4 de la Section 10 donne une grammaire formelle en forme Backus-Naur augmenté (ABNF) [RFC5234] pour l'attribut "ssrc".

L'attribut de support "ssrc" ne dépend pas du jeu de caractères.

 	4.2	Attribut de support "ssrc-group"
a=ssrc-group:<semantics> <ssrc-id> ...

L'attribut de support SDP "ssrc-group" exprime une relation entre plusieurs sources d'une session RTP. Il est analogue à l'attribut "group" de niveau session [RFC3388], qui exprime une relation entre les flux de supports dans une session SDP multimédia (c'est-à-dire, une relation entre plusieurs sessions RTP en relation logique). Comme les sources sont déjà identifiées par leurs identifiants SSRC, aucune propriété analogue à l'attribut "mid" n'est nécessaire ; les groupes de sources sont identifiés directement par leurs identifiants de SSRC.

Le paramètre <semantics> est tiré de la spécification de l'attribut "group" [RFC3388]. Les valeurs initiales de sémantique définies pour l'attribut "ssrc-group" sont FID (Identification de flux) [RFC3388] et correction d'erreur directe (FEC, Forward Error Correction) [RFC4756]. Dans chaque cas, la relation entre les sources groupées est la même que la relation entre les sources correspondantes dans les flux de supports groupés en utilisant l'attribut SDP "group".

Bien que les valeurs de sémantique de "ssrc-group" suivent la même syntaxe que les valeurs de sémantique de "group", elles sont définies indépendamment. Toutes les valeurs de sémantique de "ssrc-group" DOIVENT être enregistrées auprès de l'IANA, en utilisant le registre défini au paragraphe 12.3.

(Les autres sémantiques de "group" enregistrées par l'IANA au moment de la rédaction du présent mémoire ne sont pas utiles pour le groupement de sources. La synchronisation de lèvres (LS, Lip Synchronization) [RFC3388] est redondante pour les sources au sein d'un flux de supports car les sources RTP avec le même CNAME sont implicitement synchronisées dans RTP. La réservation d'un seul flux (SRF, Single Reservation Flow) [RFC3524] et les types d'adresse de réseau de remplacement (ANAT, Alternative Network Address Types) [RFC4091] se réfèrent spécifiquement aux caractéristiques de transport du flux de supports. Une session composite (CS, Composite Session) [FLUTE] est utilisée pour grouper des sessions FLUTE, et donc n'est pas applicable à RTP.)

L'attribut "ssrc-group" indique les sources dans un groupe en faisant la liste des <ssrc-id> des sources dans le groupe. Il DOIT mentionner au moins un <ssrc-id> pour un groupe et PEUT en mentionner un nombre quelconque en plus. Chaque <ssrc-id> mentionné dans un attribut "ssrc-group" DOIT être défini par une ligne "ssrc:" correspondante dans la même description de supports.

L'attribut de support "ssrc-group" ne dépend pas du jeu de caractères.

La Figure 5 de la Section 10 donne la grammaire formelle en format Backus-Naur augmenté (ABNF) [RFC5234] pour l'attribut "ssrc-group".

 	5.	Usage des identifiants de source identifiés dans RTP

Les identifiants de source de synchronisation utilisés dans une session RTP sont choisis au hasard et indépendamment par les points d'extrémité. À ce titre, il est possible que deux points d'extrémité RTP choisissent le même identifiant de SSRC. Bien que cette probabilité soit faible, la spécification de RTP [RFC3550] exige que tous les points d'extrémité RTP DOIVENT être prêts à détecter et résoudre les collisions.

Par suite, tous les points d'extrémité DOIVENT être prêts au fait que les informations sur les sources spécifiques identifiées dans un flux de supports pourraient être périmées. Le lien réel entre les SSRC et les CNAME de source peut seulement être identifié par les paquets RTCP de description de source (SDES) transmis sur la session RTP.

Quand les points d'extrémité choisissent leurs propres valeurs de SSRC locales pour les flux de supports pour lesquels des attributs de niveau source ont été spécifiés, ils NE DOIVENT PAS utiliser pour eux-mêmes les identifiants de SSRC mentionnés dans les descriptions de supports qu'ils ont reçu pour le flux de supports.

Cependant, les sources identifiées par des attributs SDP de niveau source n'affectent pas autrement la logique de transport RTP. Spécifiquement, les sources qui sont seulement connues par SDP, pour lesquelles des paquets ni RTP ni RTCP n'ont été reçus, NE DOIVENT PAS être comptées pour l'estimation de taille de groupe RTP, et des blocs de rapport NE DOIVENT PAS être envoyés pour eux dans les messages SR ou RR de RTCP.

Les points d'extrémité NE DOIVENT PAS supposer que seules les sources mentionnées dans SDP vont être présentes dans une session RTP ; des sources supplémentaires, avec des identifiants de SSRC non mentionnés précédemment, peuvent être ajoutées à tout moment, et les points d'extrémité DOIVENT être prêts à recevoir des paquets provenant de ces sources. (On ne spécifie pas ici comment les points d'extrémité traitent de tels paquets ; ils DEVRAIENT être traités de la même manière que les paquets provenant de sources supplémentaires seraient traités si le point d'extrémité n'avait pas reçu du tout d'attributs "a=ssrc:".)

Un point d'extrémité qui observe une collision de SSRC entre sa source explicitement signalée et une autre entité qui n'a pas explicitement signalé une SSRC PEUT retarder ses actions de collision-résolution RTP [RFC3550] de 5*1,5*Td, où Td est l'intervalle déterministe calculé de rapport pour les receveurs défini au paragraphe 6.3.1 de la spécification RTP [RFC3550], pour voir si le conflit existe toujours. (Cela donne la préséance aux sources explicitement signalées et place la charge de la résolution de collision sur les sources non signalées.) Les collisions de SSRC entre plusieurs sources explicitement signalées DOIVENT cependant faire l'objet d'une action immédiate.

Si, suivant les procédures de collision-résolution de RTP [RFC3550], une source identifiée par des attributs de niveau source a été forcée de changer son identifiant de SSRC, l'auteur du SDP contenant les attributs de niveau source pour ces sources DEVRAIT envoyer une description de session SDP mise à jour avec la nouvelle SSRC si le mécanisme par lequel SDP est distribué pour la session multimédia a un mécanisme pour distribuer le SDP mis à jour. Ce SDP mis à jour DOIT inclure un attribut de niveau source "previous-ssrc", décrit au paragraphe 6.2, faisant la liste des identifiants de SSRC précédents de la source. (Si une seule source avec un certain CNAME a une collision, les autres membres de la session RTP peuvent déduire une correspondance entre l'ancien et le nouvel identifiant de SSRC de la source sans exiger de mise à jour de description de session. Cependant, si plusieurs sources sont en collision à la fois, ou si des sources quittent et se joignent, cette déduction n'est pas possible. Pour éviter la confusion, l'envoi de messages SDP mis à jour est donc toujours RECOMMANDÉ.)

Les points d'extrémité NE DOIVENT PAS réutiliser le même identifiant de SSRC pour identifier des sources avec le même CNAME pendant au moins la durée de l'intervalle de temporisation de participant de la session RTP (voir le paragraphe  6.3.5 de la [RFC3550]). Ils NE DEVRAIENT PAS réutiliser d'identifiant de SSRC déjà mentionné dans SDP (soit par eux mêmes, soit par d'autres points d'extrémité) pour la durée de vie entière de la session RTP.

Les points d'extrémité DOIVENT être prêts à la possibilité que d'autres parties à la session ne comprennent pas les attributs SDP de niveau source, sauf si un mécanisme de niveau supérieur les exige normativement. Voir la Section 9 pour la discussion de ce point.

 	6.	Attributs de source

Cette Section décrit les attributs spécifiques de source qui peuvent être appliqués aux sources RTP.

 	6.1	Attribut de source "cname"
a=ssrc:<ssrc-id> cname:<cname>

L'attribut de source "cname" associe une source de supports à son élément de description de source (SDES, Source Description) d'identifiant canonique de point d'extrémité (CNAME, Canonical End-Point Identifier). Ce DOIT être la valeur de CNAME que l'envoyeur des supports va placer dans ses paquets de SDES RTCP ; il DOIT donc suivre les conventions de syntaxe de CNAME définies dans la spécification RTP [RFC3550]. Si un participant à la session reçoit un paquet de SDES RTCP qui associe cette SSRC à un CNAME différent, il DEVRAIT supposer qu'il y a eu une collision de SSRC et que la description de la source qui était portée dans la description SDP n'est pas applicable à la source réelle reçue. Il est EXIGÉ que cet attribut de source soit présent si des attributs de source sont présents pour une source. L'attribut "cname" NE DOIT PAS apparaître plus d'une fois pour le même ssrc-id au sein d'un flux de supports donné.

L'attribut de source "cname" ne dépend pas du jeu de caractères.

La Figure 6 de la Section 10 donne la grammaire formelle en format Backus-Naur augmenté (ABNF) [RFC5234] pour l'attribut "cname".

 	6.2	Attribut de source "previous-ssrc"
a=ssrc:<ssrc-id> previous-ssrc:<ssrc-id> ...

L'attribut de source "previous-ssrc" associe une source de supports aux précédents identifiants de source utilisés pour la même source de supports. Suite à un changement de SSRC dû à une collision de SSRC impliquant une source de supports décrite dans SDP, la description de session mise à jour qui décrit la nouvelle SSRC de la source (décrite à la Section 5) DOIT inclure l'attribut "previous-ssrc" qui associe la nouvelle SSRC à  l'ancienne. Si d'autres descriptions SDP mises à jour sont publiées qui décrivent la  source de supports, l'attribut "previous-ssrc" DEVRAIT être inclus si la description de session a été générée avant la fin de temporisation de participant de l'ancienne SSRC, et PEUT être incluse après ce moment. Cet attribut, si il est présent, DOIT mentionner au moins une SSRC précédente et PEUT mentionner un nombre quelconque de SSRC supplémentaires pour la source si celle-ci a connu plusieurs collisions. Cet attribut DOIT être présent seulement une fois pour chaque source.

L'attribut de source "previous-ssrc" ne dépend pas du jeu de caractères.

La Figure 7 de la Section 10 donne la grammaire formelle en format Backus-Naur augmenté (ABNF) [RFC5234] pour l'attribut previous-ssrc.

 	6.3	Attribut de source "fmtp"
a=ssrc:<ssrc> fmtp:<format> <paramètres spécifiques du format>

L'attribut de source "fmtp" permet que des paramètres spécifiques du format soient portés sur une source donnée. Le paramètre <format> DOIT être un des formats du support (c'est-à-dire, des types de charge utile RTP) spécifiés pour le flux de supports. La signification de <paramètres spécifiques du format> est unique pour chaque type de support. Ce paramètre DOIT seulement être utilisé pour les types de supports pour lesquels des paramètres de format de niveau source ont été explicitement spécifiés ; les paramètres de format de niveau support NE DOIVENT PAS être portés aveuglément.

L'attribut de source "fmtp" ne dépend pas du jeu de caractères.

 	6.4	Autres attributs de source
Le présent document définit seulement les attributs de source qui sont nécessaires ou utiles pour qu'un point d'extrémité décode et rende les sources dans un flux de supports. Il n'inclut pas d'attributs qui contribueraient à la décision d'un point d'extrémité d'accepter ou rejeter un flux, par exemple, dans un échange d'offre/réponse. De tels attributs seront considérés à l'avenir.

 	7.	Exemples

Cette section donne plusieurs exemples de descriptions SDP de sessions de supports contenant des attributs de source. Pour faire court, seules les sections de supports des descriptions sont données.

m=audio 49168 RTP/AVP 0
a=ssrc:314159 cname:user@exemple.com

Figure 1 : Exemple de déclaration d'une seule source de synchronisation

L'exemple de la Figure 1 montre un flux audio annonçant une seule source.

m=video 49170 RTP/AVP 96
a=rtpmap:96 H264/90000
a=ssrc:12345 cname:another-user@exemple.com
a=ssrc:67890 cname:another-user@exemple.com

Figure 2 : Exemple de flux de supports contenant plusieurs sources indépendantes d'un seul membre de session

L'exemple de la Figure 2 montre un flux vidéo où un participant (identifié par un seul CNAME) a plusieurs caméras. Les sources pourraient être plus distinguées par des informations de description de source (SDES) RTCP.

m=video 49174 RTP/AVPF 96 98
a=rtpmap:96 H.264/90000
a=rtpmap:98 rtx/90000
a=fmtp:98 apt=96;rtx-time=3000
a=ssrc-group:FID 11111 22222
a=ssrc:11111 cname:user3@exemple.com
a=ssrc:22222 cname:user3@exemple.com
a=ssrc-group:FID 33333 44444
a=ssrc:33333 cname:user3@exemple.com
a=ssrc:44444 cname:user3@exemple.com

Figure 3 : Exemple des relations entre plusieurs sources de retransmission

Les exemples de la Figure 3 montrent comment les relations entre les sources utilisées pour la retransmission RTP [RFC4588] peuvent être signalées explicitement. Cela prévient la complexité de l'association des sources originales avec les sources de retransmission quand le multiplexage de SSRC est utilisé pour la retransmission RTP, comme décrit au paragraphe 5.3 de la [RFC4588].

 	8.	Usage avec le modèle d'offre/réponse

Quand ils sont utilisés avec le modèle SDP d'offre/réponse [RFC3264], les attributs SDP spécifiques de source décrivent seulement les sources que chaque partie veut envoyer (qu'elle envoie des données RTP ou des blocs de rapport RTCP). Aucun mécanisme n'est fourni par lequel une réponse peut accepter ou rejeter des sources individuelles au sein d'un flux de supports ; si l'ensemble de sources dans un flux de supports est inacceptable, la seule option du répondeur est de rejeter le flux de supports ou la session multimédia entière.

Les identifiants de SSRC pour les sources décrites par une réponse SDP DOIVENT être distincts des identifiants de SSRC pour les sources de ce flux de supports dans l'offre. De même, les nouveaux identifiants de SSRC dans une mise à jour d'offre DOIVENT être distincts des identifiants de SSRC pour ce flux de supports établis dans le plus récent échange d'offre/réponse pour la session et DEVRAIENT être distincts de tout identifiant de SSRC déjà utilisé par une partie au sein de la session multimédia (qu'il soit ou non encore utilisé).

 	9.	Rétro compatibilité

Conformément à la définition de SDP, les interpréteurs de descriptions de session SDP ignorent les attributs inconnus. Donc, les points d'extrémité DOIVENT être prêts à ce que les receveurs de leur session de supports RTP ne puissent pas comprendre leurs descriptions de source explicites, sauf si un mécanisme externe indique qu'ils ont été compris. Dans certains cas (comme de retransmission RTP [RFC4588]) cela peut contraindre des choix sur les flux binaires qui sont transmis.

Les descriptions de sources sont spécifiées dans le présent document de telle façon que les points d'extrémité RTP qui sont conformes à la spécification RTP [RFC3550] soient capables de décoder les flux de supports qu'ils décrivent, qu'ils prennent en charge ou non les descriptions de source explicites. Cependant, certaines mises en œuvre déployées de RTP ne peuvent pas en fait prendre en charge plusieurs sources de supports dans un flux de supports. Les envoyeurs de supports PEUVENT souhaiter se restreindre à une seule source à la fois sauf si ils ont des moyens de conclure que les receveurs du flux de supports prennent en charge le multiplexage de sources.

 	10.	Grammaire formelle

Cette section donne une grammaire formelle en format Backus-Naur augmenté (ABNF) [RFC5234] pour chaque nouveau support et attributs de source définis dans le présent document. Les grammaires pour les attributs existants de session ou supports qui ont été étendus pour être des attributs de source ne sont pas inclus.

La redistribution et l'utilisation en forme source et binaire, avec ou sans modification, sont permises pourvu que les conditions suivantes soient satisfaites :
o	Les redistributions de code source doivent conserver la notice de droits de reproduction ci-dessus, cette liste de conditions et le déclinatoire de responsabilité qui suit.
o	Les redistributions en forme binaire doivent reproduire la notice de droits de reproduction ci-dessus, cette liste de conditions et le déclinatoire de responsabilité qui suit dans la documentation et/ou autres matériaux fournis avec la distribution.
o	Ni le nom de la Internet Society, de l'IETF ou de l'IETF Trust, ni les noms des contributeurs spécifiques, ne peuvent être utilisés pour avaliser ou promouvoir des produits dérivés de ce logiciel sans permission écrite spécifique préalable.

Ce logiciel est fourni par les détenteurs du droit de reproduction et les contributeurs "TEL QUEL" et toutes garanties expresses ou implicites, incluant, sans s'y limiter, les garanties implicites de commercialisabilité et de convenance à un objet particulier sont déclinées. En aucun cas les détenteurs du droit de reproduction et les contributeurs ne seront responsables de dommages directs, indirects, incidents, spéciaux, exemplaires, ou consécutifs (incluant, sans s'y limiter, la fourniture de biens ou services de substitution, perte d'usage, données, ou profits, ou interruption d'affaires) cependant causés, et aucune théorie de responsabilité, contractuelle, stricte, ou pour tort (incluant la négligence ou autrement) survenant d'une façon quelconque de l'utilisation de ce logiciel, même si on est avisé de la possibilité de tels dommages.

ssrc-attr = "ssrc:" ssrc-id SP attribute
; La définition de base de "attribute" est dans la RFC 4566.
; (C'est le contenu des lignes "a=".)

ssrc-id = entier	; 0 .. 2**32 - 1

attribute =/ ssrc-attr

Figure 4 : Syntaxe de l'attribut de support "ssrc"

ssrc-group-attr = "ssrc-group:" semantics *(SP ssrc-id)

semantics = "FEC" / "FID" / jeton
; correspond à la définition de la RFC 3388 et aux règles d'enregistrement de l'IANA dans ce document.

jeton = <comme défini dans la RFC 4566>

attribute =/ ssrc-group-attr

Figure 5 : Syntaxe de l'attribut de support "ssrc-group"

cname-attr = "cname:" cname

cname = octet-string
; Suivant les conventions de syntaxe pour CNAME comme défini dans la RFC 3550.
; La définition de "octet-string" est dans la RFC 4566.

attribute =/ cname-attr

Figure 6 : Syntaxe de l'attribut de support "cname"

previous-ssrc-attr = "previous-ssrc:" ssrc-id *(SP ssrc-id)

attribute =/ previous-ssrc-attr

Figure 7 : Syntaxe de l'attribut de support "previous-ssrc"

 	11.	Considérations sur la sécurité

Toutes les implications de sécurité de RTP [RFC3550] et de SDP [RFC4566] s'appliquent. Décrire explicitement les sources multiplexées d'un flux de supports RTP ne paraît pas ajouter de problème de sécurité supplémentaire.

 	12.	Considérations relatives à l'IANA 
 	12.1	Nouveaux attributs SDP de niveau support
Le présent document définit deux attributs SDP de niveau support : "ssrc" et "ssrc-group". Ces attributs ont été enregistrés par l'IANA dans le registre "Paramètres du protocole de description de session (SDP)" sous "att-field (seulement niveau support)".

L'attribut "ssrc" est utilisé pour identifier les caractéristiques des sources de supports au sein d'un flux de supports. Son format est défini au paragraphe 4.1.

L'attribut "ssrc-group" est utilisé pour identifier les relations entre les sources de supports au sein d'un flux de supports. Son format est défini au paragraphe 4.2.

 	12.2	Registre des attributs de niveau source
La présente spécification crée un nouveau registre IANA appelé "att-field (niveau source)" au sein du registre des paramètres SDP. Les attributs de source DOIVENT être enregistrés auprès de l'IANA et documentés selon les mêmes règles que pour les attributs SDP de niveau session et de niveau support comme spécifié dans la [RFC4566].

Les enregistrements de nouveaux attributs sont acceptés selon la politique de "spécification exigée" de la [RFC5226], pourvu que la spécification inclue les informations suivantes :
o	Nom du contact, adresse de messagerie, et numéro de téléphone,
o	Nom d'attribut (comme il va apparaître dans SDP)
o	Forme longue du nom d'attribut en anglais,
o	Si la valeur de l'attribut est sujette à l'attribut "charset",
o	Un paragraphe d'explication de l'objet de l'attribut,
o	Une spécification des valeurs d'attribut appropriées pour cet attribut.

Ceci est le minimum que l'IANA va accepter. L'expert réviseur va déterminer si les attributs proposés sont supposés avoir un usage et une interopérabilité étendus ; dans ce cas, les attributs DOIVENT être spécifiés dans une RFC sur la voie de la normalisation.

Les soumetteurs d'enregistrements devraient s'assurer que la spécification est dans l'esprit des attributs SDP, et en particulier que l'attribut est indépendant de la plate-forme au sens où il ne fait pas d'hypothèses implicites sur les systèmes d'exploitation et ne désigne pas des éléments spécifiques de logiciel d'une manière qui pourrait empêcher l'interopérabilité.
Les attributs de niveau source qui sont substantiellement similaires sémantiquement à des attributs existants de niveau session ou de niveau support DEVRAIENT réutiliser le même nom d'attribut que celui des attributs de niveau session ou de niveau support. Les attributs de niveau source NE DEVRAIENT PAS réutiliser des noms d'attribut de niveau session ou de niveau support qui sont sans relation ou substantiellement différents.

L'ensemble initial des noms d'attribut de source, dont les définitions sont à la Section 6 du présent document, est dans la Figure 8.

Type	Nom SDP	Référence
att-field (niveau source)	cname	[RFC5576]
	previous-ssrc	[RFC5576]
	fmtp	[RFC5576]

Figure 8 : Contenu initial du registre des Attributs de source de l'IANA

 	12.3	Registre des sémantiques de groupement de source
La présente spécification crée un nouveau registre de l'IANA appelé "Sémantique pour l'attribut SDP "ssrc-group"" au sein du registre des paramètres SDP. La sémantique du groupe de source DOIT être définie dans une RFC sur la voie de la normalisation, selon les mêmes règles que dans la [RFC3388].

La section Considérations relatives à l'IANA de la RFC DOIT inclure les informations suivantes, qui apparaissent dans le registre IANA avec le numéro de RFC de la publication :
o	Une brève description de la sémantique.
o	Le jeton à utiliser dans l'attribut de groupe. Ce jeton peut être d'une longueur quelconque, mais DEVRAIT ne pas faire plus de quatre caractères.
o	Une référence à une RFC sur la voie de la normalisation.

Les valeurs de sémantique de groupe de source qui sont substantiellement similaires à des valeurs existantes de sémantique de groupe de supports DEVRAIENT réutiliser le même nom de sémantique que dans ces sémantiques de groupe de supports. La sémantique de groupe de sources NE DEVRAIT PAS réutiliser les noms de sémantique de groupement de source qui sont sans relation ou substantiellement différents.

L'ensemble initial de valeurs de sémantique de groupement de source, pour les sémantiques spécifiées au paragraphe 4.2 du présent document, est dans la Figure 9.

Sémantique	Jeton	Référence
Identification de flux	FID	 [RFC5576]
Correction d'erreur directe	FEC	[RFC5576]

Figure 9 : Contenu initial du registre IANA Sémantique de groupe de sources

 	13.	Références
 	13.1	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. DOI 10.17487/RFC2119, (MàJ par RFC8174)

[RFC3264]	J. Rosenberg et H. Schulzrinne, "Modèle d'offre/réponse avec le protocole de description de session (SDP)", juin 2002, DOI 10.17487/RFC3264. (P.S.  ; MàJ par RFC8843, 9143)

[RFC3388]	G. Camarillo, G. Eriksson, J. Holler et H. Schulzrinne, "Groupage des lignes de support dans le protocole de description de session (SDP)", décembre 2002. (Remplacée par RFC5888)

[RFC3550]	H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : un protocole de transport pour les applications en temps réel", STD 64, DOI 10.17487/RFC3550, juillet 2003. (MàJ par RFC7164, RFC7160, RFC8083, RFC8108, RFC8860)

[RFC4566]	M. Handley, V. Jacobson et C. Perkins, "SDP : Protocole de description de session", juillet 2006, DOI 10.17487/RFC4566. (P.S.  ; remplacée par RFC8866)

[RFC4756]	A. Li, "Sémantique du groupage de correction d'erreur directe dans le protocole de description de session", novembre  2006. (P.S.)

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

[RFC5234]	D. Crocker, P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", janvier 2008. (STD0068)

 	13.2	Références pour information 

[FLUTE]	Mehta, H., "SDP Descriptors for FLUTE", Travail en cours, janvier 2006.

[RFC3524]	G. Camarillo, A. Monrad, "Transposition de flux de support en flux de réservation de ressource", avril 2003. (P.S.)

[RFC3830]	J. Arkko et autres, "MIKEY : Gestion de clé multimédia pour l’Internet", août 2004. (MàJ par RFC4738) (P.S.)

[RFC4091]	G. Camarillo, J. Rosenberg, "Sémantique des types d'adresse de réseau de remplacement (ANAT) pour le cadre de groupage du protocole de description de session (SDP)", juin 2005, DOI 10.17487/RFC4091. (P.S.)

[RFC4567]	J. Arkko et autres, "Extensions de gestion de clés pour le protocole de description de session (SDP) et le protocole d'écoulement en temps réel (RTSP)", juillet 2006. (P.S.)

[RFC4588]	J. Rey et autres, "Format de charge utile de retransmission RTP", juillet 2006. (P.S.)

[RFC5117]	M. Westerlund, S. Wenger "Topologies dans RTP", janvier 2008. (Info. , Remplacée par RFC7667)

[RFC5245]	J. Rosenberg,"Établissement de connexité interactive (ICE) : Protocole pour la traversée de traducteur d'adresse réseau (NAT) pour les protocoles d'offre/réponse", avril 2010, DOI 10.17487/RFC5245. (P. S. ;remplace RFC4091, 4092 ; remplacée par 8445)

[RFC5760]	J. Ott, J. Chesterfield, E. Schooler, "Extensions au protocole de contrôle RTP (RTCP) pour les sessions de diffusion groupée à une seule source avec retour en envoi individuel", février 2010. (P. S.)

 	Adresse des auteurs

Jonathan Lennox	Joerg Ott	Thomas Schierl	
Vidyo, Inc.	Helsinki University of Technology (TKK)	Fraunhofer HHI	
433 Hackensack Avenue	Dpt. Communications et Networking	Einsteinufer 37	
Sixth Floor	PO Box 3000	D-10587 Berlin	
Hackensack, NJ  07601	FIN-02015 TKK	Germany	
US	Finland	mél : ts@thomas-schierl.de	
 mél : jonathan@vidyo.com	mél : jo@acm.org