Aller au contenu principal

RFC 8854 - Exigences de correction d'erreurs sans voie de retour pour WebRTC

  • Statut: Proposed Standard
  • Publié: January 2021
  • Stream: IETF
  • Errata: Pas d'errata

Résumé​

Ce document fournit des informations et des exigences pour l'utilisation de la correction d'erreurs sans voie de retour (Forward Error Correction, FEC) par les implémentations WebRTC.

Statut de ce mémo​

Il s'agit d'un document Internet Standards Track.

Ce document est un produit de l'Internet Engineering Task Force (IETF). Il représente le consensus de la communauté IETF. Il a fait l'objet d'un examen public et a été approuvé pour publication par l'Internet Engineering Steering Group (IESG). Plus d'informations sur les normes Internet sont disponibles dans la Section 2 de RFC 7841.

Des informations sur l'état actuel de ce document, toute errata, et la manière de fournir des commentaires peuvent être obtenues à https://www.rfc-editor.org/info/rfc8854.

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.

Ce document est soumis à la BCP 78 et aux dispositions légales de l'IETF Trust relatives aux documents IETF (https://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Veuillez examiner attentivement ces documents, car ils décrivent vos droits et restrictions concernant ce document. Les composants de code extraits de ce document doivent inclure le texte de la Simplified BSD License tel que décrit dans la Section 4.e des Trust Legal Provisions et sont fournis sans garantie comme décrit dans la Simplified BSD License.

Table des matières​

1. Introduction​

Dans les situations où la perte de paquets est élevée, ou où une qualité média parfaite est essentielle, la correction d'erreurs sans voie de retour (Forward Error Correction, FEC) peut être utilisée pour récupérer de manière proactive les pertes de paquets. Cette spécification fournit des conseils sur les mécanismes FEC à utiliser, et comment les utiliser, pour les implémentations WebRTC.

2. Terminologie​

Les mots clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans BCP 14 [RFC2119] [RFC8174] lorsqu'ils apparaissent, et uniquement lorsqu'ils apparaissent, en majuscules, comme indiqué ici.

3. Types de FEC​

La FEC décrit l'envoi d'informations redondantes dans un flux de paquets sortant afin que les informations puissent encore être récupérées même en cas de perte de paquets. Il existe plusieurs façons d'y parvenir pour les flux média RTP [RFC3550] ; cette section énumère les différents mécanismes disponibles et décrit leurs compromis.

3.1. Flux FEC séparé​

Cette approche, telle que décrite dans [RFC5956], Section 4.3, envoie des paquets FEC comme un flux RTP indépendant avec sa propre synchronization source (SSRC) [RFC3550] et son propre payload type, multiplexé avec le codage principal. Bien que cette approche puisse protéger plusieurs paquets du codage principal avec un seul paquet FEC, chaque paquet FEC aura son propre en-tête IP/UDP/RTP/FEC, et ce surcoût peut être excessif dans certains cas, par exemple lors de la protection de chaque paquet principal par un paquet FEC.

Cette approche permet la récupération de paquets RTP entiers, y compris l'en-tête RTP complet.

3.2. Codage redondant​

Cette approche, telle que décrite dans [RFC2198], permet d'ajouter des données redondantes à un codage principal existant, le tout dans un seul paquet. Ces données redondantes peuvent être une copie exacte d'un payload précédent, ou pour les codecs qui prennent en charge des codages à débit variable, les données redondantes peuvent éventuellement être une représentation plus petite et de moindre qualité. Dans certains cas, les données redondantes peuvent inclure des codages de plusieurs trames audio antérieures.

Comme il n'y a qu'un seul ensemble d'en-têtes de paquets, cette approche permet une représentation très efficace des données principales et redondantes. Cependant, cette économie n'est réalisée que lorsque toutes les données tiennent dans un seul paquet (c'est-à-dire que la taille est inférieure à un MTU). En conséquence, cette approche n'est généralement pas utile pour le contenu vidéo.

Comme décrit dans [RFC2198], Section 4, cette approche ne peut pas récupérer certaines parties de l'en-tête RTP, y compris le bit de marqueur, les informations de contributing source (CSRC), et les extensions d'en-tête.

3.3. FEC en bande spécifique au codec​

Certains codecs audio, notamment Opus [RFC6716] et Adaptive Multi-Rate (AMR) [RFC4867], prennent en charge leur propre mécanisme de FEC en bande, où des données redondantes sont incluses dans le payload du codec. Cela est similaire au mécanisme de codage redondant décrit ci-dessus, mais comme il n'ajoute pas de cadrage supplémentaire, il peut être légèrement plus efficace.

Pour Opus, les trames audio jugées importantes sont recodées à un débit inférieur et ajoutées au payload suivant, permettant une récupération partielle d'un paquet perdu. Ce schéma est assez efficace ; des expériences indiquent que lorsque la FEC Opus est utilisée, le surcoût imposé n'est que d'environ 20-30 %, selon la quantité de protection nécessaire. Notez que ce mécanisme ne peut transporter des informations de redondance que pour la trame audio immédiatement précédente ; ainsi le décodeur ne peut pas récupérer complètement plusieurs paquets perdus consécutifs, ce qui peut être un problème sur les réseaux sans fil. Voir [RFC6716], Section 2.1.7, et ce message de la liste de diffusion Opus [OpusFEC] pour plus de détails.

Pour AMR et AMR-Wideband (AMR-WB), les paquets peuvent contenir des copies ou des codages de moindre qualité de plusieurs trames audio antérieures. Voir [RFC4867], Section 3.7.1, pour les détails sur ce mécanisme.

Les mécanismes de FEC en bande ne peuvent récupérer aucune partie de l'en-tête RTP.

4. FEC pour le contenu audio​

La section suivante fournit des conseils sur la meilleure façon d'utiliser la FEC pour transmettre des données audio. Comme indiqué dans la Section 8 ci-dessous, la FEC ne doit être activée que si les conditions réseau le justifient, ou sur demande explicite de l'application.

4.1. Mécanisme recommandé​

Lors de l'utilisation de codecs à débit variable sans FEC interne, le codage redondant (tel que décrit dans la Section 3.2) avec une ou plusieurs versions de moindre fidélité du ou des paquets précédents est RECOMMENDED. Cela fournit une protection raisonnable du payload avec une augmentation modérée du débit, car les codages redondants peuvent être nettement plus petits que le codage principal.

Lors de l'utilisation du codec Opus, l'utilisation du mécanisme FEC Opus intégré est RECOMMENDED. Cela fournit une protection raisonnable du flux audio contre les pertes individuelles, avec un surcoût minimal. Notez que, comme indiqué ci-dessus, la FEC Opus intégrée ne fournit qu'une redondance sur une seule trame ; si une protection multi-paquets est nécessaire, le codage redondant mentionné ci-dessus avec des codages Opus à débit réduit SHOULD être utilisé à la place.

Lors de l'utilisation des codecs AMR/AMR-WB, l'utilisation de leur mécanisme FEC intégré est RECOMMENDED. Cela fournit une protection légèrement plus efficace du flux audio que le codage redondant.

Lors de l'utilisation de codecs à débit constant, par exemple PCMU [RFC5391], le codage redondant MAY être utilisé, mais cela entraînera une augmentation potentiellement significative du débit, et augmenter soudainement le débit pour faire face aux pertes dues à la congestion peut en fait aggraver la situation.

En raison du débit de paquets plus faible des codages audio, généralement un seul paquet par trame, l'utilisation d'un flux FEC séparé s'accompagne d'un surcoût plus élevé que les autres mécanismes, et est donc NOT RECOMMENDED.

Comme mentionné ci-dessus, les mécanismes recommandés ne permettent pas la récupération de parties de l'en-tête RTP qui peuvent être importantes dans certaines applications audio, par exemple les CSRC et les extensions d'en-tête RTP comme celles spécifiées dans [RFC6464] et [RFC6465]. Les implémentations SHOULD en tenir compte et tenter d'approximer ces informations, en utilisant une approche similaire à celles décrites dans [RFC2198], Section 4, et [RFC6464], Section 5.

4.2. Négociation du support​

Le support du codage redondant d'un flux RTP donné SHOULD être indiqué en incluant audio/red [RFC2198] comme type de média supplémentaire pris en charge pour la section "m=" associée dans l'offre SDP [RFC3264]. Les répondeurs peuvent rejeter l'utilisation du codage redondant en n'incluant pas le type de média audio/red dans la section "m=" correspondante de la réponse SDP.

Le support des mécanismes FEC spécifiques au codec est généralement indiqué via des paramètres "a=fmtp".

Pour Opus, un récepteur MUST indiquer qu'il est prêt à utiliser les données FEC entrantes avec le paramètre "useinbandfec=1", comme spécifié dans [RFC7587]. Ce paramètre est déclaratif et peut être négocié séparément pour chaque direction média.

Pour AMR/AMR-WB, le support du codage redondant, et la profondeur maximale prise en charge, sont contrôlés par le paramètre "max-red", comme spécifié dans [RFC4867], Section 8.1. Les récepteurs MUST inclure ce paramètre et le définir à une valeur appropriée, comme spécifié dans [TS.26114], Tableau 6.3.

5. FEC pour le contenu vidéo​

La section suivante fournit des conseils sur la meilleure façon d'utiliser la FEC pour transmettre des données vidéo. Comme indiqué dans la Section 8 ci-dessous, la FEC ne doit être activée que si les conditions réseau le justifient, ou sur demande explicite de l'application.

5.1. Mécanisme recommandé​

Les trames vidéo, en raison de leur taille, nécessitent souvent plusieurs paquets RTP. Comme discuté ci-dessus, un flux FEC séparé peut protéger plusieurs paquets avec un seul paquet FEC. De plus, le mécanisme Flexible FEC décrit dans [RFC8627] est également capable de protéger plusieurs flux RTP via un seul flux FEC, y compris tous les flux faisant partie d'un groupe BUNDLE [RFC8843]. En conséquence, pour le contenu vidéo, l'utilisation d'un flux FEC séparé avec le format de payload RTP Flexible FEC est RECOMMENDED.

Pour traiter le flux FEC entrant, le récepteur peut le démultiplexer par SSRC, puis le corréler avec le ou les flux principaux appropriés via le ou les CSRC présents dans l'en-tête RTP des paquets de réparation Flexible FEC, ou le champ SSRC présent dans l'en-tête FEC des paquets de retransmission Flexible FEC.

5.2. Négociation du support​

Le support d'un flux Flexible FEC multiplexé par SSRC pour protéger un flux RTP donné SHOULD être indiqué en incluant video/flexfec (décrit dans [RFC8627], Section 5.1.2) comme type de média supplémentaire pris en charge pour la section "m=" associée dans l'offre SDP [RFC3264]. Comme mentionné ci-dessus, lorsque BUNDLE est utilisé, un seul flux de réparation Flexible FEC sera créé pour chaque groupe BUNDLE, même si Flexible FEC est négocié pour chaque flux principal.

Les répondeurs peuvent rejeter l'utilisation de la FEC multiplexée par SSRC en n'incluant pas le type de média video/flexfec dans la section "m=" correspondante de la réponse SDP.

L'utilisation de lignes "m=" uniquement FEC, et le regroupement à l'aide du mécanisme de groupe SDP tel que décrit dans [RFC5956], Section 4.1, n'est pas actuellement défini pour WebRTC, et SHOULD NOT être offert.

Les répondeurs SHOULD rejeter toute ligne "m=" uniquement FEC, sauf s'ils savent spécifiquement comment gérer une telle chose dans un contexte WebRTC (peut-être défini par une future version des spécifications WebRTC).

6. FEC pour le contenu applicatif​

WebRTC prend également en charge la capacité d'envoyer des données applicatives génériques, et fournit des mécanismes de retransmission au niveau du transport pour prendre en charge une fiabilité complète et partielle (par exemple, temporisée). Voir [RFC8831] pour les détails.

Parce que l'application peut contrôler exactement quelles données envoyer, elle a la capacité de surveiller les statistiques de paquets et d'effectuer sa propre FEC au niveau applicatif si nécessaire.

En conséquence, ce document ne fait aucune recommandation concernant la FEC pour le transport de données sous-jacent.

7. Exigences d'implémentation​

Pour prendre en charge la fonctionnalité recommandée ci-dessus, les implémentations MUST être capables de recevoir et d'utiliser les formats FEC pertinents pour leurs codecs audio pris en charge, et MUST indiquer ce support, comme décrit dans la Section 4. L'utilisation de ces formats lors de l'envoi, comme mentionné ci-dessus, est RECOMMENDED.

Le mécanisme FEC général décrit dans [RFC8627] SHOULD également être pris en charge, comme mentionné dans la Section 5.

Les implémentations MAY prendre en charge des mécanismes FEC supplémentaires si désiré, par exemple [RFC5109].

8. Utilisation adaptative de la FEC​

Parce que l'utilisation de la FEC entraîne toujours la transmission de données redondantes, et que la quantité totale de données doit rester dans les limites de bande passante indiquées par le contrôle de congestion et le récepteur, cela conduira à moins de bande passante disponible pour le codage principal, même lorsque les données redondantes ne sont pas utilisées. Cela contraste avec des méthodes comme RTX [RFC4588] ou le mode de retransmission de Flexible FEC ([RFC8627], Section 1.1.7), qui ne transmettent des données redondantes que lorsque nécessaire, au prix d'un aller-retour supplémentaire et donc d'une latence média accrue.

Compte tenu de cela, les implémentations WebRTC SHOULD préférer utiliser RTX ou les retransmissions Flexible FEC au lieu de la FEC lorsque le RTT de la connexion est dans le budget de latence de l'application, et sinon SHOULD uniquement transmettre la quantité de FEC nécessaire pour se protéger contre la perte de paquets observée (qui peut être déterminée, par exemple, en surveillant les données de perte de paquets de transmission des rapports de récepteur RTP Control Protocol (RTCP) [RFC3550]), sauf si l'application indique qu'elle est prête à payer une pénalité de qualité pour éviter proactivement les pertes.

Notez que lors du sondage de la bande passante, c'est-à-dire l'envoi spéculatif de données supplémentaires pour déterminer s'il existe une capacité de lien supplémentaire, les données FEC SHOULD être utilisées comme données supplémentaires. Étant donné que des données supplémentaires vont de toute façon être envoyées, il est logique que ces données protègent le payload principal ; de plus, la FEC peut généralement être appliquée d'une manière qui n'augmente la bande passante que modestement, ce qui est nécessaire lors du sondage.

Lors de l'utilisation de la FEC avec des codecs en couches, par exemple [RFC6386], où seules les trames de la couche de base sont critiques pour le décodage des trames futures, les implémentations SHOULD n'appliquer la FEC qu'à ces trames de la couche de base.

Enfin, il convient de noter que, bien que l'application de la redondance soit souvent utile pour protéger un flux contre la perte de paquets, si la perte est causée par une congestion réseau, la bande passante supplémentaire utilisée par les données redondantes peut en fait aggraver la situation et peut conduire à une dégradation significative du réseau.

9. Considérations de sécurité​

Dans le contexte WebRTC, la FEC est spécifiquement concernée par la récupération de données à partir de paquets perdus ; tout paquet corrompu sera écarté par le processus de déchiffrement du Secure Real-Time Transport Protocol (SRTP) [RFC3711]. Par conséquent, comme décrit dans [RFC3711], Section 10, le traitement par défaut lors de l'utilisation de la FEC avec SRTP est d'effectuer la FEC suivie du SRTP à l'émetteur, et le SRTP suivi de la FEC au récepteur. Cet ordre est utilisé pour tous les profils de protection SRTP utilisés dans DTLS-SRTP [RFC5763], qui sont énumérés dans [RFC5764], Section 4.1.2.

Des considérations de sécurité supplémentaires pour chaque mécanisme FEC individuel sont énumérées dans leurs documents respectifs.

10. Considérations IANA​

Ce document ne nécessite aucune action de la part de l'IANA.

11. Références​

11.1. Références normatives​

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.

[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J.C., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, DOI 10.17487/RFC2198, September 1997, https://www.rfc-editor.org/info/rfc2198.

[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, https://www.rfc-editor.org/info/rfc3264.

[RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 4867, DOI 10.17487/RFC4867, April 2007, https://www.rfc-editor.org/info/rfc4867.

[RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in the Session Description Protocol", RFC 5956, DOI 10.17487/RFC5956, September 2010, https://www.rfc-editor.org/info/rfc5956.

[RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format for the Opus Speech and Audio Codec", RFC 7587, DOI 10.17487/RFC7587, June 2015, https://www.rfc-editor.org/info/rfc7587.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

[RFC8627] Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP Payload Format for Flexible Forward Error Correction (FEC)", RFC 8627, DOI 10.17487/RFC8627, July 2019, https://www.rfc-editor.org/info/rfc8627.

[TS.26114] 3GPP, "IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction", 3GPP TS 26.114 15.0.0, 22 September 2017, http://www.3gpp.org/ftp/Specs/html-info/26114.htm.

11.2. Références informatives​

[OpusFEC] Terriberry, T., "Subject: Opus FEC", message to the opus mailing list, 28 January 2013, http://lists.xiph.org/pipermail/opus/2013-January/001904.html.

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, https://www.rfc-editor.org/info/rfc3550.

[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, https://www.rfc-editor.org/info/rfc3711.

[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, https://www.rfc-editor.org/info/rfc4588.

[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, https://www.rfc-editor.org/info/rfc5109.

[RFC5391] Sollaud, A., "RTP Payload Format for ITU-T Recommendation G.711.1", RFC 5391, DOI 10.17487/RFC5391, November 2008, https://www.rfc-editor.org/info/rfc5391.

[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, https://www.rfc-editor.org/info/rfc5763.

[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, https://www.rfc-editor.org/info/rfc5764.

[RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding Guide", RFC 6386, DOI 10.17487/RFC6386, November 2011, https://www.rfc-editor.org/info/rfc6386.

[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication", RFC 6464, DOI 10.17487/RFC6464, December 2011, https://www.rfc-editor.org/info/rfc6464.

[RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication", RFC 6465, DOI 10.17487/RFC6465, December 2011, https://www.rfc-editor.org/info/rfc6465.

[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, September 2012, https://www.rfc-editor.org/info/rfc6716.

[RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021, https://www.rfc-editor.org/info/rfc8831.

[RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 8843, DOI 10.17487/RFC8843, January 2021, https://www.rfc-editor.org/info/rfc8843.

Remerciements​

Plusieurs personnes ont fourni des contributions significatives à ce document, notamment Bernard Aboba, Jonathan Lennox, Giri Mandyam, Varun Singh, Tim Terriberry, Magnus Westerlund et Mo Zanaty.

Adresse de l'auteur​

Justin Uberti
Google
747 6th St S
Kirkland, WA 98033
United States of America
Email: [email protected]