Passa al contenuto principale

RFC 8854 - Requisiti di Forward Error Correction per WebRTC

  • Stato: Proposed Standard
  • Pubblicato: January 2021
  • Stream: IETF
  • Errata: Nessun errata

Abstract​

Questo documento fornisce informazioni e requisiti per l'uso della Forward Error Correction (FEC) da parte delle implementazioni WebRTC.

Stato di questo memo​

Questo è un documento Internet Standards Track.

Questo documento è un prodotto dell'Internet Engineering Task Force (IETF). Rappresenta il consenso della comunità IETF. Ha ricevuto una revisione pubblica ed è stato approvato per la pubblicazione dall'Internet Engineering Steering Group (IESG). Ulteriori informazioni sugli standard Internet sono disponibili nella Sezione 2 di RFC 7841.

Informazioni sullo stato attuale di questo documento, eventuali errata e su come fornire feedback possono essere ottenute all'indirizzo https://www.rfc-editor.org/info/rfc8854.

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

Questo documento è soggetto a BCP 78 e alle disposizioni legali dell'IETF Trust relative ai documenti IETF (https://trustee.ietf.org/license-info) in vigore alla data di pubblicazione di questo documento. Si prega di esaminare attentamente questi documenti, poiché descrivono i propri diritti e le restrizioni rispetto a questo documento. I componenti di codice estratti da questo documento devono includere il testo della Simplified BSD License come descritto nella Sezione 4.e delle Trust Legal Provisions e sono forniti senza garanzia come descritto nella Simplified BSD License.

Indice​

1. Introduzione​

In situazioni in cui la perdita di pacchetti è elevata, o una qualità media perfetta è essenziale, la Forward Error Correction (FEC) può essere usata per recuperare in modo proattivo dalle perdite di pacchetti. Questa specifica fornisce indicazioni su quali meccanismi FEC usare, e come usarli, per le implementazioni WebRTC.

2. Terminologia​

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, compaiono tutte in maiuscolo, come mostrato qui.

3. Tipi di FEC​

La FEC descrive l'invio di informazioni ridondanti in un flusso di pacchetti in uscita in modo che le informazioni possano ancora essere recuperate anche in caso di perdita di pacchetti. Esistono più modi per realizzarlo per i flussi media RTP [RFC3550]; questa sezione enumera i vari meccanismi disponibili e ne descrive i compromessi.

3.1. Flusso FEC separato​

Questo approccio, come descritto in [RFC5956], Sezione 4.3, invia i pacchetti FEC come un flusso RTP indipendente con la propria synchronization source (SSRC) [RFC3550] e payload type, multiplexato con la codifica primaria. Sebbene questo approccio possa proteggere più pacchetti della codifica primaria con un singolo pacchetto FEC, ogni pacchetto FEC avrà la propria intestazione IP/UDP/RTP/FEC, e questo overhead può essere eccessivo in alcuni casi, ad esempio quando si protegge ogni pacchetto primario con un pacchetto FEC.

Questo approccio consente il recupero di interi pacchetti RTP, inclusa l'intestazione RTP completa.

3.2. Codifica ridondante​

Questo approccio, come descritto in [RFC2198], consente di affiancare dati ridondanti a una codifica primaria esistente, tutto in un singolo pacchetto. Questi dati ridondanti possono essere una copia esatta di un payload precedente, oppure, per i codec che supportano codifiche a bitrate variabile, i dati ridondanti possono essere una rappresentazione più piccola e di qualità inferiore. In certi casi, i dati ridondanti potrebbero includere codifiche di più frame audio precedenti.

Poiché c'è un solo insieme di intestazioni di pacchetto, questo approccio consente una rappresentazione molto efficiente di dati primari e ridondanti. Tuttavia, questo risparmio si realizza solo quando i dati entrano tutti in un singolo pacchetto (cioè la dimensione è inferiore a un MTU). Di conseguenza, questo approccio in genere non è utile per i contenuti video.

Come descritto in [RFC2198], Sezione 4, questo approccio non può recuperare certe parti dell'intestazione RTP, incluso il bit marker, le informazioni di contributing source (CSRC) e le estensioni di intestazione.

3.3. FEC in-band specifica del codec​

Alcuni codec audio, in particolare Opus [RFC6716] e Adaptive Multi-Rate (AMR) [RFC4867], supportano un proprio meccanismo di FEC in-band, in cui i dati ridondanti sono inclusi nel payload del codec. Questo è simile al meccanismo di codifica ridondante descritto sopra, ma poiché non aggiunge framing aggiuntivo, può essere leggermente più efficiente.

Per Opus, i frame audio ritenuti importanti vengono ricodificati a un bitrate inferiore e aggiunti al payload successivo, consentendo un recupero parziale di un pacchetto perso. Questo schema è abbastanza efficiente; esperimenti indicano che quando si usa la FEC di Opus, l'overhead imposto è solo di circa il 20-30%, a seconda della quantità di protezione necessaria. Si noti che questo meccanismo può trasportare informazioni di ridondanza solo per il frame audio immediatamente precedente; quindi il decoder non può recuperare completamente più pacchetti persi consecutivi, il che può essere un problema sulle reti wireless. Vedere [RFC6716], Sezione 2.1.7, e questo post della mailing list Opus [OpusFEC] per maggiori dettagli.

Per AMR e AMR-Wideband (AMR-WB), i pacchetti possono contenere copie o codifiche di qualità inferiore di più frame audio precedenti. Vedere [RFC4867], Sezione 3.7.1, per i dettagli su questo meccanismo.

I meccanismi di FEC in-band non possono recuperare alcuna parte dell'intestazione RTP.

4. FEC per contenuti audio​

La sezione seguente fornisce indicazioni su come usare al meglio la FEC per trasmettere dati audio. Come indicato nella Sezione 8 sotto, la FEC dovrebbe essere attivata solo se le condizioni di rete lo giustificano, o su esplicita richiesta dell'applicazione.

4.1. Meccanismo raccomandato​

Quando si usano codec a bitrate variabile senza FEC interna, la codifica ridondante (come descritto nella Sezione 3.2) con versioni a fedeltà inferiore del/i pacchetto/i precedente/i è RECOMMENDED. Ciò fornisce una protezione ragionevole del payload con un aumento di bitrate solo moderato, poiché le codifiche ridondanti possono essere significativamente più piccole della codifica primaria.

Quando si usa il codec Opus, l'uso del meccanismo FEC Opus integrato è RECOMMENDED. Ciò fornisce una protezione ragionevole del flusso audio contro le perdite individuali, con overhead minimo. Si noti che, come indicato sopra, la FEC Opus integrata fornisce solo ridondanza a singolo frame; se è necessaria protezione multi-pacchetto, SHOULD essere usata invece la suddetta codifica ridondante con codifiche Opus a bitrate ridotto.

Quando si usano i codec AMR/AMR-WB, l'uso del loro meccanismo FEC integrato è RECOMMENDED. Ciò fornisce una protezione del flusso audio leggermente più efficiente rispetto alla codifica ridondante.

Quando si usano codec a bitrate costante, ad esempio PCMU [RFC5391], la codifica ridondante MAY essere usata, ma ciò comporterà un potenziale aumento significativo del bitrate, e aumentare improvvisamente il bitrate per affrontare le perdite da congestione può in realtà peggiorare la situazione.

A causa del minore packet rate delle codifiche audio, di solito un singolo pacchetto per frame, l'uso di un flusso FEC separato comporta un overhead più alto rispetto ad altri meccanismi, e quindi è NOT RECOMMENDED.

Come accennato sopra, i meccanismi raccomandati non consentono il recupero di parti dell'intestazione RTP che possono essere importanti in certe applicazioni audio, ad esempio CSRC ed estensioni di intestazione RTP come quelle specificate in [RFC6464] e [RFC6465]. Le implementazioni SHOULD tenerne conto e tentare di approssimare queste informazioni, usando un approccio simile a quelli descritti in [RFC2198], Sezione 4, e [RFC6464], Sezione 5.

4.2. Negoziazione del supporto​

Il supporto per la codifica ridondante di un dato flusso RTP SHOULD essere indicato includendo audio/red [RFC2198] come tipo di media supportato aggiuntivo per la sezione "m=" associata nell'offerta SDP [RFC3264]. I risponditori possono rifiutare l'uso della codifica ridondante non includendo il tipo di media audio/red nella corrispondente sezione "m=" nella risposta SDP.

Il supporto per i meccanismi FEC specifici del codec è tipicamente indicato tramite parametri "a=fmtp".

Per Opus, un ricevitore MUST indicare che è preparato a usare i dati FEC in ingresso con il parametro "useinbandfec=1", come specificato in [RFC7587]. Questo parametro è dichiarativo e può essere negoziato separatamente per ciascuna direzione media.

Per AMR/AMR-WB, il supporto per la codifica ridondante, e la profondità massima supportata, sono controllati dal parametro "max-red", come specificato in [RFC4867], Sezione 8.1. I ricevitori MUST includere questo parametro e impostarlo a un valore appropriato, come specificato in [TS.26114], Tabella 6.3.

5. FEC per contenuti video​

La sezione seguente fornisce indicazioni su come usare al meglio la FEC per trasmettere dati video. Come indicato nella Sezione 8 sotto, la FEC dovrebbe essere attivata solo se le condizioni di rete lo giustificano, o su esplicita richiesta dell'applicazione.

5.1. Meccanismo raccomandato​

I frame video, a causa delle loro dimensioni, spesso richiedono più pacchetti RTP. Come discusso sopra, un flusso FEC separato può proteggere più pacchetti con un singolo pacchetto FEC. Inoltre, il meccanismo Flexible FEC descritto in [RFC8627] è anche capace di proteggere più flussi RTP tramite un singolo flusso FEC, inclusi tutti i flussi che fanno parte di un gruppo BUNDLE [RFC8843]. Di conseguenza, per i contenuti video, l'uso di un flusso FEC separato con il formato di payload RTP Flexible FEC è RECOMMENDED.

Per elaborare il flusso FEC in ingresso, il ricevitore può demultiplexarlo per SSRC, e poi correlarlo con i flussi primari appropriati tramite i CSRC presenti nell'intestazione RTP dei pacchetti di riparazione Flexible FEC, o il campo SSRC presente nell'intestazione FEC dei pacchetti di ritrasmissione Flexible FEC.

5.2. Negoziazione del supporto​

Il supporto per un flusso Flexible FEC multiplexato per SSRC per proteggere un dato flusso RTP SHOULD essere indicato includendo video/flexfec (descritto in [RFC8627], Sezione 5.1.2) come tipo di media supportato aggiuntivo per la sezione "m=" associata nell'offerta SDP [RFC3264]. Come accennato sopra, quando si usa BUNDLE, verrà creato un solo flusso di riparazione Flexible FEC per ciascun gruppo BUNDLE, anche se Flexible FEC è negoziato per ciascun flusso primario.

I risponditori possono rifiutare l'uso della FEC multiplexata per SSRC non includendo il tipo di media video/flexfec nella corrispondente sezione "m=" nella risposta SDP.

L'uso di righe "m=" solo-FEC, e il raggruppamento usando il meccanismo di gruppo SDP come descritto in [RFC5956], Sezione 4.1, non è attualmente definito per WebRTC, e SHOULD NOT essere offerto.

I risponditori SHOULD rifiutare qualsiasi riga "m=" solo-FEC, a meno che non sappiano specificamente come gestire una tale cosa in un contesto WebRTC (forse definito da una futura versione delle specifiche WebRTC).

6. FEC per contenuti applicativi​

WebRTC supporta anche la capacità di inviare dati applicativi generici, e fornisce meccanismi di ritrasmissione a livello di trasporto per supportare affidabilità completa e parziale (ad esempio, temporizzata). Vedere [RFC8831] per i dettagli.

Poiché l'applicazione può controllare esattamente quali dati inviare, ha la capacità di monitorare le statistiche dei pacchetti ed eseguire la propria FEC a livello applicativo se necessario.

Di conseguenza, questo documento non formula raccomandazioni riguardo alla FEC per il trasporto dati sottostante.

7. Requisiti di implementazione​

Per supportare la funzionalità raccomandata sopra, le implementazioni MUST essere in grado di ricevere e usare i formati FEC rilevanti per i loro codec audio supportati, e MUST indicare questo supporto, come descritto nella Sezione 4. L'uso di questi formati in invio, come accennato sopra, è RECOMMENDED.

Il meccanismo FEC generale descritto in [RFC8627] SHOULD essere anche supportato, come accennato nella Sezione 5.

Le implementazioni MAY supportare meccanismi FEC aggiuntivi se desiderato, ad esempio [RFC5109].

8. Uso adattivo della FEC​

Poiché l'uso della FEC causa sempre la trasmissione di dati ridondanti, e la quantità totale di dati deve rimanere entro eventuali limiti di banda indicati dal controllo di congestione e dal ricevitore, ciò porterà a meno banda disponibile per la codifica primaria, anche quando i dati ridondanti non vengono usati. Ciò contrasta con metodi come RTX [RFC4588] o la modalità di ritrasmissione di Flexible FEC ([RFC8627], Sezione 1.1.7), che trasmettono dati ridondanti solo quando necessario, al costo di un round trip extra e quindi di una latenza media aumentata.

Dato questo, le implementazioni WebRTC SHOULD preferire l'uso di RTX o ritrasmissioni Flexible FEC invece della FEC quando l'RTT della connessione è entro il budget di latenza dell'applicazione, e altrimenti SHOULD trasmettere solo la quantità di FEC necessaria a proteggere contro la perdita di pacchetti osservata (che può essere determinata, ad esempio, monitorando i dati di perdita di pacchetti in trasmissione dai report del ricevitore RTP Control Protocol (RTCP) [RFC3550]), a meno che l'applicazione non indichi di essere disposta a pagare una penalità di qualità per evitare proattivamente le perdite.

Si noti che quando si sonda la banda, cioè inviando speculativamente dati extra per determinare se esiste capacità di link aggiuntiva, i dati FEC SHOULD essere usati come i dati aggiuntivi. Dato che i dati extra verranno comunque inviati, ha senso che tali dati proteggano il payload primario; inoltre, la FEC può tipicamente essere applicata in modo da aumentare la banda solo modestamente, il che è necessario quando si sonda.

Quando si usa la FEC con codec a livelli, ad esempio [RFC6386], dove solo i frame del layer di base sono critici per la decodifica di frame futuri, le implementazioni SHOULD applicare la FEC solo a questi frame del layer di base.

Infine, va notato che, sebbene applicare la ridondanza sia spesso utile per proteggere un flusso contro la perdita di pacchetti, se la perdita è causata da congestione di rete, la banda aggiuntiva usata dai dati ridondanti può in realtà peggiorare la situazione e può portare a un degrado significativo della rete.

9. Considerazioni sulla sicurezza​

Nel contesto WebRTC, la FEC si occupa specificamente del recupero di dati da pacchetti persi; eventuali pacchetti corrotti saranno scartati dal processo di decrittazione del Secure Real-Time Transport Protocol (SRTP) [RFC3711]. Pertanto, come descritto in [RFC3711], Sezione 10, l'elaborazione predefinita quando si usa FEC con SRTP è eseguire FEC seguito da SRTP al mittente, e SRTP seguito da FEC al ricevitore. Questo ordinamento è usato per tutti i profili di protezione SRTP usati in DTLS-SRTP [RFC5763], che sono enumerati in [RFC5764], Sezione 4.1.2.

Ulteriori considerazioni di sicurezza per ciascun meccanismo FEC individuale sono enumerate nei rispettivi documenti.

10. Considerazioni IANA​

Questo documento non richiede azioni da parte di IANA.

11. Riferimenti​

11.1. Riferimenti normativi​

[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. Riferimenti informativi​

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

Ringraziamenti​

Diverse persone hanno fornito input significativi a questo documento, tra cui Bernard Aboba, Jonathan Lennox, Giri Mandyam, Varun Singh, Tim Terriberry, Magnus Westerlund e Mo Zanaty.

Indirizzo dell'autore​

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