4. Requirements (Anforderungen)

Dieser Abschnitt listet die Anforderungen für Peer-to-Peer (P2P)-Datenkanäle zwischen zwei Browsern auf. Bitte beachten Sie, dass dieser Abschnitt nur informativ ist.

Anf. 1: Mehrere gleichzeitige Datenkanäle MÜSSEN unterstützt werden. Beachten Sie, dass es null oder mehr SRTP-Medienstreams parallel zu den Datenkanälen in derselben PeerConnection geben kann, und die Anzahl und der Zustand (aktiv/inaktiv) dieser SRTP-Medienstreams können sich jederzeit ändern.

Anf. 2: Sowohl zuverlässige als auch unzuverlässige Datenkanäle MÜSSEN unterstützt werden.

Anf. 3: Datenkanäle einer PeerConnection MÜSSEN entweder einzeln, als Klasse oder in Verbindung mit den SRTP-Medienstreams der PeerConnection staukontrolliert werden. Dies stellt sicher, dass Datenkanäle keine Stauprobleme für diese SRTP-Medienstreams verursachen und dass die WebRTC-PeerConnection keine übermäßigen Probleme verursacht, wenn sie parallel zu TCP-Verbindungen betrieben wird.

Anf. 4: Die Anwendung SOLLTE in der Lage sein, Hinweise zur relativen Priorität jedes Datenkanals im Verhältnis zueinander und im Verhältnis zu den SRTP-Medienstreams zu geben. Dies wird mit den Staukontrollalgorithmen interagieren.

Anf. 5: Datenkanäle MÜSSEN gesichert sein, was Vertraulichkeit, Integrität und Quellauthentifizierung ermöglicht. Siehe [RFC8826] und [RFC8827] für detaillierte Informationen.

Anf. 6: Datenkanäle MÜSSEN Nachrichtenfragmentierungsunterstützung bereitstellen, sodass IP-Schicht-Fragmentierung vermieden werden kann, unabhängig davon, wie groß eine Nachricht die JavaScript-Anwendung zum Senden übergibt. Es MUSS auch sichergestellt werden, dass große Datenkanalübertragungen den Datenverkehr auf anderen Datenkanälen nicht übermäßig verzögern.

Anf. 7: Das Datenkanalübertragungsprotokoll DARF NICHT lokale IP-Adressen in seinen Protokollfeldern kodieren; dies würde potenziell private Informationen preisgeben und zu Fehlern führen, wenn die Adresse abhängig gemacht wird.

Anf. 8: Das Datenkanalübertragungsprotokoll SOLLTE unbegrenzt lange „Nachrichten" (d. h. einen virtuellen Socket-Stream) auf der Anwendungsschicht für Dinge wie Bilddateiübertragungen unterstützen; Implementierungen könnten eine vernünftige Nachrichtengrößenbeschränkung durchsetzen.

Anf. 9: Das Datenkanalübertragungsprotokoll SOLLTE IP-Fragmentierung vermeiden. Es MUSS Path-MTU (PMTU)-Erkennung unterstützen und DARF NICHT darauf angewiesen sein, dass ICMP oder ICMPv6 generiert oder zurückgegeben wird, insbesondere für die PMTU-Erkennung.

Anf. 10: Es MUSS möglich sein, den Protokoll-Stack im Benutzeranwendungsraum zu implementieren.