Zum Hauptinhalt springen

RFC 8854 - WebRTC-Anforderungen an Forward Error Correction

  • Status: Proposed Standard
  • Veröffentlicht: January 2021
  • Stream: IETF
  • Errata: Keine Errata

Zusammenfassung​

Dieses Dokument stellt Informationen und Anforderungen für die Verwendung von Forward Error Correction (FEC) durch WebRTC-Implementierungen bereit.

Status dieses Memos​

Dies ist ein Internet-Standards-Track-Dokument.

Dieses Dokument ist ein Produkt der Internet Engineering Task Force (IETF). Es repräsentiert den Konsens der IETF-Community. Es wurde öffentlich geprüft und von der Internet Engineering Steering Group (IESG) zur Veröffentlichung freigegeben. Weitere Informationen zu Internet-Standards finden sich in Abschnitt 2 von RFC 7841.

Informationen zum aktuellen Status dieses Dokuments, etwaigen Errata und zur Rückmeldung finden sich unter https://www.rfc-editor.org/info/rfc8854.

Urheberrechtshinweis​

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

Dieses Dokument unterliegt BCP 78 und den rechtlichen Bestimmungen des IETF Trust zu IETF-Dokumenten (https://trustee.ietf.org/license-info), die am Datum der Veröffentlichung dieses Dokuments gelten. Bitte prüfen Sie diese Dokumente sorgfältig, da sie Ihre Rechte und Einschränkungen in Bezug auf dieses Dokument beschreiben. Aus diesem Dokument extrahierte Code-Komponenten müssen den Simplified-BSD-License-Text gemäß Abschnitt 4.e der Trust Legal Provisions enthalten und werden ohne Gewährleistung bereitgestellt, wie in der Simplified BSD License beschrieben.

Inhaltsverzeichnis​

1. Einführung​

In Situationen, in denen der Paketverlust hoch ist oder perfekte Medienqualität unerlässlich ist, kann Forward Error Correction (FEC) verwendet werden, um proaktiv von Paketverlusten zu erholen. Diese Spezifikation gibt Hinweise dazu, welche FEC-Mechanismen verwendet werden sollen und wie sie für WebRTC-Implementierungen einzusetzen sind.

2. Terminologie​

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind so zu interpretieren, wie in BCP 14 [RFC2119] [RFC8174] beschrieben, wenn und nur wenn sie wie hier gezeigt in Großbuchstaben erscheinen.

3. Arten von FEC​

FEC beschreibt das Senden redundanter Informationen in einem ausgehenden Paketstrom, sodass Informationen auch bei Paketverlust noch wiederhergestellt werden können. Für RTP-Mediaströme [RFC3550] gibt es mehrere Möglichkeiten, dies zu erreichen; dieser Abschnitt zählt die verfügbaren Mechanismen auf und beschreibt ihre Kompromisse.

3.1. Separater FEC-Strom​

Dieser Ansatz, wie in [RFC5956], Abschnitt 4.3 beschrieben, sendet FEC-Pakete als unabhängigen RTP-Strom mit eigener synchronization source (SSRC) [RFC3550] und eigenem payload type, multiplexiert mit der primären Kodierung. Während dieser Ansatz mehrere Pakete der primären Kodierung mit einem einzigen FEC-Paket schützen kann, hat jedes FEC-Paket seinen eigenen IP/UDP/RTP/FEC-Header, und dieser Overhead kann in manchen Fällen übermäßig sein, z. B. wenn jedes Primärpaket mit einem FEC-Paket geschützt wird.

Dieser Ansatz ermöglicht die Wiederherstellung ganzer RTP-Pakete einschließlich des vollständigen RTP-Headers.

3.2. Redundante Kodierung​

Dieser Ansatz, wie in [RFC2198] beschrieben, ermöglicht es, redundante Daten an eine bestehende primäre Kodierung anzuhängen, alles in einem einzigen Paket. Diese redundanten Daten können eine exakte Kopie eines vorherigen Payloads sein, oder bei Codecs, die variable Bitraten unterstützen, möglicherweise eine kleinere, qualitativ minderwertigere Darstellung. In bestimmten Fällen können die redundanten Daten Kodierungen mehrerer vorheriger Audioframes enthalten.

Da es nur einen Satz Paketheader gibt, erlaubt dieser Ansatz eine sehr effiziente Darstellung primärer und redundanter Daten. Diese Einsparung wird jedoch nur realisiert, wenn die Daten alle in ein einziges Paket passen (d. h. die Größe ist kleiner als eine MTU). Daher ist dieser Ansatz im Allgemeinen für Videoinhalte nicht nützlich.

Wie in [RFC2198], Abschnitt 4 beschrieben, kann dieser Ansatz bestimmte Teile des RTP-Headers nicht wiederherstellen, einschließlich des Marker-Bits, der contributing source (CSRC)-Informationen und der Header-Erweiterungen.

3.3. Codec-spezifische In-Band-FEC​

Einige Audiocodecs, insbesondere Opus [RFC6716] und Adaptive Multi-Rate (AMR) [RFC4867], unterstützen einen eigenen In-Band-FEC-Mechanismus, bei dem redundante Daten im Codec-Payload enthalten sind. Das ist dem oben beschriebenen Mechanismus der redundanten Kodierung ähnlich, kann aber etwas effizienter sein, da keine zusätzliche Rahmenstruktur hinzugefügt wird.

Bei Opus werden als wichtig erachtete Audioframes mit niedrigerer Bitrate neu kodiert und dem nächsten Payload angehängt, was eine teilweise Wiederherstellung eines verlorenen Pakets ermöglicht. Dieses Schema ist recht effizient; Experimente zeigen, dass bei Verwendung von Opus-FEC der auferlegte Overhead je nach erforderlichem Schutzumfang nur etwa 20–30 % beträgt. Beachten Sie, dass dieser Mechanismus nur Redundanzinformationen für den unmittelbar vorhergehenden Audioframe tragen kann; daher kann der Decoder mehrere aufeinanderfolgende verlorene Pakete nicht vollständig wiederherstellen, was in drahtlosen Netzen problematisch sein kann. Siehe [RFC6716], Abschnitt 2.1.7, und diesen Beitrag auf der Opus-Mailingliste [OpusFEC] für weitere Details.

Bei AMR und AMR-Wideband (AMR-WB) können Pakete Kopien oder Kodierungen minderer Qualität mehrerer vorheriger Audioframes enthalten. Siehe [RFC4867], Abschnitt 3.7.1, für Details zu diesem Mechanismus.

In-Band-FEC-Mechanismen können keinen Teil des RTP-Headers wiederherstellen.

4. FEC für Audioinhalte​

Der folgende Abschnitt gibt Hinweise, wie FEC am besten zum Übertragen von Audiodaten verwendet wird. Wie in Abschnitt 8 unten angegeben, sollte FEC nur aktiviert werden, wenn die Netzbedingungen dies rechtfertigen, oder auf ausdrückliche Anforderung der Anwendung.

4.1. Empfohlener Mechanismus​

Bei Verwendung von Codecs mit variabler Bitrate ohne interne FEC ist die redundante Kodierung (wie in Abschnitt 3.2 beschrieben) mit Version(en) geringerer Treue des/der vorherigen Pakete(s) RECOMMENDED. Dies bietet einen angemessenen Schutz des Payloads bei nur mäßiger Bitratenerhöhung, da die redundanten Kodierungen deutlich kleiner als die primäre Kodierung sein können.

Bei Verwendung des Opus-Codecs ist die Nutzung des eingebauten Opus-FEC-Mechanismus RECOMMENDED. Dies bietet einen angemessenen Schutz des Audiostroms gegen einzelne Verluste bei minimalem Overhead. Beachten Sie, dass die eingebaute Opus-FEC, wie oben angegeben, nur Einfachframe-Redundanz bietet; wenn Mehrpaketschutz benötigt wird, SHOULD stattdessen die erwähnte redundante Kodierung mit Opus-Kodierungen reduzierter Bitrate verwendet werden.

Bei Verwendung der AMR/AMR-WB-Codecs ist die Nutzung ihres eingebauten FEC-Mechanismus RECOMMENDED. Dies bietet einen etwas effizienteren Schutz des Audiostroms als die redundante Kodierung.

Bei Verwendung von Codecs mit konstanter Bitrate, z. B. PCMU [RFC5391], MAY redundante Kodierung verwendet werden, dies führt jedoch zu einer potenziell erheblichen Bitratenerhöhung, und das plötzliche Erhöhen der Bitrate zur Bewältigung von Verlusten durch Überlastung kann die Situation tatsächlich verschlechtern.

Wegen der niedrigeren Paketrate von Audiokodierungen, üblicherweise ein Paket pro Frame, ist der Overhead eines separaten FEC-Stroms höher als bei anderen Mechanismen und daher NOT RECOMMENDED.

Wie oben erwähnt, erlauben die empfohlenen Mechanismen keine Wiederherstellung von Teilen des RTP-Headers, die in bestimmten Audioanwendungen wichtig sein können, z. B. CSRCs und RTP-Header-Erweiterungen wie in [RFC6464] und [RFC6465] spezifiziert. Implementierungen SHOULD dies berücksichtigen und versuchen, diese Informationen anzunähern, mit einem Ansatz ähnlich den in [RFC2198], Abschnitt 4, und [RFC6464], Abschnitt 5, beschriebenen.

4.2. Aushandlung der Unterstützung​

Unterstützung für redundante Kodierung eines gegebenen RTP-Stroms SHOULD angezeigt werden, indem audio/red [RFC2198] als zusätzlicher unterstützter Medientyp für den zugehörigen "m="-Abschnitt im SDP-Angebot [RFC3264] aufgenommen wird. Antwortende können die Nutzung der redundanten Kodierung ablehnen, indem sie den Medientyp audio/red im entsprechenden "m="-Abschnitt der SDP-Antwort nicht aufnehmen.

Unterstützung für codec-spezifische FEC-Mechanismen wird typischerweise über "a=fmtp"-Parameter angezeigt.

Für Opus MUST ein Empfänger anzeigen, dass er bereit ist, eingehende FEC-Daten mit dem Parameter "useinbandfec=1" zu verwenden, wie in [RFC7587] spezifiziert. Dieser Parameter ist deklarativ und kann für jede Medienrichtung separat ausgehandelt werden.

Für AMR/AMR-WB werden die Unterstützung redundanter Kodierung und die maximal unterstützte Tiefe durch den Parameter "max-red" gesteuert, wie in [RFC4867], Abschnitt 8.1, spezifiziert. Empfänger MUST diesen Parameter aufnehmen und auf einen geeigneten Wert setzen, wie in [TS.26114], Tabelle 6.3, spezifiziert.

5. FEC für Videoinhalte​

Der folgende Abschnitt gibt Hinweise, wie FEC am besten zum Übertragen von Videodaten verwendet wird. Wie in Abschnitt 8 unten angegeben, sollte FEC nur aktiviert werden, wenn die Netzbedingungen dies rechtfertigen, oder auf ausdrückliche Anforderung der Anwendung.

5.1. Empfohlener Mechanismus​

Videoframes erfordern aufgrund ihrer Größe oft mehrere RTP-Pakete. Wie oben erörtert, kann ein separater FEC-Strom mehrere Pakete mit einem einzigen FEC-Paket schützen. Zusätzlich ist der in [RFC8627] beschriebene Flexible-FEC-Mechanismus auch in der Lage, mehrere RTP-Ströme über einen einzigen FEC-Strom zu schützen, einschließlich aller Ströme, die Teil einer BUNDLE-Gruppe [RFC8843] sind. Daher ist für Videoinhalte die Verwendung eines separaten FEC-Stroms mit dem Flexible-FEC-RTP-Payload-Format RECOMMENDED.

Um den eingehenden FEC-Strom zu verarbeiten, kann der Empfänger ihn per SSRC demultiplexen und ihn dann über die CSRC(s) im RTP-Header von Flexible-FEC-Reparaturpaketen oder das SSRC-Feld im FEC-Header von Flexible-FEC-Retransmissionspaketen mit dem/den geeigneten Primärstrom/Primärströmen korrelieren.

5.2. Aushandlung der Unterstützung​

Unterstützung für einen SSRC-multiplexierten Flexible-FEC-Strom zum Schutz eines gegebenen RTP-Stroms SHOULD angezeigt werden, indem video/flexfec (beschrieben in [RFC8627], Abschnitt 5.1.2) als zusätzlicher unterstützter Medientyp für den zugehörigen "m="-Abschnitt im SDP-Angebot [RFC3264] aufgenommen wird. Wie oben erwähnt, wird bei Verwendung von BUNDLE nur ein einziger Flexible-FEC-Reparaturstrom pro BUNDLE-Gruppe erzeugt, auch wenn Flexible FEC für jeden Primärstrom ausgehandelt wird.

Antwortende können die Nutzung von SSRC-multiplexierter FEC ablehnen, indem sie den Medientyp video/flexfec im entsprechenden "m="-Abschnitt der SDP-Antwort nicht aufnehmen.

Die Verwendung von nur-FEC-"m="-Zeilen und die Gruppierung mit dem SDP-Gruppenmechanismus wie in [RFC5956], Abschnitt 4.1, beschrieben, ist derzeit für WebRTC nicht definiert und SHOULD NOT angeboten werden.

Antwortende SHOULD alle nur-FEC-"m="-Zeilen ablehnen, es sei denn, sie wissen speziell, wie so etwas in einem WebRTC-Kontext zu handhaben ist (möglicherweise definiert durch eine zukünftige Version der WebRTC-Spezifikationen).

6. FEC für Anwendungsinhalte​

WebRTC unterstützt auch die Fähigkeit, generische Anwendungsdaten zu senden, und stellt transportbezogene Retransmissionsmechanismen zur Unterstützung voller und teilweiser (z. B. zeitlich begrenzter) Zuverlässigkeit bereit. Siehe [RFC8831] für Details.

Da die Anwendung genau steuern kann, welche Daten gesendet werden, kann sie Paketstatistiken überwachen und bei Bedarf eigene anwendungsbezogene FEC durchführen.

Daher gibt dieses Dokument keine Empfehlungen zu FEC für den darunterliegenden Datentransport.

7. Implementierungsanforderungen​

Um die oben empfohlene Funktionalität zu unterstützen, MUST Implementierungen die relevanten FEC-Formate für ihre unterstützten Audiocodecs empfangen und nutzen können und MUST diese Unterstützung anzeigen, wie in Abschnitt 4 beschrieben. Die Verwendung dieser Formate beim Senden ist, wie oben erwähnt, RECOMMENDED.

Der allgemeine FEC-Mechanismus aus [RFC8627] SHOULD ebenfalls unterstützt werden, wie in Abschnitt 5 erwähnt.

Implementierungen MAY bei Bedarf zusätzliche FEC-Mechanismen unterstützen, z. B. [RFC5109].

8. Adaptive Nutzung von FEC​

Da die Nutzung von FEC immer zur Übertragung redundanter Daten führt und die Gesamtmenge an Daten innerhalb der von Staukontrolle und Empfänger angegebenen Bandbreitengrenzen bleiben muss, führt dies zu weniger verfügbarer Bandbreite für die primäre Kodierung, selbst wenn die redundanten Daten nicht verwendet werden. Dies steht im Gegensatz zu Methoden wie RTX [RFC4588] oder dem Retransmissionsmodus von Flexible FEC ([RFC8627], Abschnitt 1.1.7), die redundante Daten nur bei Bedarf übertragen, auf Kosten eines zusätzlichen Roundtrips und damit erhöhter Medienlatenz.

Angesichts dessen SHOULD WebRTC-Implementierungen RTX oder Flexible-FEC-Retransmissionen gegenüber FEC bevorzugen, wenn die Verbindungs-RTT im Latenzbudget der Anwendung liegt, und andernfalls SHOULD sie nur die FEC-Menge übertragen, die zum Schutz vor dem beobachteten Paketverlust nötig ist (der z. B. durch Überwachung der Übertragungs-Paketverlustdaten aus RTP Control Protocol (RTCP)-Empfängerberichten [RFC3550] bestimmt werden kann), es sei denn, die Anwendung gibt an, dass sie bereit ist, eine Qualitätsstrafe zu zahlen, um Verluste proaktiv zu vermeiden.

Beachten Sie, dass beim Bandbreiten-Probing, d. h. dem spekulativen Senden zusätzlicher Daten zur Bestimmung vorhandener zusätzlicher Linkkapazität, FEC-Daten als die zusätzlichen Daten SHOULD verwendet werden. Da ohnehin zusätzliche Daten gesendet werden, ist es sinnvoll, dass diese Daten den Primärpayload schützen; zudem kann FEC typischerweise so angewendet werden, dass die Bandbreite nur mäßig steigt, was beim Probing nötig ist.

Bei Verwendung von FEC mit geschichteten Codecs, z. B. [RFC6386], bei denen nur Basislayer-Frames für die Dekodierung künftiger Frames kritisch sind, SHOULD Implementierungen FEC nur auf diese Basislayer-Frames anwenden.

Schließlich ist anzumerken, dass das Anwenden von Redundanz oft nützlich ist, um einen Strom vor Paketverlust zu schützen; wenn der Verlust jedoch durch Netzüberlastung verursacht wird, kann die zusätzliche Bandbreite der redundanten Daten die Situation tatsächlich verschlechtern und zu einer erheblichen Netzverschlechterung führen.

9. Sicherheitsüberlegungen​

Im WebRTC-Kontext befasst sich FEC speziell mit der Wiederherstellung von Daten aus verlorenen Paketen; alle beschädigten Pakete werden durch den Entschlüsselungsprozess des Secure Real-Time Transport Protocol (SRTP) [RFC3711] verworfen. Daher besteht die Standardverarbeitung bei Verwendung von FEC mit SRTP, wie in [RFC3711], Abschnitt 10, beschrieben, darin, am Sender zuerst FEC und dann SRTP und am Empfänger zuerst SRTP und dann FEC auszuführen. Diese Reihenfolge wird für alle in DTLS-SRTP [RFC5763] verwendeten SRTP-Schutzprofile verwendet, die in [RFC5764], Abschnitt 4.1.2, aufgeführt sind.

Zusätzliche Sicherheitsüberlegungen für jeden einzelnen FEC-Mechanismus sind in den jeweiligen Dokumenten aufgeführt.

10. IANA-Überlegungen​

Dieses Dokument erfordert keine Aktionen von IANA.

11. Referenzen​

11.1. Normative Referenzen​

[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. Informative Referenzen​

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

Danksagungen​

Mehrere Personen haben wesentliche Beiträge zu diesem Dokument geleistet, darunter Bernard Aboba, Jonathan Lennox, Giri Mandyam, Varun Singh, Tim Terriberry, Magnus Westerlund und Mo Zanaty.

Adresse des Autors​

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