Équipe d'ingénierie de l'Internet (IETF)	G. Camarillo, Ericsson	
Request for Comments : 5888	H. Schulzrinne, Columbia University	
Remplace la RFC 3388		
Catégorie : Sur la voie de la normalisation	juillet 2009	
ISSN: 2070-1721	Traduction Claude Brière de L'Isle	

Cadre de groupement dans le protocole de description de session (SDP)

Résumé
Dans la présente specification, on définit un cadre pour grouper les lignes "m" dans le protocole de description de session (SDP, description de session Protocol) pour différentes raisons. Ce cadre utilise les attributs SDP "group" et "mid"; qui sont tous deux définis dans la présente spécification. De plus, on spécifie comment utiliser le cadre pour deux objets différents : pour la synchronisation des lèvres et pour recevoir un flux de supports consistant en plusieurs flux de supports sur des adresses de transport différentes. Ce document rend obsolète la RFC 3388.

Statut du présent mémoire
Ceci est un document de l’Internet sur la voie de la normalisation.

Le présent document a été produit par l’équipe d’ingénierie de l’Internet (IETF). Il représente le consensus de la communauté de l’IETF. Il a subi une révision publique et sa publication a été approuvée par le groupe de pilotage de l’ingénierie de l’Internet (IESG). Tous les documents approuvés par l’IESG ne sont pas candidats à devenir une norme de l’Internet ; voir la Section 2 de la RFC5741.

Les informations sur le statut actuel du présent document, tout errata, et comment fournir des réactions sur lui peuvent être obtenues à http://www.rfc-editor.org/info/rfc5888 

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. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.
Table des matières
1. Introduction	2
2. Terminologie	2
3. Vue d'ensemble du fonctionnement	2
4. Attribut Identification de flux de supports	2
5. Attribut "group"	3
6. Utilisation de "group" et "mid"	3
7. Synchronisation des lèvres (LS)	3
7.1 Exemple de LS	3
8. Identification de flux (FID)	4
8.1 SIP et accès cellulaire	4
8.2 Tonalités DTMF	4
8.3 Définition de flux de supports	4
8.4 Sémantique de FID	5
8.5 Scénarios non couverts par le FID	7
9. Usage de l'attribut "group" dans SIP	8
9.1 Valeurs "mid" dans les réponses	8
9.2 Valeur "group" dans les réponses	9
9.3 Négociation de capacité	10
9.4 Rétro compatibilité	11
10. Changements par rapport à la RFC 3388	11
11. Considérations sur la sécurité	11
12. Considérations relatives à l'IANA	12
13. Remerciements	12
14. Références	13
14.1 Références normatives	13
14.2 Références pour information	13
Adresse des auteurs	13

 	1.	Introduction

La [RFC3388] a spécifié un cadre de groupement de lignes de support pour SDP [RFC4566]. La présente spécification rend obsolète la [RFC3388].

Une description de session SDP [RFC4566] contient normalement une ou plusieurs lignes de supports, qui sont couramment appelées des lignes "m". Quand une description de session contient plus d'une ligne "m", SDP ne fournit pas de moyen d'exprimer une relation particulière entre deux d'entre elles ou plus. Quand une application reçoit une description de session SDP avec plus d'une ligne "m", il appartient à l'application de déterminer ce qu'elle doit en faire. SDP ne porte pas d'information sur le groupement des flux de supports.

Bien que dans certains environnements, cette information puisse être portée hors bande, il est nécessaire d'avoir un mécanisme dans SDP pour exprimer comment différents flux de supports au sein d'une description de session sont en relation les uns avec les autres. Le cadre défini dans la présente spécification est un tel mécanisme.

 	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 le BCP 14, [RFC2119].

 	3.	Vue d'ensemble du fonctionnement

Cette section fournit une description non normative de la façon dont fonctionne le cadre de groupement SDP défini dans ce document. Dans une description de session donnée, chaque ligne "m" est identifiée par un jeton, qui est porté dans un attribut "mid" en dessous de la ligne "m". La description de session porte des attributs "group" de niveau session qui groupent les différentes lignes "m" (identifiées par leurs jetons) en utilisant des sémantiques de groupe différentes. La sémantique d'un groupe décrit l'objet pour lequel les lignes "m" sont groupées. Par exemple, la ligne "group" dans la description de session ci-dessous indique que les lignes "m" identifiées par les jetons 1 et 2 (respectivement les lignes "m" audio et vidéo) sont groupées pour les besoins de synchronisation de lèvres (LS, Lip Synchronization).

v=0
o=Laura 289083124 289083124 IN IP4 one.exemple.com
c=IN IP4 192.0.2.1
t=0 0
a=group:LS 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=video 30002 RTP/AVP 31
a=mid:2

 	4.	Attribut Identification de flux de supports

Le présent document définit l'attribut de support "media stream identification", qui est utilisé pour identifier les flux de supports au sein d'une description de session. Son formatage dans SDP [RFC4566] est décrit par le format Backus-Naur augmenté (ABNF, Augmented Backus-Naur Form) [RFC5234] suivant :

mid-attribute = "a=mid:" identification-tag
identification-tag = token	; token est défini dans la RFC 4566

L'étiquette d'identification DOIT être unique dans une description de session SDP.

 	5.	Attribut "group"

Le présent document définit l'attribut de niveau session "group", qui est utilisé pour grouper ensemble différents flux de supports. Son format dans SDP est décrit par l'ABNF [RFC5234] suivant :

group-attribute = "a=group:" semantics *(SP identification-tag)
semantics = "LS" / "FID" / semantics-extension
semantics-extension = token	; token est défini dans la RFC 4566

Le présent document définit deux sémantiques standard : Synchronisation de lèvres (LS) et Identification de flux (FID). Les extensions de sémantique suivent la politique d'action de normalisation [RFC5226].

 	6.	Utilisation de "group" et "mid"

Toutes les lignes "m" d'une description de session qui utilise "group" DOIVENT être identifiées avec un attribut "mid", qu'elles apparaissent ou non dans la ou les lignes du groupe. Si une description de session contient au moins une ligne "m" qui n'a pas d'identification "mid", l'application NE DOIT PAS effectuer de groupement de lignes de supports.

Les lignes "a=group" sont utilisées pour grouper plusieurs lignes "m" qui sont identifiées par leur attribut "mid". Des lignes "a=group" qui contiennent des étiquettes d'identification qui ne correspondent à aucune ligne "m" au sein de la description de session DOIVENT être ignorées. L'application agit comme si la ligne "a=group" n'existait pas. Le comportement d'une application qui reçoit une description SDP avec des lignes "m" groupées est définie par le champ Sémantique dans la ligne "a=group".

Il PEUT y avoir plusieurs lignes "a=group" dans une description de session. Les lignes "a=group" d'une description de session peuvent utiliser la même sémantique ou une sémantique différente. Une ligne "m" identifiée par son attribut "mid" PEUT apparaître dans plus d'une ligne "a=group".

 	7.	Synchronisation des lèvres (LS)

Une application qui reçoit une description de session contenant des lignes "m" groupées en utilisant la sémantique LS DOIT synchroniser l'exécution des flux de supports correspondants. Noter que la sémantique de LS ne s'applique pas qu'au flux vidéo qui doit être synchronisé avec un flux audio ; l'exécution de deux flux de même type peut être synchronisée aussi.

Pour les flux RTP, la synchronisation est normalement effectuée en utilisant le protocole de contrôle de RTP (RTCP, RTP Control Protocol) qui fournit assez d'informations pour transposer les horodatages provenant des différents flux en une valeur de temps local absolu. Cependant, le concept de synchronisation des flux de supports PEUT aussi s'appliquer aux flux de supports qui n'utilisent pas RTP. Si c'est le cas, l'application DOIT récupérer les relations temporelles originales entre les flux en utilisant tout mécanisme disponible.

 	7.1	Exemple de LS
L'exemple suivant montre une description de session d'une conférence en diffusion groupée. Le premier flux de supports (mid:1) contient la voix de l'orateur qui parle en anglais. Le second flux de supports (mid:2) contient le composant vidéo, et le troisième flux de supports (mid:3) porte la traduction en espagnol de ce qui est dit. Le premier et le second flux de supports doivent être synchronisés.

v=0
o=Laura 289083124 289083124 IN IP4 two.exemple.com
c=IN IP4 233.252.0.1/127
t=0 0
a=group:LS 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=video 30002 RTP/AVP 31
a=mid:2
m=audio 30004 RTP/AVP 0
i=ce flux de supports contient la traduction espagnole
a=mid:3

Noter que bien que le troisième flux de supports ne soit pas présent dans la ligne de groupe, il doit quand même contenir un attribut "mid" (mid:3), comme déclaré plus haut.

 	8.	Identification de flux (FID)

Une ligne "m" dans une description de session SDP définit un flux de supports. Cependant, SDP ne définit pas ce qu'est un flux de supports. Cette définition se trouve dans la spécification du protocole de flux en temps réel (RTSP, Real Time Streaming Protocol). La RFC de RTSP [RFC2326] définit un flux de supports comme "une seule instance de supports, par exemple, un flux audio ou un flux vidéo aussi bien qu'un seul tableau blanc ou un groupe d'application partagée. Lorsque on utilise RTP, un flux consiste en tous les paquets RTP et RTCP créés par une source au sein d'une session RTP."

Cette définition suppose qu'un seul flux audio (ou vidéo) se transpose en une session RTP. La RFC de RTP [RFC1889] (à présent rendue obsolète par la [RFC3550]) définissait une session RTP comme suit : "Pour chaque participant, la session est définie par une paire particulière d'adresses de transport de destination (une adresse réseau plus une paire d'accès pour RTP et RTCP)".

Bien que les définitions précédentes couvrent les cas les plus courants, il y a des situations où une seule instance de supports (par exemple, un flux audio ou vidéo) est envoyé en utilisant plus d'une session RTP. Deux exemples (parmi bien d'autres) de cette sorte de situation sont les systèmes cellulaires qui utilisent le protocole d'initialisation de session (SIP, Session Initiation Protocol) [RFC3261] et les systèmes qui reçoivent des tonalités en multifréquence bi-tonalités (DTMF, Dual-Tone Multi-Frequency) sur un hôte différent de la voix.

 	8.1	SIP et accès cellulaire
Les systèmes qui utilisent un accès cellulaire et SIP comme protocole de signalisation ont besoin de recevoir les supports sur le réseau. Durant une session, le support peut être codé en utilisant des codecs différents. Le support codé doit traverser l'interface radio. L'interface radio est généralement caractérisée comme encline aux erreurs de bits et associée à des délais relativement élevés de transfert de paquets. De plus, les ressources de l'interface radio dans un environnement cellulaire sont rares et donc coûteuses, ce qui appelle des mesures particulières pour fournir un transport très efficace. Afin d'obtenir une qualité de parole appropriée en combinaison avec un transport efficace, une connaissance précise des propriété du codec est nécessaire afin qu'une porteuse radio appropriée pour la session RTP puisse être configurée avant de transférer les supports. Ces porteuses radio sont des porteuses dédiées par type de support (c'est-à-dire, un codec).

Les systèmes cellulaires configurent normalement des porteuses radio différentes sur des numéros d'accès différents. Donc les supports entrants doivent avoir des numéros d'accès de destination différents pour les différents codecs possibles afin d'être acheminés de façon appropriée à la porteuse radio correcte. Donc, c'est un exemple dans lequel plusieurs sessions RTP sont utilisées pour porter une seule instance de supports (la parole codée provenant de l'envoyeur).

 	8.2	Tonalités DTMF
Certaines sessions vocales incluent des tonalités DTMF. Parfois, le traitement de la voix est effectué par un hôte différent de celui qui traite le DTMF. Il est courant d'avoir un serveur d'application dans le réseau qui collecte les tonalités DTMF pour l'utilisateur tandis que l'utilisateur reçoit la parole codée sur son agent d'utilisateur. Dans cette situation, il est nécessaire d'établir deux sessions RTP : une pour la voix et l'autre pour les tonalités DTMF. Les deux sessions RTP font logiquement partie de la même instance de supports.

 	8.3	Définition de flux de supports
Les exemples précédents montrent que la définition d'un flux de supports de la [RFC2326] ne couvre pas certains scénarios.  On ne peut pas supposer qu'une seule instance de supports se transpose en une seule session RTP. Donc, on introduit la définition d'un flux de supports suivante : un flux de supports consiste en une seule instance de supports, par exemple, un flux audio ou vidéo ainsi qu'un seul tableau blanc ou groupe d'applications partagées. Quand on utilise RTP, un flux de supports comporte une ou plusieurs sessions RTP.

 	8.4	Sémantique de FID
Plusieurs lignes "m" groupées ensemble en utilisant la sémantique de FID forment un flux de supports. Un agent de supports traitant un flux de supports qui comporte plusieurs lignes "m" DOIT envoyer une copie des supports à chaque ligne "m" qui fait partie du flux pour autant que les codecs et l'attribut de direction présent dans une ligne "m" particulière le permettent.

On suppose que l'application utilise seulement un codec à la fois pour coder le support produit. Ce codec PEUT changer dynamiquement durant la session, mais à tout instant particulier, un seul codec est utilisé.

L'application code les supports en utilisant le codec actuel et vérifie, une par une, toutes les lignes "m" qui font partie du flux. Si une ligne "m" particulière contient le codec utilisé et si l'attribut de direction est "sendonly" ou "sendrecv", une copie des supports codés est envoyée à l'adresse/accès spécifié dans ce flux de supports particulier. Si la ligne "m" ne contient pas le codec utilisé ou si l'attribut de direction n'est ni "sendonly" ni "sendrecv", rien n'est envoyé sur ce flux de supports.

L'application finit normalement par envoyer les supports aux différentes destinations (adresse IP/numéro d'accès) selon le codec utilisé à ce moment.

 	8.4.1	Exemples de FID
La description de session ci-dessous pourrait être envoyée par un agent d'utilisateur SIP utilisant un accès cellulaire. L'agent d'utilisateur prend en charge le système mondial de communications mobiles (GSM, Global System for Mobile communications) sur l'accès 30000 et le multi débits adaptatif (AMR, Adaptive Multi-Rate) sur l'accès 30002. Quand la partie distante envoie du GSM, elle va envoyer des paquets RTP au numéro d'accès 30000. Quand l'AMR est le codec choisi, les paquets vont être envoyés à l'accès 30002. Noter que la partie distante peut commuter entre les deux codecs de façon dynamique au milieu de la session. Cependant, dans cet exemple, seul un flux de supports à la fois porte de la voix. Les autres restent "muets" tandis que le codec correspondant n'est pas utilisé.

v=0
o=Laura 289083124 289083124 IN IP4 three.exemple.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 30000 RTP/AVP 3
a=rtpmap:3 GSM/8000
a=mid:1
m=audio 30002 RTP/AVP 97
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; mode-change-neighbor; maxframes=1
a=mid:2

Dans l'exemple précédent, un système reçoit des supports sur la même adresse IP sur les différents numéros d'accès. L'exemple suivant montre comment un système peut recevoir des codecs différents sur différentes adresses IP.

v=0
o=Laura 289083124 289083124 IN IP4 four.exemple.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.2
a=rtpmap:0 PCMU/8000
a=mid:1
m=audio 30002 RTP/AVP 97
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; mode-change-neighbor; maxframes=1
a=mid:2

Le terminal cellulaire dans cet exemple prend seulement en charge le codec AMR. Cependant, de nombreux téléphones IP actuels prennent seulement en charge la modulation par impulsion de codage (MIC) de charge utile 0. Afin d'être capable d'interopérer entre eux, les terminaux cellulaires utilisent un transcodeur dont l'adresse IP est 192.0.2.2. Le terminal cellulaire inclut l'adresse IP du transcodeur dans sa description SDP pour assurer la prise en charge du MIC. Les systèmes distants vont envoyer l'AMR directement au terminal, mais le MIC va être envoyé au transcodeur. Le transcodeur va être configuré (en utilisant la méthode préférée) pour convertir le MIC audio entrant en AMR et l'envoyer au terminal.

L'exemple suivant montre comment l'attribut "group" utilisé avec la sémantique de FID peut indiquer l'utilisation de deux codecs différents dans les deux directions d'un flux de supports bidirectionnel.

v=0
o=Laura 289083124 289083124 IN IP4 five.exemple.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30002 RTP/AVP 8
a=recvonly
a=mid:2

Un agent d'utilisateur qui reçoit la description SDP ci-dessus sait que, à un certain moment, il peut envoyer soit du MIC loi  µ au numéro d'accès 30000, soit du MIC loi A au numéro d'accès 30002. Cependant, l'agent de support sait aussi que l'autre côté va seulement envoyer du MIC loi µ (charge utile 0).

L'exemple suivant montre une description de session avec différentes lignes "m" groupées en utilisant la sémantique de FID qui contient le même codec.

v=0
o=Laura 289083124 289083124 IN IP4 six.exemple.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2 3
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30002 RTP/AVP 8
a=mid:2
m=audio 20000 RTP/AVP 0 8
c=IN IP4 192.0.2.2
a=recvonly
a=mid:3

À un moment donné, si l'agent de supports qui reçoit le message SDP ci-dessus envoie du MIC loi µ (charge utile 0) il envoie des paquets RTP à 192.0.2.1 sur l'accès 30000 et à 192.0.2.2 sur l'accès 20000 (première et troisième lignes "m"). Si il envoie du MIC loi A (charge utile 8) il envoie des paquets RTP à 192.0.2.1 sur l'accès 30002 et à 192.0.2.2 sur l'accès 20000 (seconde et troisième lignes "m").

Le système qui a généré la description SDP ci-dessus prend en charge le MIC loi µ sur l'accès 30000 et le MIC loi A sur l'accès 30002. Par ailleurs, il utilise un serveur d'application qui enregistre la conversation et dont l'adresse IP est 192.0.2.2.  Le serveur d'application n'a pas besoin de comprendre le contenu du support, donc il reçoit toujours une copie du flus de supports, sans considération du codec et du type de charge utile utilisés. C'est pourquoi le serveur d'application reçoit toujours une copie du flux audio sans considération du codec utilisé à tout instant donné (il effectue en fait un stockage RTP, de sorte qu'il peut effectivement recevoir tout codec).

On se souvient que si plusieurs lignes "m" qui sont groupées en utilisant la sémantique de FID contiennent le même codec, l'agent de supports DOIT envoyer des copies du même flux de supports comme plusieurs sessions RTP en même temps.

Le dernier exemple de cette section traite des tonalités DTMF. Les tonalités DTMF peuvent être transmises en utilisant un codec vocal normal ou peuvent être transmises comme des événements de téléphonie. La charge utile RTP pour les tonalités DTMF traitées comme des événements de téléphonie est décrite dans la [RFC4733]. Ci-dessous est un exemple de description de session SDP utilisant la sémantique de FID et ce type de charge utile.

v=0
o=Laura 289083124 289083124 IN IP4 seven.exemple.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 20000 RTP/AVP 97
c=IN IP4 192.0.2.2
a=rtpmap:97 telephone-events
a=mid:2

La partie distante va envoyer de la voix codée en MIC (charge utile 0) à 192.0.2.1 et des tonalités DTMF codées comme des événements de téléphonie à 192.0.2.2. Noter que seule la voix ou le DTMF est envoyé à un instant donné. Quand les tonalités DTMF sont envoyées, le premier flux de supports ne porte aucune donnée et, quand la voix est envoyée, il n'y a pas de données dans le second flux de supports. La sémantique de FID donne des destinations différentes pour les codecs de remplacement.

 	8.5	Scénarios non couverts par le FID
Il est utile de mentionner des scénarios où l'attribut "group" utilisant les sémantiques existantes (en particulier FID) pourrait sembler être applicable mais ne l'est pas.

 	8.5.1	Codage parallèle utilisant des codecs différents
La sémantique de FID est utile quand l'application utilise seulement un codec à la fois. Une application qui code les mêmes supports en utilisant simultanément différents codecs NE DOIT PAS utiliser FID pour grouper ces lignes de supports. Certains systèmes qui traitent les tonalités DTMF sont un exemple typique de codage en parallèle utilisant des codecs différents. Certains systèmes mettent en œuvre la charge utile RTP définie dans la [RFC4733], mais quand ils envoient des tonalités DTMF, ils n'assourdissent pas le canal vocal. Donc, en effet ils envoient deux copies de la même tonalité DTMF : une codée comme de la voix et une codée comme un événement de téléphonie. Quand le receveur obtient les deux copies, il utilise normalement l'événement de téléphonie plutôt que la tonalité codée en vocal. La sémantique de FID NE DOIT PAS être utilisée dans ce contexte pour grouper les deux flux de supports, car un tel système n'utilise pas des codecs de remplacement mais plutôt des codages différents en parallèle pour les mêmes informations.

 	8.5.2	Codage en couches
Les schémas de codage en couches codent les supports dans des couches différentes. La qualité du flux de supports chez le receveur varie selon le nombre de couches reçues. SDP donne un moyen pour grouper les adresses de diffusion groupée contiguës qui transportent des couches différentes. La ligne "c" ci-dessous :

c=IN IP4 233.252.0.1/127/3

est équivalente aux trois lignes "c" suivantes :

c=IN IP4 233.252.0.1/127
c=IN IP4 233.252.0.2/127
c=IN IP4 233.252.0.3/127

FID NE DOIT PAS être utilisé pour grouper des lignes "m" qui ne représentent pas les mêmes informations. Donc, FID NE DOIT PAS être utilisé pour grouper des lignes "m" qui contiennent les différents couches des schémas de codage en couches. Par ailleurs, on ne définit pas de nouvelle sémantique de groupe pour fournir une façon plus souple de grouper des couches différentes, parce que le mécanisme SDP déjà existant couvre les scénarios les plus utiles. Comme le mécanisme SDP existant couvre déjà les scénarios les plus utiles, on ne définit pas une nouvelle sémantique de groupe pour définir une façon plus souple de grouper les couches différentes.

 	8.5.3	Même adresse et numéro d'accès IP
Si les flux de supports qui utilisent plusieurs codecs différents doivent être envoyés à la même adresse et accès IP, la syntaxe traditionnelle de SDP de mentionner plusieurs codecs dans la même ligne "m" DOIT être utilisée. FID NE DOIT PAS être utilisé pour grouper des lignes "m" avec la même adresse/accès IP. Donc, une description SDP comme celle ci-dessous NE DOIT PAS être générée.

v=0
o=Laura 289083124 289083124 IN IP4 eight.exemple.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30000 RTP/AVP 8
a=mid:2

La description SDP correcte pour la session ci-dessus serait la suivante :

v=0
o=Laura 289083124 289083124 IN IP4 nine.exemple.com
c=IN IP4 192.0.2.1
t=0 0
m=audio 30000 RTP/AVP 0 8

Si deux lignes "m" sont groupées en utilisant FID, elles DOIVENT différer par leurs adresses de transport (c'est-à-dire, adresse IP plus accès).

 	9.	Usage de l'attribut "group" dans SIP

Les descriptions SDP sont utilisées par plusieurs protocoles différents, dont SIP. On inclut un paragraphe sur SIP, parce que l'attribut "group" va très probablement être utilisé principalement par des systèmes SIP.

SIP [RFC3261] est un protocole de couche application pour établir, terminer, et modifier des sessions multimédia. SIP porte des descriptions de session dans le corps des messages SIP mais est indépendant du protocole utilisé pour décrire les sessions. SDP [RFC4566] est un des protocoles qui peuvent être utilisés à cette fin.

À l'établissement de session, SIP fournit une prise de contact en trois phases (INVITE-200 OK-ACK) entre les systèmes d'extrémité. Cependant, seuls deux de ces trois messages portent SDP, comme décrit dans la [RFC3264].

 	9.1	Valeurs "mid" dans les réponses
L'attribut "mid" est un identifiant pour un flux de supports particulier. Donc, la valeur "mid" dans l'offre DOIT être la même que la valeur "mid" dans la réponse. Par ailleurs, les offres suivantes (par exemple, dans un re-INVITE) DEVRAIENT utiliser la même valeur de "mid" pour les flux de supports déjà existants.

La [RFC3264] décrit l'usage de SDP dans le texte de SIP. L'offreur et le répondeur alignent leur description de supports afin que le nième flux de supports (ligne "m=") dans la description de session de l'offreur corresponde au nième flux de supports dans la description du répondeur.

La présence de l'attribut "group" dans une description de session SDP ne modifie pas ce comportement.

Comme l'attribut "mid" donne un moyen pour étiqueter les lignes "m", il serait possible d'effectuer l'alignement des supports en utilisant des étiquettes "mid" plutôt que de confronter les nièmes lignes "m". Cependant, cela n'apporterait rien et ajouterait de la complexité aux mises en œuvre. Donc, les systèmes SIP DOIVENT effectuer l'alignement des supports en confrontant les nièmes lignes sans considération de la présence de l'attribut "group" ou "mid".

Si un flux de supports qui contenait un identifiant "mid" particulier dans l'offre contient un identifiant différent dans la réponse, l'application ignore toutes les lignes "mid" et "group" qui pourraient apparaître dans la description de session. L'exemple suivant illustre ce scénario.

 	9.1.1	Exemple
Deux entités SIP échangent des SDP durant l'établissement de session. Le INVITE contient la description SDP suivante :

v=0
o=Laura 289083124 289083124 IN IP4 ten.exemple.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 30000 RTP/AVP 0 8
a=mid:1
m=audio 30002 RTP/AVP 0 8
a=mid:2

La réponse 200 OK contient la description SDP suivante :

v=0
o=Bob 289083122 289083122 IN IP4 eleven.exemple.com
c=IN IP4 192.0.2.3
t=0 0
a=group:FID 1 2
m=audio 25000 RTP/AVP 0 8
a=mid:2
m=audio 25002 RTP/AVP 0 8
a=mid:1

Comme l'alignement des lignes "m" est effectué sur la base de la confrontation des nièmes lignes, le premier flux a "mid:1" dans l'INVITE et "mid:2" dans le 200 OK. Donc, l'application ignore chaque ligne "mid" et "group" contenue dans la description SDP.

Un agent d'utilisateur SIP qui se comporte bien aurait retourné la description SDP ci-dessous dans la réponse 200 OK :

v=0
o=Bob 289083122 289083122 IN IP4 twelve.exemple.com
c=IN IP4 192.0.2.3
t=0 0
a=group:FID 1 2
m=audio 25002 RTP/AVP 0 8
a=mid:1
m=audio 25000 RTP/AVP 0 8
a=mid:2

 	9.2	Valeur "group" dans les réponses
Une entité SIP qui reçoit une offre contenant une ligne "a=group" avec une sémantique qu'elle ne comprend pas DOIT retourner une réponse sans la ligne "group". Noter que, comme décrit au paragraphe précédent, les lignes "mid" DOIVENT quand même être présentes dans la réponse.

Une entité SIP qui reçoit une offre contenant une ligne "a=group" avec une sémantique qui n'est pas comprise DOIT retourner une réponse qui contient une ligne "a=group" avec la même sémantique. Les étiquettes d'identification contenues dans cette ligne "a=group" DOIVENT être les mêmes que celles reçues dans l'offre, ou un sous ensemble de celles-ci (zéro étiquette d'identification est un sous ensemble valide). Quand les étiquettes d'identification dans la réponse sont un sous ensemble, la valeur "group" à utiliser dans la session DOIT être celle présente dans la réponse.

Les entités SIP refusent les flux de supports en réglant l'accès à zéro dans la ligne "m" correspondante. Des lignes "a=group" NE DOIVENT PAS contenir des étiquettes d'identification qui correspondent aux lignes "m" avec l'accès réglé à zéro.

Noter que grouper des lignes "m" DOIT toujours être demandé par l'offreur, mais jamais par le répondeur. Comme SIP fournit un échange SDP en deux phases, un répondeur qui a demandé un groupement ne saurait pas si l'attribut "group" a été accepté ou non par l'offreur. Un répondeur qui veut grouper des lignes de supports produit une autre offre après avoir répondu à la première (dans un re-INVITE, par exemple).

 	9.2.1	Exemple
L'exemple ci-dessous montre comment l'appelé refuse un flux de supports offert par l'appelant en réglant son numéro d'accès à zéro. La valeur de "mid" correspondant à ce flux de supports est supprimée de la valeur de "group" dans la réponse.

Description SDP dans l'INVITE de l'appelant à l'appelé :

v=0
o=Laura 289083124 289083124 IN IP4 thirteen.exemple.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2 3
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30002 RTP/AVP 8
a=mid:2
m=audio 30004 RTP/AVP 3
a=mid:3

Description SDP dans l'INVITE de l'appelé à l'appelant :

v=0
o=Bob 289083125 289083125 IN IP4 fourteen.exemple.com
c=IN IP4 192.0.2.3
t=0 0
a=group:FID 1 3
m=audio 20000 RTP/AVP 0
a=mid:1
m=audio 0 RTP/AVP 8
a=mid:2
m=audio 20002 RTP/AVP 3
a=mid:3

 	9.3	Négociation de capacité
Un client qui comprend "group" et "mid", mais ne veut pas utiliser ces caractéristiques SDP dans une session particulière, peut quand même vouloir indiquer qu'il prend en charge ces caractéristiques. Pour indiquer cette prise en charge, un client peut ajouter une ligne "a=3Dgroup" sans étiquette d'identification pour chaque valeur de sémantique qu'il comprend.

Si un serveur reçoit une offre contenant des lignes "a=group" vides, il DEVRAIT ajouter ses capacités aussi sous la forme de lignes "a=group" vides à sa réponse.

 	9.3.1	Exemple
Un système qui prend en charge les deux sémantiques de LS et FID mais ne veut pas grouper de flux de supports pour une session particulière génère la description SDP suivante :

v=0
o=Bob 289083125 289083125 IN IP4 fifteen.exemple.com
c=IN IP4 192.0.2.3
t=0 0
a=group:LS
a=group:FID
m=audio 20000 RTP/AVP 0 8

Le serveur qui reçoit cette offre prend en charge FID mais pas LS. Il répond avec la description SDP ci-dessous :

v=0
o=Laura 289083124 289083124 IN IP4 sixteen.exemple.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID
m=audio 30000 RTP/AVP 0

 	9.4	Rétro compatibilité
Le présent document ne définit pas de champ d'en-tête SIP "Require". Donc, si un des agents d'utilisateur SIP ne comprend pas l'attribut "group", le mécanisme standard de repli de SDP DOIT être utilisé, à savoir, que les attributs non compris sont simplement ignorés.

 	9.4.1	L'offreur ne prend pas en charge "group"
Cette situation ne représente pas un problème, parce que les demandes de groupement sont toujours effectuées par les offreurs et non par les répondeurs. Si l'offreur ne prend pas en charge "group", cet attribut ne va simplement pas être utilisé.

 	9.4.2	Le répondeur ne prend pas en charge "group"
Le répondeur va ignorer l'attribut "group" car il ne le comprend pas et il va aussi ignorer l'attribut "mid". Pour la sémantique de LS, le répondeur pourrait décider d'effectuer, ou de ne pas effectuer, la synchronisation entre les flux de supports.

Pour la sémantique de FID, le répondeur va considérer que la session consiste en plusieurs flux de supports.

Différentes mises en œuvre vont se comporter de façons différentes.

Dans le cas d'audio et de lignes "m" différentes pour des codecs différents, une mise en œuvre pourrait décider d'agir comme un mélangeur avec les différentes sessions RTP entrantes, ce qui est le comportement correct.

Une mise en œuvre pourrait aussi décider de refuser la demande (par exemple, 488 Non acceptable ici, ou 606 Non acceptable) parce qu'elle contient plusieurs lignes "m". Dans ce cas, le serveur ne prend pas en charge le type de session que l'appelant voulait établir. Dans le cas où le client veut établir de toutes façons une session plus simple, le client peut réessayer la demande sans l'attribut "group" et avec une seule ligne "m" par flux.

 	10.	Changements par rapport à la RFC 3388

La Section 3 (Vue d'ensemble du fonctionnement) a été ajoutée pour des précisions. Les acronymes AMR et GSM sont maintenant développés à leur première utilisation. Les exemples utilisent maintenant des adresses IP dans la gamme convenable pour les exemples.

Le mécanisme de groupement est maintenant défini comme un cadre extensible. Précédemment, la [RFC3388] déconseillait les extensions à ce mécanisme en faveur de l'utilisation de nouveaux protocoles de description de session.

Étant donnée une valeur de sémantique, la [RFC3388] restreignait les identifiants de ligne "m" a seulement apparaître dans un seul groupe utilisant cette sémantique. Cette restriction a été levée dans la présente spécification. D'après des conversations avec les développeurs, les mises en œuvre existantes (c'est-à-dire, traditionnelles) appliquent cette restriction sur la base de la sémantique. C'est-à-dire, elles appliquent seulement cette restriction pour les sémantiques prises en charge. À cause de la nature des sémantiques existantes, les mises en œuvre vont seulement utiliser un identifiant de ligne "m" à travers les groupes utilisant une sémantique donnée même après que la restriction a été levée par la présente spécification. Par conséquent, la levée de cette restriction ne va pas causer de problème de rétro-compatibilité, parce que les mises en œuvre qui prennent en charge la nouvelle sémantique vont être mises à jour pour ne pas appliquer cette restriction au moment où elles sont mises à jour pour prendre en charge la nouvelle sémantique.

 	11.	Considérations sur la sécurité

Utilisant le paramètre "group" avec la sémantique de FID, une entité qui s'est arrangée pour modifier la description de sessions échangée entre les participants pour établir une session multimédia pourrait forcer les participants à envoyer une copie des supports à toute destination de son choix.

Les mécanismes de protection de l'intégrité fournis par les protocoles utilisés pour échanger les descriptions de session et le chiffrement des supports peuvent être utilisés pour empêcher cette attaque. Dans SIP, les extensions sécurisées/multi-usage de messagerie Internet (S/MIME, Secure/Multipurpose Internet Mail Extensions) [RFC5750] et la sécurité de la couche transport (TLS, Transport Layer Security) [RFC5246] peuvent être utilisées pour protéger les échanges de description de session respectivement de bout en bout et bond par bond.

 	12.	Considérations relatives à l'IANA

Le présent document définit deux attributs SDP : "mid" et "group".

L'attribut "mid" est utilisé pour identifier les flux de supports dans une description de session, et son format est défini à la Section 4.

L'attribut "group" est utilisé pour grouper différents flux de supports, et son format est défini à la Section 5.

Le présent document définit un cadre pour grouper des lignes de supports dans SDP en utilisant des sémantiques différentes. Les valeurs de sémantique à utiliser avec ce cadre sont enregistrées par l'IANA suivant la politique d'action de normalisation [RFC5226].

La section des 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 "group". Ce jeton peut être d'une longueur quelconque, mais ne DEVRAIT pas faire plus de quatre caractères,
o	la référence à une RFC sur la voie de la normalisation.

Les entrées actuelles du registre sont les suivantes :

Sémantique	Jeton	Référence
Synchronisation de lèvres	LS	[RFC5888]
Identification du flux	FID	[RFC5888]
Réservation de flux seul	SRF	[RFC3524]
Autres types d'adresse réseau	ANAT	[RFC4091]
Correction d'erreur directe	FEC	[RFC4756]
Dépendance de décodage	DDP	[RFC5583]

 	13.	Remerciements

Goran Eriksson et Jan Holler étaient co-auteurs de la [RFC3388].

 	14.	Références
 	14.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)

[RFC3261]	J. Rosenberg et autres, "SIP : Protocole d'initialisation de session", juin 2002, DOI 10.17487/RFC3261. (Mise à jour par 3265, 3853, 4320, 4916, 5393, 6665, 8217, 8760)

[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)

[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)

[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)

[RFC5246]	T. Dierks, E. Rescorla, "Version 1.2 du protocole de sécurité de la couche Transport (TLS)", DOI 10.17487/RFC5246, août 2008. (P.S. ; remplace RFC3268, 4346, 4366 ; MàJ RFC4492 ; rendue obsolète par la RFC8446)

[RFC5750]	B. Ramsdell, S. Turner, "Traitement du certificat des extensions de messagerie Internet multi objets sécurisée (S/MIME) version 3.2", janvier 2010. (Remplace RFC3850). (P. S. ; Remplacée par RFC8550)

 	14.2	Références pour information

[RFC1889]	H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : protocole de transport pour applications en temps réel", janvier 1996. (Obsolète, voir RFC3550 STD64) 

[RFC2326]	H. Schulzrinne, A. Rao et R. Lanphier, "Protocole de flux directs en temps réel (RTSP)", avril 1998. (Remplacée par RFC7826)

[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)

[RFC4733]	H. Schulzrinne, T. Taylor, "Charge utile RTP pour chiffres DTMF, tonalités téléphoniques, et signaux de téléphonie", décembre 2006. (Remplace RFC2833) (MàJ par RFC4734, RFC5244) (P.S.)

 	Adresse des auteurs

Gonzalo Camarillo	Henning Schulzrinne	
Ericsson	Columbia University	
Hirsalantie 11	1214 Amsterdam Avenue	
Jorvas  02420	New York, NY  10027	
FINLAND	USA	
mél : Gonzalo.Camarillo@ericsson.com	mél : schulzrinne@cs.columbia.edu