5.2.1. Initial Offers (Initiale Angebote)

5.2.1. Initial Offers (Initiale Angebote)

Wenn createOffer zum ersten Mal aufgerufen wird, wird das Ergebnis als initiales Angebot bezeichnet.

Der erste Schritt bei der Generierung eines initialen Angebots besteht darin, Attribute auf Sitzungsebene zu generieren, wie in [RFC4566], Abschnitt 5 spezifiziert. Insbesondere:

• Die erste SDP-Zeile MUSS "v=0" sein, wie in [RFC4566], Abschnitt 5.1 definiert.

• Die zweite SDP-Zeile MUSS eine "o="-Zeile sein, wie in [RFC4566], Abschnitt 5.2 definiert. Der Wert des <username>-Feldes SOLLTE "-" sein. Die <sess-id> MUSS durch eine vorzeichenbehaftete 64-Bit-Ganzzahl darstellbar sein, und der Wert MUSS kleiner als 2^(63)-1 sein. Es wird EMPFOHLEN, dass die <sess-id> durch Generierung einer 64-Bit-Größe konstruiert wird, wobei das höchste Bit auf Null gesetzt ist und die verbleibenden 63 Bits kryptografisch zufällig sind. Der Wert des <nettype> <addrtype> <unicast-address>-Tupels SOLLTE auf eine nicht bedeutungsvolle Adresse gesetzt werden, wie z.B. IN IP4 0.0.0.0, um das Durchsickern einer lokalen IP-Adresse in diesem Feld zu verhindern; dieses Problem wird in [RFC8828] diskutiert. Wie in [RFC4566] erwähnt, muss die gesamte "o="-Zeile eindeutig sein, aber die Auswahl einer Zufallszahl für <sess-id> ist ausreichend, um dies zu erreichen.

• Die dritte SDP-Zeile MUSS eine "s="-Zeile sein, wie in [RFC4566], Abschnitt 5.3 definiert; um der "o="-Zeile zu entsprechen, SOLLTE ein einzelner Bindestrich als Sitzungsname verwendet werden, z.B. "s=-". Beachten Sie, dass dies vom Rat in [RFC4566] abweicht, der ein einzelnes Leerzeichen vorschlägt, aber da sowohl "o=" als auch "s=" in JSEP bedeutungslos sind, scheint es klarer, denselben bedeutungslosen Wert zu haben.

• Sitzungsinformationszeilen ("i="), URI ("u="), E-Mail-Adresse ("e="), Telefonnummer ("p="), Wiederholungszeiten ("r=") und Zeitzonen ("z=") sind in diesem Kontext nicht nützlich und SOLLTEN NICHT enthalten sein.

• Verschlüsselungsschlüsselzeilen ("k=") bieten keine ausreichende Sicherheit und DÜRFEN NICHT enthalten sein.

• Eine "t="-Zeile MUSS hinzugefügt werden, wie in [RFC4566], Abschnitt 5.9 spezifiziert; sowohl <start-time> als auch <stop-time> SOLLTEN auf Null gesetzt werden, z.B. "t=0 0".

• Eine "a=ice-options"-Zeile mit den Optionen "trickle" und "ice2" MUSS hinzugefügt werden, wie in [RFC8840], Abschnitt 4.1.1 und [RFC8445], Abschnitt 10 spezifiziert.

• Wenn WebRTC-Identität verwendet wird, MUSS eine "a=identity"-Zeile hinzugefügt werden, wie in [RFC8827], Abschnitt 5 beschrieben.

Der nächste Schritt besteht darin, "m="-Abschnitte zu generieren, wie in [RFC4566], Abschnitt 5.14 spezifiziert. Für jeden RtpTransceiver, der zur PeerConnection hinzugefügt wurde, wird ein "m="-Abschnitt generiert, ausgenommen gestoppte RtpTransceiver; dies erfolgt in der Reihenfolge, in der die RtpTransceiver zur PeerConnection hinzugefügt wurden.

Jeder "m="-Abschnitt, sofern er nicht als bundle-only markiert ist, MUSS einen eindeutigen Satz von ICE-Anmeldeinformationen und einen eindeutigen Satz von ICE-Kandidaten enthalten. Bundle-only "m="-Abschnitte DÜRFEN KEINE ICE-Anmeldeinformationen enthalten und DÜRFEN KEINE Kandidaten sammeln.

Für DTLS MÜSSEN alle "m="-Abschnitte alle Zertifikate verwenden, die für die PeerConnection spezifiziert wurden; infolgedessen MÜSSEN sie alle denselben Fingerabdruckwert oder dieselben Werte [RFC8122] haben, oder diese Werte MÜSSEN Attribute auf Sitzungsebene sein.