3.8.2. Parallel Forking (Paralleles Forking)
3.8.2. Parallel Forking (Paralleles Forking)
Paralleles Forking beinhaltet, dass ein Anruf an mehrere entfernte Angerufene gesendet wird, wobei jeder Angerufene den Anruf annehmen kann und als Ergebnis mehrere gleichzeitige aktive Signalisierungssitzungen eingerichtet werden können. Wenn mehrere Angerufene gleichzeitig Medien senden, werden die Möglichkeiten zur Behandlung dieser Situation in [RFC3960], Abschnitt 3.1, beschrieben. Die meisten SIP-Geräte unterstützen heute nur den Medienaustausch mit einem einzelnen Gerät gleichzeitig und versuchen nicht, mehrere Early-Media-Audioquellen zu mischen, da dies zu einer verwirrenden Situation führen könnte. Betrachten Sie beispielsweise, dass ein europäischer Freizeichenton mit dem nordamerikanischen Freizeichenton gemischt wird -- der resultierende Klang wäre wie keiner der beiden Töne und würde den Benutzer verwirren. Wenn die Signalisierungsanwendung nur mit einem der entfernten Endpunkte gleichzeitig Medien austauschen möchte, ist dies aus Sicht der Medien-Engine genau wie der Fall des sequenziellen Forkings.
Im Fall des parallelen Forkings, bei dem die JavaScript-Anwendung gleichzeitig Medien mit mehreren Peers austauschen möchte, ist der Ablauf etwas komplexer, aber die JavaScript-Anwendung kann der Strategie folgen, die [RFC3960] beschreibt, unter Verwendung von UPDATE. Der UPDATE-Ansatz ermöglicht es der Signalisierung, für jeden Peer, mit dem sie Medien austauschen möchte, einen separaten Medienfluss einzurichten. In JSEP würde dieses im UPDATE verwendete Angebot gebildet, indem einfach eine neue PeerConnection erstellt wird (siehe Abschnitt 4.1) und sichergestellt wird, dass dieselben lokalen Medienströme zu dieser neuen PeerConnection hinzugefügt wurden. Dann würde das neue PeerConnection-Objekt ein SDP-Angebot erzeugen, das von der Signalisierung verwendet werden könnte, um die in [RFC3960] diskutierte UPDATE-Strategie auszuführen.
Als Ergebnis des Teilens der Medienströme endet die Anwendung mit N parallelen PeerConnection-Sitzungen, jede mit einer lokalen und entfernten Beschreibung und ihren eigenen lokalen und entfernten Adressen. Der Medienfluss aus diesen Sitzungen kann mit setDirection verwaltet werden (siehe Abschnitt 4.2.3), oder die Anwendung kann wählen, die Medien aus allen Sitzungen gemischt abzuspielen. Wenn die Anwendung natürlich nur eine einzelne Sitzung behalten möchte, kann sie einfach die Sitzungen beenden, die sie nicht mehr benötigt.