6. The Usage of SCTP for Data Channels (Die Verwendung von SCTP für Datenkanäle)

6.1. SCTP Protocol Considerations (SCTP-Protokollüberlegungen)

Die in [RFC8261] beschriebene DTLS-Kapselung von SCTP-Paketen MUSS verwendet werden.

Dieser SCTP-Stack und seine obere Schicht MÜSSEN die Verwendung mehrerer SCTP-Streams unterstützen. Eine Benutzernachricht kann geordnet oder ungeordnet und mit partieller oder vollständiger Zuverlässigkeit gesendet werden.

Die folgenden SCTP-Protokollerweiterungen sind erforderlich:

• Die in [RFC6525] definierte Stream-Rekonfigurationserweiterung MUSS unterstützt werden. Sie wird zum Schließen von Kanälen verwendet.
• Die in [RFC5061] definierte dynamische Adressrekonfigurationserweiterung MUSS verwendet werden, um die Unterstützung der in [RFC6525] definierten Stream-Reset-Erweiterung zu signalisieren. Andere Funktionen von [RFC5061] sind OPTIONAL.
• Die in [RFC3758] definierte partielle Zuverlässigkeitserweiterung MUSS unterstützt werden. Zusätzlich zur in [RFC3758] definierten zeitbasierten Zuverlässigkeits-PR-SCTP-Richtlinie MUSS die in [RFC7496] definierte begrenzte Wiederübertragungsrichtlinie unterstützt werden. Die Begrenzung der Anzahl der Wiederübertragungen auf null, kombiniert mit ungeordneter Zustellung, bietet einen UDP-ähnlichen Dienst, bei dem jede Benutzernachricht genau einmal gesendet und in der Empfangsreihenfolge zugestellt wird.

Die Unterstützung für Nachrichtenverschachtelung, wie in [RFC8260] definiert, SOLLTE verwendet werden.

6.2. SCTP Association Management (SCTP-Assoziationsverwaltung)

Im WebRTC-Kontext wird die SCTP-Assoziation eingerichtet, wenn die beiden Endpunkte der WebRTC-PeerConnection sich auf deren Öffnung einigen, wie durch das JavaScript Session Establishment Protocol (JSEP) ausgehandelt, das typischerweise ein Austausch des Session Description Protocol (SDP) [RFC8829] ist. Es wird die über ICE ausgewählte DTLS-Verbindung verwenden, und typischerweise wird diese über BUNDLE oder äquivalent mit DTLS-Verbindungen geteilt, die zur Schlüsselung der SRTP-Medienstreams verwendet werden.

Die Anzahl der während der SCTP-Assoziationseinrichtung ausgehandelten Streams SOLLTE 65535 betragen, was die maximale Anzahl von Streams ist, die während der Assoziationseinrichtung ausgehandelt werden kann.

SCTP unterstützt zwei Methoden zum Beenden einer SCTP-Assoziation. Die erste Methode ist eine elegante, bei der ein Verfahren verwendet wird, das sicherstellt, dass während des Herunterfahrens der Assoziation keine Nachrichten verloren gehen. Die zweite Methode ist eine nicht elegante, bei der eine Seite die Assoziation einfach abbrechen kann.

Wenn eine SCTP-Assoziation auf elegante Weise geschlossen wird, werden alle ihre Datenkanäle geschlossen. Im Fall eines nicht eleganten Abbaus werden alle Datenkanäle ebenfalls geschlossen, aber eine Fehleranzeige SOLLTE wenn möglich bereitgestellt werden.

6.3. SCTP Streams (SCTP-Streams)

SCTP definiert einen Stream als einen unidirektionalen logischen Kanal, der innerhalb einer SCTP-Assoziation zu einem anderen SCTP-Endpunkt existiert. Die Streams werden verwendet, um das Konzept der sequenziellen Zustellung und für Multiplexing bereitzustellen. Jede Benutzernachricht wird auf einem bestimmten Stream gesendet, entweder geordnet oder ungeordnet. Die Reihenfolge wird nur für geordnete Nachrichten beibehalten, die auf demselben Stream gesendet werden.

6.4. Data Channel Definition (Datenkanalsdefinition)

Datenkanäle sind so definiert, dass ihre begleitende API auf Anwendungsebene die API für WebSockets eng widerspiegeln kann, was bidirektionale Datenstreams und ein Textfeld namens „label" impliziert, das zur Identifizierung der Bedeutung des Datenkanals verwendet wird.

Die Realisierung eines Datenkanals ist ein Paar aus einem eingehenden Stream und einem ausgehenden SCTP-Stream mit demselben SCTP-Stream-Bezeichner. Wie diese SCTP-Stream-Bezeichner ausgewählt werden, ist protokoll- und implementierungsabhängig. Dies ermöglicht eine bidirektionale Kommunikation.

Zusätzlich hat jeder Datenkanal in jede Richtung folgende Eigenschaften:

• zuverlässige oder unzuverlässige Nachrichtenübertragung: Im Fall unzuverlässiger Übertragungen wird dasselbe Maß an Unzuverlässigkeit verwendet.
• geordnete oder ungeordnete Nachrichtenzustellung für gesendete Nachrichten.
• eine Priorität, die eine 2-Byte-Ganzzahl ohne Vorzeichen ist: Diese Prioritäten MÜSSEN als Weighted-Fair-Queuing-Scheduling-Prioritäten gemäß der Definition des entsprechenden Stream-Schedulers interpretiert werden, der Verschachtelung in [RFC8260] unterstützt. Für die Verwendung in WebRTC SOLLTEN die verwendeten Werte einer der folgenden sein: 128 („unter normal"), 256 („normal"), 512 („hoch") oder 1024 („extra hoch").
• ein optionales Label.
• ein optionales Protokoll.

6.5. Opening a Data Channel (Öffnen eines Datenkanals)

Datenkanäle können durch Aushandlung innerhalb der SCTP-Assoziation (In-Band-Aushandlung) oder durch Out-of-Band-Aushandlung geöffnet werden. Out-of-Band-Aushandlung ist definiert als jede Methode, die zu einer Einigung über die Parameter eines Kanals und dessen Erstellung führt. Die Details liegen außerhalb des Geltungsbereichs dieses Dokuments.

Ein einfaches Protokoll für die In-Band-Aushandlung ist in [RFC8832] spezifiziert.

Wenn eine Seite einen Kanal über Out-of-Band-Aushandlung öffnen möchte, wählt sie einen Stream. Sofern nicht anders definiert oder ausgehandelt, werden die Streams basierend auf der DTLS-Rolle ausgewählt (der Client wählt gerade Stream-Bezeichner, und der Server wählt ungerade Stream-Bezeichner). Die Anwendung ist jedoch dafür verantwortlich, Kollisionen mit bestehenden Streams zu vermeiden.

6.6. Transferring User Data on a Data Channel (Übertragen von Benutzerdaten auf einem Datenkanal)

Alle auf einem Datenkanal in beide Richtungen gesendeten Daten MÜSSEN über den zugrunde liegenden Stream unter Verwendung der beim Öffnen des Datenkanals definierten Zuverlässigkeit gesendet werden, es sei denn, die Optionen werden geändert oder Optionen pro Nachricht werden von einer höheren Ebene angegeben.

Die Nachrichtenorientierung von SCTP wird verwendet, um die Nachrichtengrenzen von Benutzernachrichten zu erhalten. Daher DÜRFEN Sender NICHT mehr als eine Anwendungsnachricht in eine SCTP-Benutzernachricht einfügen.

Die SCTP Payload Protocol Identifiers (PPIDs) werden verwendet, um die Interpretation der „Nutzlastdaten" zu signalisieren. Die folgenden PPIDs MÜSSEN verwendet werden (siehe Abschnitt 8):

• WebRTC String: zur Identifizierung einer nicht leeren JavaScript-Zeichenkette, die in UTF-8 kodiert ist.
• WebRTC String Empty: zur Identifizierung einer leeren JavaScript-Zeichenkette, die in UTF-8 kodiert ist.
• WebRTC Binary: zur Identifizierung nicht leerer JavaScript-Binärdaten (ArrayBuffer, ArrayBufferView oder Blob).
• WebRTC Binary Empty: zur Identifizierung leerer JavaScript-Binärdaten (ArrayBuffer, ArrayBufferView oder Blob).

SCTP unterstützt das Senden leerer Benutzernachrichten nicht. Wenn daher eine leere Nachricht gesendet werden muss, wird der entsprechende PPID (WebRTC String Empty oder WebRTC Binary Empty) verwendet, und die SCTP-Benutzernachricht von einem Null-Byte wird gesendet.

Die Verwendung der PPIDs „WebRTC String Partial" und „WebRTC Binary Partial" ist veraltet.

Der Sender SOLLTE den Nagle-Algorithmus (siehe [RFC1122]) deaktivieren, um die Latenz zu minimieren.

6.7. Closing a Data Channel (Schließen eines Datenkanals)

Das Schließen eines Datenkanals MUSS durch Zurücksetzen der entsprechenden ausgehenden Streams [RFC6525] signalisiert werden. Das bedeutet, wenn eine Seite beschließt, den Datenkanal zu schließen, setzt sie den entsprechenden ausgehenden Stream zurück. Wenn der Peer sieht, dass ein eingehender Stream zurückgesetzt wurde, setzt er auch seinen entsprechenden ausgehenden Stream zurück. Sobald dies abgeschlossen ist, ist der Datenkanal geschlossen. Das Zurücksetzen eines Streams setzt die Stream Sequence Numbers (SSNs) des Streams auf „null" zurück, mit einer entsprechenden Benachrichtigung an die Anwendungsschicht, dass das Zurücksetzen durchgeführt wurde. Streams sind nach einem Zurücksetzen zur Wiederverwendung verfügbar.

[RFC6525] garantiert auch, dass alle Nachrichten zugestellt (oder aufgegeben) werden, bevor der Stream zurückgesetzt wird.