Groupe de travail Réseau	A. Li, Hyervision
Request for Comments : 4756	novembre 2006
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

Sémantique du groupage de correction d'erreur directe 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 en cours de 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 Copyright
Copyright (C) The Internet Society (2006).

Résumé
Le présent document définit la sémantique qui permet le groupage de flux de correction d'erreur directe (FEC, Forward Error Correction) avec les flux de charge utile protégée dans le protocole de description de session (SDP, Session Description Protocol). La sémantique définie dans ce document est d'être utilisée avec le "groupage de lignes de supports dans le protocole de description de session" (RFC 3388) pour grouper ensemble les lignes "m" dans la même session.
Table des matières
1. Introduction	1
2. Terminologie	2
3. Correction d'erreur directe	2
4. Groupage de FEC	2
4.1 Groupe de FEC	2
4.2 Considérations d’offre/réponse	2
4.3 Exemple de groupage de FEC	3
5. Considérations sur la sécurité	3
6. Considérations relatives à l'IANA	3
7. Remerciements	3
8. Références	4
8.1 Références normatives	4
8.1 Références pour information	4
Adresse de l'auteur	4
Déclaration complète de droits de reproduction	4

 	1.	Introduction

Les lignes de supports (media) dans une session SDP [RFC4566] peuvent être associées à chaque autre de diverses façons. SDP lui-même ne donne pas de méthode pour porter les relations entre les lignes de supports. De telles relations sont indiquées par l'extension à SDP définie dans "Groupage des lignes de support dans le protocole de description de session" [RFC3388]. La RFC 3388 définit deux types de sémantiques : synchronisation de bord et identification de flux.

La correction d'erreur directe (FEC, Forward Error Correction) est une technique courante pour réaliser une communication robuste dans des environnements enclins à l'erreur. Dans le présent document, on définit la sémantique qui permet le groupage des flux de FEC avec les flux protégés de charge utile dans SDP en étendant un peu plus la RFC  3388.

 	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.	Correction d'erreur directe

La correction d'erreur directe (FEC, Forward Error Correction) est une technique courante pour réaliser une communication robuste dans des environnements enclins à l'erreur. Dans la FEC, la communication utilise une bande passante qui est plus que la charge utile à envoyer de façon redondante avec des informations de charge utile codées. Les receveurs peuvent directement récupérer la charge utile d'origine même quand une partie de la communication est perdue dans la transmission. Comparée aux autres techniques de correction d'erreur (comme la retransmission) la FEC peut réaliser un délai de transmission beaucoup plus faible, et elle ne pose pas de problème d'explosion des demandes de retransmission comme dans divers scénarios de diffusion groupée.

En général, les données de FEC peuvent être envoyés de deux façons différentes : (1) multiplexées avec le flux de charge utile d'origine ou (2) comme un flux séparé. Il est donc nécessaire de définir des mécanismes pour indiquer la relation d'association entre les données de FEC et les données de charge utile qu'elles protègent.

Quand les données de FEC sont multiplexées avec le flux de charge utile d'origine, la relation d'association peut, par exemple, être indiquée comme spécifié dans "Charge utile RTP pour données audio redondantes" [RFC2198]. Le format générique de charge utile RTP pour la FEC [RFC5109] utilise cette méthode.

Quand les données de FEC sont envoyées comme un flux séparé à partir des données de la charge utile, la relation d'association peut être indiquée de diverses façons. Le présent document sur le groupage de lignes de support de FEC spécifie un mécanisme pour indiquer une telle relation.

 	4.	Groupage de FEC
 	4.1	Groupe de FEC
Chaque ligne "a=group" est utilisée pour indiquer une relation d'association entre les flux de FEC et les flux de charge utile. Les flux inclus dans une ligne "a=group" sont appelés un "groupe FEC".

Chaque groupe FEC PEUT avoir un ou plusieurs flux de FEC, et un ou plusieurs flux de charge utile. Par exemple, il est possible d'avoir un flux de charge utile protégé par plus d'un flux de FEC, ou plusieurs flux de charge utile qui partagent un flux de FEC.

Le groupage de flux dans un groupe FEC indique seulement la relation d'association entre les flux. Les schémas/paramètres détaillés de protection de FEC sont convoyés par le mécanisme de l'algorithme particulier de FEC utilisé. Par exemple, le groupage de FEC est utilisé pour la charge utile générique RTP pour la FEC [RFC5109] pour indiquer la relation d'association entre les flux de FEC et le flux de charge utile. Le niveau détaillé de protection et les informations de longueur pour l'algorithme de protection de perte inégale (ULP, Unequal Loss Protection) sont communiqués dans la bande au sein du flux de FEC.

 	4.2	Considérations d’offre/réponse
La rétro compatibilité en offre/réponse est généralement traitée comme spécifié dans la [RFC3388].

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

Dans le premier cas, l'envoyeur original de l'offre DOIT établir la connexion sans FEC. Dans le second cas, si l'envoyeur de l'offre souhaite quand même établir la session, il DEVRAIT réessayer la demande avec une offre sans FEC.

 	4.3	Exemple de groupage de FEC
L'exemple suivant montre une description de session de conférence en diffusion groupée. Le premier flux de supports (mid:1) contient le flux audio. Le second flux de supports (mid:2) contient la protection de FEC générique [RFC5109] pour le flux audio. Ces deux flux forment un groupe FEC. La relation entre les deux flux est indiquée par la ligne "a=group:FEC 1 2". Le flux de FEC est envoyé au même groupe de diffusion groupée et a la même durée de vie (TTL, Time to Live) que l'audio, mais sur un numéro d'accès supérieur de deux. De même, le flux vidéo (mid:3) et son flux générique de protection de FEC (mid:4) forme un autre groupe FEC. La relation entre les deux flux est indiquée par la ligne "a=group:FEC 3 4". Le flux de FEC est envoyé à une adresse de diffusion groupée différente, mais a le même numéro d'accès (30004) que le flux de charges utiles de vidéo.

v=0
o=adam 289083124 289083124 IN IP4 host.exemple.com
s=Seminaire ULP FEC 
t=0 0
c=IN IP4 224.2.17.12/127
a=group:FEC 1 2
a=group:FEC 3 4
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30002 RTP/AVP 100
a=rtpmap:100 ulpfec/8000
a=mid:2
m=video 30004 RTP/AVP 31
a=mid:3
m=video 30004 RTP/AVP 101
c=IN IP4 224.2.17.13/127
a=rtpmap:101 ulpfec/8000
a=mid:4

 	5.	Considérations sur la sécurité

Il y a une faible menace pour le receveur que le groupage de FEC puisse être modifié pour indiquer des relations de FEC qui n'existent pas. De telles attaques pourraient résulter en l'échec de la FEC à protéger, et/ou en un mauvais traitement d'autres flux de charges utiles de supports. Il est RECOMMANDÉ que le receveur fasse une vérification d'intégrité sur SDP et suive les considérations sur la sécurité de SDP [RFC4566] pour ne faire confiance qu'à du SDP provenant de sources de confiance.

 	6.	Considérations relatives à l'IANA

Le présent document définit la sémantique à utiliser avec le groupage de lignes de supports dans SDP comme défini dans la RFC 3388. La sémantique définie dans le présent document est à enregistrer par l'IANA quand elle est publiée dans des RFC sur la voie de la normalisation.

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

Sémantique	Jeton	Référence
Correction d'erreur directe	FEC	RFC 4756

 	7.	Remerciements

L'auteur tient à remercier Magnus Westerlund, Colin Perkins, Joerg Ott, et Cullen Jennings de leurs réactions sur ce document.

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

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

 	8.1	Références pour information

[RFC2198]	C. Perkins et autres, "Charge utile RTP pour données audio redondantes", septembre 1997. (P.S.)

[RFC5109]	A. Li, éd., "Format de charge utile RTP pour la correction générique d'erreur directe", décembre 2007. (Remplace RFC2733, RFC3009) (P.S.)

 	Adresse de l'auteur
Adam H. Li
HyerVision
10194 Wateridge Circle #152
San Diego, CA 92121
U.S.A.

Téléphone : +1 858 622 9038
mél : adamli@hyervision.com 

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2006).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement 
Le financement de la fonction d’édition des RFC est fourni par l'activité de soutien administratif (IASA) de l'IETF.