Groupe de travail Réseau	T. Schierl, Fraunhofer HHI	
Request for Comments : 5583	S. Wenger, indépendant	
Catégorie : Sur la voie de la normalisation	juillet 2009	
Traduction Claude Brière de L'Isle		

Dépendance du décodage de support de signalisation dans le protocole de description de session (SDP)

Résumé
Le présent mémoire définit la sémantique qui permet de signaler la dépendance au décodage de différentes descriptions de supports avec le même type de supports dans le protocole de description de session (SDP, Session Description Protocol). C'est exigé, par exemple, si les données de supports sont séparées et transportées dans des flux de réseau différents par suite de l'utilisation d'un processus de codage de supports descriptif en couches ou multiple.

Un nouveau type de groupement "DDP" -- dépendance de décodage -- est défini, à utiliser en conjonction avec la RFC  3388 intitulée "Groupement de lignes de supports dans le protocole de description de session". De plus, un attribut est spécifié pour décrire la relation des flux de supports dans un groupe "DDP" indiqué par un ou des attributs d'identification de supports et une ou des descriptions de format de support.

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.
Table des matières
1. Introduction	2
2. Terminologie	2
3. Définitions	2
4. Motivation, cas d'utilisation, et architecture	3
4.1 Motivation	3
4.2 Cas d'utilisation	4
5. Signalisation des dépendances du support	4
5.1 Principes de conception	4
5.2 Sémantique	4
6. Usage d'une nouvelle sémantique dans SDP	6
6.1 Usage avec le modèle d'offre/réponse SDP	6
6.2 Usage déclaratif	6
6.3 Usage avec AVP et les profils SAVP RTP	6
6.4 Usage avec la négociation de capacité	7
6.5 Exemples	7
7. Considérations sur la sécurité	8
8. Considérations relatives à l'IANA	8
9. Note d'information sur le "cadre de groupement SDP"	9
10. Références	9
10.1 Références normatives	9
10.2 Références pour information	10
Appendice A. Remerciements	10
Adresse des auteurs	10

 	1.	Introduction

Une description de session SDP peut contenir une ou plusieurs descriptions de supports, chacune identifiant un seul flux de supports. Une description de supports est identifiée par une ligne "m=". Aujourd'hui, si plus d'une ligne "m=" existe pour indiquer le même type de support, un receveur ne peut pas identifier une relation spécifique entre ces supports.

Un codage de description multiple (MDC, Multiple Description Coding) ou un flux binaire de supports mis en couches contient, par définition, une ou plusieurs partitions de supports qui sont portées dans leur propre flux de supports. Les cas qui nous intéressent sont les flux binaires en couches et MDC avec deux partitions de supports ou plus. Porter plus d'une partition de supports dans sa propre session est un des cas d'utilisation clés pour employer des supports en couches ou codés en MDC. Les envoyeurs, les éléments de réseau, ou les receveurs peuvent supprimer les envois, transmissions, abonnements, décodages de partitions de supports individuelles et préserver quand même peut-être de façon sous optimale, mais toujours utile, la qualité des supports.

Une propriété de tous les flux binaires de supports relevant du présent mémoire est que leurs partitions de supports ont une relation d'usage bien définie. Par exemple, dans le codage en couche, les partitions de supports "supérieures"sont inutiles sans les "inférieures". Dans le codage MDC, les partitions de supports sont complémentaires -- plus on reçoit de partitions de supports, meilleure est la qualité reproduite. Le présent document définit une extension à SDP pour indiquer une telle dépendance au décodage.

Le déclencheur pour le présent mémoire a été le processus de normalisation du format de charge utile RTP pour l'extension de codage vidéo adaptable (SVC, Scalable Video Coding) à la Recommandation UIT-T H.264 / MPEG-4 AVC [RFC6190].  Lors de la rédaction de la [RFC6190], il a été observé que le manque susmentionné dans la prise en charge de la signalisation n'est pas spécifique de SVC, mais s'applique à tous les codecs en couches ou MDC. Donc, le présent mémoire présente une solution générique. Probablement, la seconde technologie qui utilise les mécanismes du présent mémoire va être le codage vidéo multi-vues. Dans le codage vidéo multi-vues (MVC, Multi-View Coding) [RFC6184], les dépendances en couches entre vues sont utilisées pour augmenter l'efficacité du codage, et, donc, les propriétés de MVC par rapport à la signalisation SDP sont comparables à celles de SVC.

Les mécanismes définis ici dépendent du protocole de transport des supports, et applicables seulement en conjonction avec l'utilisation de RTP [RFC3550].

Le groupement dans SDP de lignes de supports de différents types de supports sort du domaine d'application du présent mémoire.

 	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.	Définitions

Flux de supports : comme dans la [RFC4566].

Flux binaire de supports : flux décodable valide, contenant toutes les partitions de supports générées par le codeur. Un flux binaire de supports se conforme normalement à une norme de codage de supports.

Partition de supports : sous ensemble d'un flux binaire de supports destiné à un transport indépendant. Un nombre entier de partitions de supports forme un flux binaire de supports. Dans le codage en couches, une partition de supports représente une ou plusieurs couches qui sont traitées comme un ensemble. Dans le codage MDC, une partition de supports représente une ou plusieurs descriptions qui sont traitées comme un ensemble.

Dépendance de décodage : classe de relations que les partitions de supports ont les unes avec les autres. Le présent mémoire définit pour l'instant deux dépendances de décodage : le codage en couches et le codage de description multiple.

Dépendance de codage en couches : chaque partition de supports est seulement utile (c'est-à-dire, peut être décodée) quand toutes les partitions de supports dont elle dépend sont disponibles. Les dépendances entre les partitions de supports créent donc un graphe dirigé. Note : normalement, dans le codage en couches, plus de partitions de supports sont employées (suivant la règle ci-dessus) meilleure est la qualité reproduite possible.

Dépendance de codage de description multiple : N de M partitions de supports sont exigées pour former un flux binaire de supports, mais il n'y a pas de hiérarchie entre ces partitions de supports. La plupart des schémas de MDC visent à augmenter la qualité des supports reproduits quand plus de partitions de supports sont décodées. Certains schémas de MDC exigent plus d'une partition de supports pour former un point d'opération.

Point d'opération : dans le codage en couches, c'est un sous ensemble d'un flux binaire de supports en couches qui inclut toutes les partitions de supports exigées pour la reconstruction à un certain point de qualité, de résilience à l'erreur, ou autre propriété, et qui n'inclut pas d'autres partitions de supports. En codage MDC, c'est un sous ensemble d'un flux de supports MDC qui est conforme à la norme de codage MDC en question.

 	4.	Motivation, cas d'utilisation, et architecture
 	4.1	Motivation
Le présent mémoire est concerné par deux types de dépendances de décodage : en couche et multi-descriptions. Le transport de codage en couche et le codage multi-descriptions partagent comme motivations clés le désir d'adaptation des supports aux conditions du réseau, c'est-à-dire, relatives à la bande passante, aux taux d'erreurs, à la connexité des points d'extrémité dans les scénarios de diffusion ou de diffusion groupée, etc.

o	Dépendance de décodage en couches : dans le codage en couches, les partitions d'un flux binaire de supports sont appelées des couches de supports ou simplement des couches. Une ou plusieurs couches peuvent être transportées dans différents flux de supports au sens de la [RFC4566]. Un cas d'utilisation classique est celui de la diffusion groupée en couches pilotée par le receveur, dans laquelle un receveur choisit une combinaison de flux de supports en réponse à des exigences de qualité ou de débit binaire. Au milieu des années 1990, les formats de supports en couches et les codecs alors disponibles envisageaient principalement (ou même exclusivement) une hiérarchie unidimensionnelle de couches.  C'est-à-dire, chaque couche dite d'amélioration se référait à exactement une couche "en-dessous". La seule exception a été la couche de base, qui est auto-contenue. Donc, l'identification d'une couche d'amélioration spécifie pleinement le point d'opération d'un schéma de codage en couches, incluant la connaissance de toutes les autres couches qui ont besoin d'être décodées. SDP [RFC4566] contient une prise en charge rudimentaire d'exactement ce cas d'utilisation et des formats de supports, en ce qu'il permet la signalisation d'une gamme d'adresses de transport dans une certaine description de supports. Par définition, une adresse de transport plus élevée identifie une couche supérieure dans la hiérarchie unidimensionnelle. Un receveur a seulement besoin de décoder les données portées sur cette adresse de transport et des adresses de transport inférieures pour décoder ce point d'opération. Les formats de supports plus récents se distinguent de cette simple hiérarchie unidimensionnelle, en ce que des hiérarchies de dépendance très complexes (au moins en forme d'arborescence) peuvent être mises en œuvre. Des cas d'utilisation exigeants pour ces hiérarchies complexes ont été identifiés par l'industrie. Il est donc désirable de les prendre en charge. Cependant, SDP, dans sa forme actuelle, ne permet pas la signalisation de ces relations complexes. Donc, les receveurs ne peuvent pas prendre une décision informée sur les couches à souscrire (dans le cas de diffusion groupée en couches). Les dépendances de décodage en couches peuvent aussi exister dans un environnement de codage multi-vues. Les vues peuvent être codées en utilisant des dépendances inter-vues pour augmenter l'efficacité du codage. Il en résulte des flux binaires de supports qui peuvent être logiquement séparés en partitions de supports qui représentent des vues différentes du signal vidéo reconstruit. Ces partitions de supports ne peuvent pas être décodées indépendamment, et, donc, d'autres partitions de supports sont exigées pour la reconstruction. Pour exprimer cette relation, la signalisation doit exprimer les dépendances des vues, qui à leur tour sont des partitions de supports dans le sens du présent document.

o	Dépendance de décodage descriptive multiple : dans la forme la plus basique de MDC, chaque partition de supports forme une représentation indépendante du support. C'est-à-dire, le décodage de toutes les partitions de supports donne d'utiles données de supports reproduites. Quand plus d'une partition de supports est disponible, un décodeur peut alors les traiter conjointement, et la qualité résultante des supports augmente. La meilleure qualité reproduite est disponible si toutes les partitions de supports originales sont disponibles pour le décodage. Des formes plus complexes de codage de descriptions multiples peuvent aussi être envisagées, c'est-à-dire, lorsque, au minimum, N sur M partitions de supports totales doivent être disponibles pour permettre un décodage significatif. MDC n'a pas encore été bien considéré par la communauté de la normalisation des supports, bien qu'il soit le sujet de nombreuses recherches universitaires. Par exemple, voir [MDC]. Dans le présent mémoire, on traite de MDC parce que a) on envisage que les formats de supports  MDC vont avoir une utilisation pratique durant la vie du présent mémoire, et b) la solution pour sa signalisation est très similaire à celle du codage en couches.

o	Autres relations de dépendance de décodage : au moment de la rédaction du présent mémoire, aucune relation de dépendance de décodage au delà des deux mentionnées ci-dessus n'a été identifiée qui garantirait la normalisation. Cependant, les mécanismes du présent mémoire pourraient être étendus en introduisant de nouveaux codets pour de nouveaux types de dépendance de décodage. Si une telle extension devient nécessaire, comme formellement exigé au paragraphe 5.2.2, le nouveau type de dépendance de décodage DOIT être documenté dans un document de l'IETF sur la voie de la normalisation.

 	4.2	Cas d'utilisation
o	Diffusion groupée en couches pilotée par le receveur : cette technologie est discutée dans la [RFC3550] et on y fait référence ici. On s'abstient de la développer plus ; le sujet est bien connu et compris.

o	Transmission multiple de bout en bout avec différentes propriétés : supposons une topologie d'envoi individuel et point à point, dans laquelle un point d'extrémité envoie des supports à un autre. Supposons de plus que différentes formes de transmission de supports soient disponibles. La différence peut être dans le coût de la transmission (gratuite, taxée) dans la protection disponible (non protégée/sécurisée) dans la qualité de service (QS) (qualité garantie / au mieux, ou dans d'autres facteurs.

Le codage en couches et MDC permet de faire correspondre les caractéristiques de support aux chemins de transmission  disponibles. Par exemple, dans le codage en couches, il y a un sens à porter la couche de base sur une QS élevée. Les couches d'amélioration, par ailleurs, peuvent être portées au mieux, car elles sont "facultatives" dans leur caractéristique -- c'est bien de les avoir, mais elles ne sont pas essentielles pour la consommation du support. Dans un scénario différent, la couche de base peut être offerte dans une session non chiffrée comme visionnage préalable gratuit. Une couche d'amélioration chiffrée fait référence à cette couche de base et permet une exécution de qualité optimale ; cependant, elle est seulement accessible aux utilisateurs qui ont la clé, qui peut avoir été distribuée par un mécanisme d'accès conditionnel.

 	5.	Signalisation des dépendances du support
 	5.1	Principes de conception
La signalisation de dépendance est seulement faisable entre des descriptions de supports décrites avec une ligne "m=" et avec un attribut d'identification de support alloué ("mid") comme défini dans la [RFC3388]. Toutes les descriptions de supports groupées en accord avec la présente spécification DOIVENT avoir le même type de support. Les autres relations de dépendances exprimées par le groupement SDP doivent être traitées dans d'autres spécifications. Une description de support NE DOIT PAS faire partie de plus d'un groupe du type de groupement défini dans la présente spécification.

 	5.2	Sémantique
 	5.2.1	Sémantique de groupement SDP pour la dépendance du décodage
La présente spécification définit une nouvelle sémantique de groupement Dépendance du décodage "DDP":

DDP associe un flux de supports, identifié par son attribut "mid", à un groupe DDP. Chaque flux de supports DOIT être composé d'un nombre entier de partitions de supports. Un flux de supports est identifié par une description unique pour la session du format de supports (numéro de type de charge utile RTP) au sein d'une description de supports. Dans un groupe DDP, tous les flux de supports DOIVENT avoir le même type de dépendance de décodage (comme signalée par l'attribut défini au paragraphe 5.2.2). Tous les flux de supports DOIVENT contenir au moins un point d'opération. Le type de groupe DDP informe un receveur de l'exigence pour le traitement du flux de supports du groupe en accord avec le nouvel attribut de niveau support "depend", comme défini au paragraphe 5.2.2.

Quand on utilise plusieurs codecs, par exemple, pour le modèle d'offre/réponse, le flux de supports DOIT avoir la même structure de dépendance, sans considération de la description de format de supports (numéro de type de charge RTP) utilisée.

 	5.2.2	Attribut "depend" pour la signalisation de dépendance par flux de support
Le présent mémoire définit un nouvel attribut de niveau support, "depend", avec l'ABNF [RFC5234] suivant. L'étiquette d'identification est définie dans la [RFC3388]. Dans l'ABNF suivant, fmt, jeton, SP, et CRLF sont utilisés comme défini dans la [RFC4566].

<DÉBUT DU CODE>

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

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.

depend-attribute = "a=depend:" dependent-fmt SP dependency-tag *(";" SP dependent-fmt SP dependency-tag) CRLF

dependency-tag = dependency-type *1( SP identification-tag ":" fmt-dependency *("," fmt-dependency ))

dependency-type = "lay" / "mdc" / jeton

dependent-fmt = fmt

fmt-dependency = fmt

 <FIN DU CODE>

dependency-tag indique une ou plusieurs dépendances d'un dependent-fmt dans la description des supports. Ces dépendances sont signalées comme des valeurs de fmt-dependency, qui indiquent les valeurs de fmt des autres descriptions de supports. Ces autres descriptions de supports sont identifiées par leurs valeurs de identification-tag dans l'attribut "depend". Il DOIT y avoir exactement une dependency-tag indiquée par dependent-fmt.

dependent-fmt indique la description de format de support, comme défini dans la [RFC4566], qui dépend d'une ou plusieurs descriptions de format de support dans la description de support indiquée par la valeur de la identification-tag dans la dependency-tag.

fmt-dependency indique la description de format de support dans la description de support identifiée par la identification-tag au sein de la dependency-tag, dont dépend le dependent-fmt de la description de supports dépendante. Dans le cas où une liste de valeurs de fmt-dependency est donnée, tout élément de la liste est suffisant pour satisfaire la dépendance, au choix de l'entité décodeuse.

Le "depend-attribute" décrit la dépendance de décodage. Le depend-attribute DOIT être suivi par une séquence de champs dependent-fmt et dependency-tag correspondante, qui identifie toutes les descriptions de format de supports en relation dans toutes les descriptions de supports du dependent-fmt en relation. L'attribut PEUT être utilisé avec la diffusion groupée aussi bien qu'avec des adresses de transport d'envoi individuel. Les valeurs de type de dépendance suivantes sont définies dans le présent mémoire :

o	lay : dépendance de décodage en couche -- identifie le flux de supports décrit comme une ou plusieurs partitions de supports d'un flux binaire de supports en couches. Quand "lay" est utilisé, tous les flux de supports exigés pour le point d'opération de décodage DOIVENT être identifiés par une identification-tag et une fmt-dependency suivant la chaîne "lay".

o	mdc : dépendance de décodage multi-descriptive -- signale que le flux de supports décrit fait partie d'un ensemble de flux binaires de supports MDC. Par définition, au moins N sur M flux de supports du groupe doivent être disponibles à un point d'opération. Les valeurs de N et M dépendent des propriétés du flux binaire de supports et ne sont pas signalés dans ce contexte. Quand "mdc" est utilisé, tous les flux de supports exigés pour le point d'opération DOIVENT être identifiés par une identification-tag et une fmt-dependency suivant la chaîne "mdc".

De plus, les types de dépendances DOIVENT être définis dans un document sur la voie de la normalisation.

 	6.	Usage d'une nouvelle sémantique dans SDP
 	6.1	Usage avec le modèle d'offre/réponse SDP
La rétro compatibilité dans l'offre/réponse est généralement traitée comme spécifié au paragraphe 8.4 de la [RFC3388], comme résumé ci-dessous.

Selon la mise en œuvre, un nœud qui ne comprend pas le groupement DDP (soit ne comprend pas du tout le groupement de lignes, soit ne comprend pas juste la sémantique de DDP) DEVRAIT répondre à une offre contenant un groupement DDP soit (1) avec une réponse qui ignore l'attribut de groupement, soit (2) avec un refus de la demande (par exemple, 488 Non acceptable ici ou 606 Non acceptable dans SIP).

Dans le cas (1), si l'envoyeur original de l'offre souhaite encore établir des communications, il DEVRAIT générer une nouvelle offre avec un seul flux de supports qui représente un point d'opération. Note : dans la plupart des cas, cela va être la couche de base d'un flux binaire de supports en couches ; sont également possibles des points d'opération contenant un ensemble de couches d'amélioration pour autant qu'elles font toutes partie d'un seul flux de supports. Dans le cas (2), si l'envoyeur de l'offre originale a identifié que le refus de la demande est causé par l'utilisation d'un groupement DDP, et si l'envoyeur de l'offre souhaite encore établir la session, il DEVRAIT réessayer la demande avec une offre incluant seulement un flux de supports.

Si le répondeur comprend la sémantique de DDP, il est nécessaire de prendre en considération l'attribut "depend" dans la procédure d'offre/réponse. La principale règle pour l'attribut "depend" est que l'offreur décide du nombre de flux de supports et de la dépendance entre eux. Le répondeur ne peut pas changer les relations de dépendance.

Pour les sessions en envoi individuel où le répondeur reçoit des supports, c'est-à-dire, pour les offres qui incluent des flux de supports qui ont une directionnalité indiquée par "sendonly", "sendrecv", ou n'ont pas de directionnalité indiquée, le répondeur PEUT supprimer les points d'opération de supports. Le répondeur DOIT utiliser les relations de dépendance fournies dans l'offre quand il envoie des supports. Le répondeur PEUT envoyer en accord avec tous les points d'opération présents dans l'offre, même si le répondeur a supprimé certains de ces points d'opération. Donc, un répondeur peut limiter le nombre de points d'opération livrés au répondeur alors que le répondeur peut encore envoyer des supports à l'offreur en utilisant tous les points d'opération indiqués dans l'offre.

Pour une session de diffusion groupée, le répondeur DOIT accepter tous les points d'opération et leurs dépendances de décodage ou DOIT supprimer complètement les points d'opération non acceptés. Du fait de la nature de la diffusion groupée, le receveur peut choisir quels points d'opération il reçoit et traite. Pour une session de diffusion groupée qui permet au répondeur d'envoyer aussi des données, le répondeur PEUT envoyer tous les points d'opération offerts.

Dans tous les cas, si le répondeur ne peut pas accepter un ou plusieurs des points d'opération offerts et/ou les dépendances du flux de supports, le répondeur PEUT réinviter avec une offre incluant les points d'opération acceptables et/ou leurs dépendances.

Note : les applications peuvent limiter la possibilité d'effectuer un re-invite. L'offre précédente est aussi une bonne indication des capacités de l'autre agent.
 	6.2	Usage déclaratif
Si un receveur du protocole de flux en temps réel (RTSP, Real Time Streaming Protocol) comprend la signalisation décrite dans le présent mémoire, il DEVRA établir tous les flux de supports qui sont exigés pour décoder le point d'opération de son choix.

Si un receveur RTSP ne comprend pas la signalisation définie dans le présent mémoire, il revient au traitement SDP normal. Deux cas probables doivent être distingués : (1) si au moins un des types de supports inclus dans le SDP est dans les capacités du receveur, il choisit parmi ces candidats en accord avec les critères spécifiques de la mise en œuvre pour l'établissement, comme normalement ; (2) si aucun des types de supports inclus dans le SDP ne peut être traité, alors évidemment aucun établissement ne peut avoir lieu.

 	6.3	Usage avec AVP et les profils SAVP RTP
Les mécanismes de signalisation définis dans le présent document NE DOIVENT PAS être utilisés pour négocier entre utiliser la paire attribut-valeur (AVP) [RFC3551] et le profil SAVP [RFC3711] pour RTP. Cependant, les deux profils PEUVENT être utilisés séparément ou conjointement avec le mécanisme de signalisation défini dans le présent document.

 	6.4	Usage avec la négociation de capacité
Le présent mémoire ne couvre pas les interactions avec la négociation de capacité [RFC5939]. Cette question fera l'objet de futures études et sera traitée dans un document différent.

 	6.5	Exemples
a.)	Exemple pour signaler la dépendance de décodage en couches :
L'exemple ci-dessous montre une description de session avec trois descriptions de supports, toutes de type vidéo et avec la dépendance de décodage en couches ("lay"). Chaque description de supports inclut deux descriptions possibles de format de support avec différents paramètres de codage comme, par exemple, "mode de mise en paquets" (non montré dans l'exemple) pour les sous types de supports "H264" et "H264-SVC" donnés par la ligne "a=rtpmap:". La première description de support inclut deux types de charge utile H264 comme descriptions de format de support, "96" et "97", comme défini dans la [RFC3984] et représente le point d'opération de la couche de base (identifié par "mid:L1"). Les deux autres descriptions de supports (identifiées par "mid:L2" et "mid:L3") incluent les types de charge utile H264-SVC comme défini dans la [RFC6190], qui contient des améliorations au point d'opération de la couche de base ou le premier point d'opération de couche d'amélioration (description de support identifiée par "mid:L2").

L'exemple montre les dépendances des descriptions de format de support des différentes descriptions de supports indiquées par le groupement "DDP", des attributs "mid", et "depend". L'attribut "depend" est utilisé avec le type de dépendance de décodage "lay" qui indique la dépendance de décodage en couches. Par exemple, la troisième description de support ("m=video 40004...") identifiée par "mid:L3" a des dépendances sur les descriptions de format de support différentes des deux autres descriptions de supports : la description de format de support "100" dépend de la description de format de support "96" ou "97" de la description de support identifiée par "mid:L1". Ceci est un OU exclusif, c'est-à-dire, le type de charge utile "100" peut être utilisé avec le type de charge utile "96" ou "97", mais une des deux combinaisons est exigée pour le décodage du type de charge utile "100".

Pour la description du format de support "101", c'est différent. Celui-ci dépend à la fois de deux des autres descriptions de supports, c'est-à-dire, il dépend de la description du format de support "97" de la description de support identifiée par "mid:L1" et il dépend aussi de la description de format de support "99" de la description de support identifiée par "mid:L2".  Pour décoder la description de format de support "101", les deux descriptions de format de support "97" et "99" sont exigées par définition.

v=0
o=svcsrv 289083124 289083124 IN IP4 host.exemple.com
s=LAYERED VIDEO SIGNALING Seminar
t=0 0
c=IN IP4 192.0.2.1/127
a=group:DDP L1 L2 L3
m=video 40000 RTP/AVP 96 97
b=AS:90
a=tramerate:15
a=rtpmap:96 H264/90000
a=rtpmap:97 H264/90000
a=mid:L1
m=video 40002 RTP/AVP 98 99
b=AS:64
a=tramerate:15
a=rtpmap:98 H264-SVC/90000
a=rtpmap:99 H264-SVC/90000
a=mid:L2
a=depend:98 lay L1:96,97; 99 lay L1:97
m=video 40004 RTP/AVP 100 101
b=AS:128
a=tramerate:30
a=rtpmap:100 H264-SVC/90000
a=rtpmap:101 H264-SVC/90000
a=mid:L3
a=depend:100 lay L1:96,97; 101 lay L1:97 L2:99

b.)	Exemple pour signaler la dépendance de décodage multi-descriptive :
L'exemple montre une description de session avec trois descriptions de supports, toutes de type vidéo et avec une dépendance de décodage multi-descriptive. Chacune des descriptions de supports inclut une description de format de supports. L'exemple montre les dépendances des descriptions de format de supports des différentes descriptions de supports indiquées par le groupement "DDP", et les attributs "mid" et "depend". L'attribut "depend" est utilisé avec le type de dépendance de décodage "mdc" qui indique une dépendance de décodage en couches. Par exemple, la description de  format de supports "104" dans la description de supports ("m=video 40000...") avec "mid:M1" dépend des deux autres descriptions de supports. Elle dépend de la description de format de supports "105" de la description de supports avec "mid:M2", et elle dépend aussi de la description de format de supports "106" de la description de supports avec "mid:M3". Dans le cas de dépendance de décodage multi-descriptive, les descriptions de format de supports "105" et "106" peuvent être utilisées par définition pour améliorer le processus de décodage de la description de format de supports "104", mais elles ne sont pas exigées pour le décodage.

v=0
o=mdcsrv 289083124 289083124 IN IP4 host.exemple.com
s=MULTI DESCRIPTION VIDEO SIGNALING Seminar
t=0 0
c=IN IP4 192.0.2.1/127
a=group:DDP M1 M2 M3
m=video 40000 RTP/AVP 104
a=mid:M1
a=depend:104 mdc M2:105 M3:106
m=video 40002 RTP/AVP 105
a=mid:M2
a=depend:105 mdc M1:104 M3:106
m=video 40004 RTP/AVP 106
a=mid:M3
a=depend:106 mdc M1:104 M2:105

 	7.	Considérations sur la sécurité

Toutes les implications de sécurité de SDP s'appliquent.

Il peut y avoir un risque de manipulation de la signalisation de dépendance d'une description de session par un attaquant. Cela peut conduire à tromper un receveur ou un boîtier de médiation, par exemple, un receveur peut essayer de composer un flux binaire de supports à partir de plusieurs flux de paquets RTP qui ne forment pas un point d'opération, bien que la signalisation lui fasse croire qu'il formerait un point d'opération valide, avec potentiellement des conséquences fatales pour le processus de décodage des supports. Il est recommandé que le receveur DEVRAIT effectuer une vérification d'intégrité sur SDP et qu'il suive les considérations sur la sécurité de SDP pour seulement faire confiance à SDP provenant de sources de confiance.

 	8.	Considérations relatives à l'IANA

Les informations de contact suivantes devront être utilisées pour tous les enregistrements inclus ici :

Contact : Thomas Schierl,  ts@thomas-schierl.de ; tél : +49-30-31002-227

La sémantique suivante a été enregistrée par l'IANA dans la sémantique pour l'attribut "group" SDP dans les paramètres SDP.

Sémantique	Jeton	Référence
Dépendance au décodage	DDP	RFC 5583

L'attribut SDP de niveau support "depend" a été enregistré par l'IANA dans la sémantique pour "att-field (seulement niveau support)". La procédure d'enregistrement du paragraphe 8.2.4 de la [RFC4566] s'applique.

Attribut SDP ("att-field (niveau support seulement)") :
Nom d'attribut : depend
Forme longue : decoding dependency
Type de nom : att-field
Type d'attribut : niveau support seulement
Sujet à jeu de caractères : non
Objet : RFC 5583
Référence : RFC 5583
Valeurs : voir ce document et les enregistrements ci-dessous.

La signification suivante a été enregistrée par l'IANA dans la sémantique pour l'attribut "depend" SDP dans les paramètres SDP :

Sémantique de l'attribut "depend" SDP :

Sémantique	Jeton	Référence
Dépendance de décodage en couches	lay	RFC 5583
Dépendance de décodage multi-descriptive	mdc	RFC 5583

Les nouveaux enregistrements pour la sémantique de l'attribut "depend" de SDP sont ajoutés par la politique de "Spécification exigée" comme défini dans la [RFC5226].

 	9.	Note d'information sur le "cadre de groupement SDP"

Il y a actuellement des travaux sur la [RFC5888]. Dans la [RFC5888], le mécanisme de groupage est étendu de façon à ce que une description de supports puisse faire partie de plus d'un groupe du même type de groupage dans la même description de session. Cependant, les descriptions de supports groupées par le présent document doivent être au plus dans un groupe de type "DDP" dans la même description de session.

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

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

[RFC3551]	H. Schulzrinne et S. Casner, "Profil RTP pour conférences audio et vidéo avec contrôle minimal", STD 65, juillet 2003. (MàJ par RFC8860)

[RFC3711]	M. Baugher et autres, "Protocole de transport sécurisé en temps réel (SRTP)", mars 2004, DOI 10.17487/RFC3711. (P.S. ; MàJ par 9335)

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

 	10.2	Références pour information

[MDC]	Vitali, A., Borneo, A., Fumagalli, M., and R. Rinaldo, "Video over IP using Standard-Compatible Multiple Description Coding:  an IETF proposal", Packet Video Workshop, avril 2006, Hangzhou, China.

[RFC3984]	S. Wenger et autres, "Format de charge utile RTP pour vidéo H.264", février 2005. (P.S., Obsolète, voir RFC6184)

[RFC5888]	G. Camarillo, H. Schulzrinne, "Cadre de groupage du protocole de description de session (SDP)", juin 2010. (Remplace RFC3388). (P. S.  ; MàJ par RFC8843, 9143 )

[RFC5939]	F. Andreasen, "Négociation de capacités dans le protocole de description de session (SDP)", septembre 2010. (P.S.)

[RFC6184]	Y.-K. Wang et autres, "Format de charge utile RTP pour la vidéo H.264", mai 2011. (P.S.)

[RFC6190]	S. Wenger, et autres, "Format de charge utile RTP pour le codage vidéo adaptable", mai  2011. (P.S.)

 	Appendice A.	Remerciements

L'auteur Thomas Schierl de Fraunhofer HHI est sponsorisé par la Commission Européenne sous le contrat numéro FP7-ICT-214063, projet SEA.
Nous voulons aussi remercier Magnus Westerlund, Joerg Ott, Ali Begen, Dan Wing, Helmut Burklin, et Jean-Francois  Mule de leurs précieux et constructifs commentaires du présent mémoire.

 	Adresse des auteurs

Thomas Schierl	Stephan Wenger	
Fraunhofer HHI	2400 Skyfarm Dr.	
Einsteinufer 37	Hillsborough, CA 94010	
D-10587 Berlin	USA	
Germany	mél : stewe@stewe.org	
mél : ts@thomas-schierl.de