4.1.1. Constructor (Konstruktor)
4.1.1. Constructor (Konstruktor)
Der PeerConnection-Konstruktor ermöglicht es der Anwendung, globale Parameter für die Mediensitzung anzugeben, wie z.B. die STUN/TURN-Server und Anmeldeinformationen, die beim Sammeln von Kandidaten verwendet werden sollen, sowie die anfängliche ICE-Kandidatenrichtlinie und Poolgröße und auch die zu verwendende Bundle-Richtlinie.
Wenn eine ICE-Kandidatenrichtlinie angegeben wird, funktioniert sie wie in Abschnitt 3.5.3 beschrieben und bewirkt, dass die JSEP-Implementierung nur die zulässigen Kandidaten (einschließlich jeglicher implementierungsinterner Filterung) an die Anwendung weitergibt und nur diese Kandidaten für Konnektivitätsprüfungen verwendet. Die Menge der verfügbaren Richtlinien ist wie folgt:
all: Alle von der Implementierungsrichtlinie zugelassenen Kandidaten werden gesammelt und verwendet.
relay: Alle Kandidaten außer Relay-Kandidaten werden herausgefiltert. Dies verschleiert die Standortinformationen, die möglicherweise vom entfernten Peer aus den empfangenen Kandidaten ermittelt werden könnten. Je nachdem, wie die Anwendung Relay-Server bereitstellt und auswählt, könnte dies den Standort auf Metro- oder möglicherweise sogar globaler Ebene verschleiern.
Die Standard-ICE-Kandidatenrichtlinie MUSS auf "all" gesetzt werden, da dies im Allgemeinen die gewünschte Richtlinie ist und auch typischerweise die Nutzung der TURN-Server-Ressourcen der Anwendung erheblich reduziert.
Wenn eine Größe für den ICE-Kandidatenpool angegeben wird, gibt dies die Anzahl der ICE-Komponenten an, für die Kandidaten vorab gesammelt werden sollen. Da das Vorsammeln dazu führt, dass STUN/TURN-Server-Ressourcen über potenziell lange Zeiträume genutzt werden, MUSS dies nur auf Anforderung der Anwendung erfolgen, und daher MUSS die Standard-Kandidatenpoolgröße null sein.
Die Anwendung kann ihre bevorzugte Richtlinie bezüglich der Verwendung von Bundle, dem in [RFC8843] definierten Multiplexing-Mechanismus, angeben. Unabhängig von der Richtlinie wird die Anwendung immer versuchen, Bundle auf einem einzigen Transport auszuhandeln und wird eine einzige Bundle-Gruppe über alle "m="-Abschnitte hinweg anbieten; die Verwendung dieses einzelnen Transports hängt davon ab, dass der Antwortende Bundle akzeptiert. Durch Angabe einer Richtlinie aus der Liste unten kann die Anwendung jedoch genau steuern, wie aggressiv sie versucht, Medienströme zu bündeln, was sich darauf auswirkt, wie sie mit einem nicht-bundle-fähigen Endpunkt interagiert. Bei der Verhandlung mit einem nicht-bundle-fähigen Endpunkt werden nur die Ströme eingerichtet, die nicht als nur-bundle-Ströme markiert sind.
Die Menge der verfügbaren Richtlinien ist wie folgt:
balanced: Der erste "m="-Abschnitt jedes Typs (Audio, Video oder Anwendung) enthält Transportparameter, die es einem Antwortenden ermöglichen, diesen Abschnitt zu entbündeln. Der zweite und alle nachfolgenden "m="-Abschnitte jedes Typs werden als nur-bundle markiert. Das Ergebnis ist, dass bei N verschiedenen Medientypen Kandidaten für N Medienströme gesammelt werden. Diese Richtlinie gleicht den Wunsch nach Multiplexing mit der Notwendigkeit aus, sicherzustellen, dass grundlegendes Audio und Video in Legacy-Fällen weiterhin ausgehandelt werden können. Wenn als Antwortender fungiert wird und keine Bundle-Gruppe im Angebot vorhanden ist, lehnt die Implementierung alle außer dem ersten "m="-Abschnitt jedes Typs ab.
max-compat: Alle "m="-Abschnitte enthalten Transportparameter; keiner wird als nur-bundle markiert. Diese Richtlinie ermöglicht es, dass alle Ströme von nicht-bundle-fähigen Endpunkten empfangen werden, erfordert jedoch das Sammeln separater Kandidaten für jeden Medienstrom.
max-bundle: Nur der erste "m="-Abschnitt enthält Transportparameter; alle Ströme außer dem ersten werden als nur-bundle markiert. Diese Richtlinie zielt darauf ab, das Sammeln von Kandidaten zu minimieren und das Multiplexing zu maximieren, auf Kosten geringerer Kompatibilität mit Legacy-Endpunkten. Wenn als Antwortender fungiert wird, lehnt die Implementierung alle "m="-Abschnitte außer dem ersten "m="-Abschnitt ab, es sei denn, sie befinden sich in derselben Bundle-Gruppe wie dieser "m="-Abschnitt.
Da sie den besten Kompromiss zwischen Leistung und Kompatibilität mit Legacy-Endpunkten bietet, MUSS die Standard-Bundle-Richtlinie auf "balanced" gesetzt werden.
Die Anwendung kann ihre bevorzugte Richtlinie bezüglich der Verwendung von RTP/RTCP-Multiplexing [RFC5761] unter Verwendung einer der folgenden Richtlinien angeben:
negotiate: Die JSEP-Implementierung sammelt sowohl RTP- als auch RTCP-Kandidaten, bietet aber auch "a=rtcp-mux" an, wodurch Kompatibilität mit sowohl multiplexenden als auch nicht-multiplexenden Endpunkten ermöglicht wird.
require: Die JSEP-Implementierung sammelt nur RTP-Kandidaten und fügt eine "a=rtcp-mux-only"-Angabe in alle neuen "m="-Abschnitte in Angeboten ein, die sie generiert. Dies halbiert die Anzahl der Kandidaten, die der Anbieter sammeln muss. Das Anwenden einer Beschreibung mit einem "m="-Abschnitt, der kein "a=rtcp-mux"-Attribut enthält, führt dazu, dass ein Fehler zurückgegeben wird.
Die Standard-Multiplexing-Richtlinie MUSS auf "require" gesetzt werden. Implementierungen KÖNNEN wählen, Versuche der Anwendung abzulehnen, die Multiplexing-Richtlinie auf "negotiate" zu setzen.