4. Anforderungen und Implementierung

Der nächste Abschnitt beschreibt die Anforderungen im Detail und erörtert die Implementierung der gemeinsamen Erscheinungsfunktion.

4.1. Anforderungen

Die grundlegenden Anforderungen der gemeinsamen Erscheinungsfunktion können wie folgt zusammengefasst werden:

REQ-1: Eingehende Anrufe an den AOR müssen einer Gruppe von UAs angeboten werden und können von jedem von ihnen beantwortet werden.

REQ-2: Jede UA in der Gruppe muss in der Lage sein, den Anrufstatus der anderen in der Gruppe zu erfahren, um diese Informationen dem Benutzer darzustellen.

REQ-3: Eine UA muss in der Lage sein, einem aktiven Anruf einer anderen UA in der Gruppe auf sichere Weise beizutreten (auch Bridge oder Conference Together genannt) oder ihn zu übernehmen (Take).

REQ-4: Der Mechanismus sollte minimalen Konfigurationsaufwand erfordern. UAs, die sich gegen den Gruppen-AOR registrieren, sollten ohne manuelle Konfiguration der Gruppenmitglieder an der gemeinsamen Erscheinungsgruppe teilnehmen können.

REQ-5: Der Mechanismus muss für große Anzahlen von Erscheinungen und große Anzahlen von UAs skalierbar sein, ohne übermäßigen Nachrichtenverkehr einzuführen.

REQ-6: Jedem Anruf oder jeder Sitzung (eingehend oder ausgehend) sollte eine gemeinsame "Erscheinungs"-Nummer aus einem verwalteten Pool zugewiesen werden, der für die AOR-Gruppe verwaltet wird. Sobald die Sitzung beendet ist, wird die Erscheinungsnummer in den Pool zurückgegeben und kann von einer anderen eingehenden oder ausgehenden Sitzung wiederverwendet werden.

REQ-7: Jede UA in der Gruppe muss in der Lage sein, den Status aller Erscheinungen der Gruppe zu erfahren.

REQ-8: Es müssen Mechanismen vorhanden sein, um Erscheinungskonflikte zwischen den UAs in der Gruppe zu lösen. Konflikt in diesem Kontext bedeutet, dass eine Erscheinungsnummer mit mehreren Dialogen verbunden ist, die nicht gemischt oder anderweitig verknüpft sind.

REQ-9: Der Mechanismus muss es allen UAs, die eine eingehende Sitzungsanfrage erhalten, ermöglichen, zum Zeitpunkt der Alarmierung dieselbe Erscheinungsnummer zu verwenden.

REQ-10: Der Mechanismus muss eine Möglichkeit haben, den Erscheinungszustand nach einem Ausfall zu rekonstruieren, der nicht zu übermäßigem Verkehr und Verarbeitung führt.

REQ-11: Der Mechanismus muss Abwärtskompatibilität aufweisen, so dass eine UA, die die Funktion nicht kennt, sich immer noch gegen den Gruppen-AOR registrieren und Anrufe tätigen und empfangen kann.

REQ-12: Der Mechanismus darf es UAs außerhalb der Gruppe nicht erlauben, Erscheinungsnummern auszuwählen, zu besetzen oder zu manipulieren.

REQ-13: Aus Datenschutzgründen muss ein Mechanismus vorhanden sein, damit Erscheinungsinformationen nicht außerhalb der Gruppe von UAs durchsickern (z. B. "Also, wen haben Sie auf Leitung 1?").

REQ-14: Der Mechanismus muss eine Möglichkeit für UAs unterstützen, Exklusivität auf einer Leitungserscheinung anzufordern. Exklusivität bedeutet, dass die UA, die sie anfordert, ein privates Gespräch mit der externen Partei wünscht und anderen UAs nicht erlaubt werden darf, dem Anruf beizutreten oder ihn zu übernehmen. Exklusivität kann zu Beginn einer eingehenden oder ausgehenden Sitzung oder während der Sitzung angefordert werden. Eine Exklusivitätsanfrage kann von der Entität, die den gemeinsamen Erscheinungsdienst bereitstellt, akzeptiert oder abgelehnt werden. Daher muss der Mechanismus eine Möglichkeit bieten, das Ergebnis an die anfordernde UA zurückzukommunizieren.

REQ-15: Der Mechanismus sollte eine Möglichkeit für eine UA unterstützen, eine bestimmte Erscheinungsnummer für ausgehende Anfragen vor dem Senden der tatsächlichen Anfrage zu besetzen. Dies wird oft als Seizure bezeichnet.

REQ-16: Der Mechanismus sollte eine Möglichkeit für eine UA unterstützen, eine bestimmte Erscheinungsnummer zu besetzen und gleichzeitig die Anfrage zu senden. Dies ist erforderlich, wenn eine automatische Ringdown-Funktion (ein Telefon, das so konfiguriert ist, dass es sofort eine Telefonnummer wählt, wenn es abgehoben wird) mit gemeinsamen Erscheinungen kombiniert wird. In diesem Fall ist das Besetzen der Leitung mit dem Wählen integriert.

4.2. Implementierung

Dieser Abschnitt erörtert nicht normativ die Implementierung der gemeinsamen Erscheinungsfunktion. Die normative Beschreibung befindet sich in Abschnitt 5. Viele der Anforderungen für diesen Dienst können unter Verwendung von Standard-SIP-Mechanismen erfüllt werden, wie z. B.:

• Ein SIP-Forking-Proxy und Registrar/Location-Service erfüllt REQ-1.

• Das SIP-Dialog-Paket erfüllt REQ-2.

• Die Kombination der SIP-Replaces- und Join-Header-Felder erfüllt REQ-3.

• Die Verwendung eines State Agents für das Dialog-Paket erfüllt REQ-4 und REQ-5.

REQ-6 deutet auf die Notwendigkeit einer Entität hin, die die Erscheinungsressource verwaltet. So wie Konferenzsysteme üblicherweise einen einzigen Kontrollpunkt haben, der als Fokus bekannt ist, hat eine gemeinsame Erscheinungsgruppe einen einzigen Kontrollpunkt der gemeinsam genutzten Erscheinungsressource. Dies wird als Appearance Agent für eine Gruppe definiert. Während ein Appearance Agent Teil eines zentralisierten Servers sein kann, könnte er auch in einer Mitglieds-UA mitresidieren, die diese Funktionalität für eine Gruppe übernommen hat. Der Appearance Agent kennt oder ist in der Lage, den Dialogzustand aller Mitglieder der Gruppe zu bestimmen.

Während die Erscheinungsressource von einer Gruppe von UAs ohne zentrale Kontrolle kooperativ verwaltet werden könnte, liegt dies außerhalb des Geltungsbereichs dieses Dokuments. Es ist auch möglich, dass die Appearance-Agent-Logik auf alle UAs in der Gruppe verteilt werden könnte. Zum Beispiel müssten Regeln, die die Zuweisung von Erscheinungsnummern für eingehende Anfragen steuern (z. B. niedrigste verfügbare Erscheinungsnummer), und Regeln für die Konfliktbehandlung (z. B. wenn zwei UAs die Verwendung derselben Erscheinungsnummer anfordern, Dialog-Identifikatoren hashen und mit dem niedrigsten Hash vergleichen, der gewinnt) definiert und implementiert werden.

Um REQ-9 am besten zu erfüllen, muss die Erscheinungsnummer für eine eingehende INVITE zusätzlich zur Übermittlung im Dialog-Paket NOTIFY in der INVITE enthalten sein. Andernfalls könnte eine UA in der Gruppe, wenn die NOTIFY verzögert oder verloren geht, eine eingehende INVITE empfangen, aber möglicherweise nicht wissen, welche Erscheinungsnummer während der Alarmierung dargestellt werden soll.

Diese Spezifikation definiert einen Erweiterungsparameter, der in Abschnitt 7 normativ definiert ist, für das Alert-Info-Header-Feld in RFC 3261, um die Erscheinungsnummer zu tragen:

Alert-Info: <urn:alert:service:normal>;appearance=1

Die folgende Liste beschreibt den Betrieb der gemeinsamen Erscheinungsfunktion.

1. Eine UA wird mit dem AOR einer gemeinsamen Erscheinungsgruppe konfiguriert. Sie registriert sich gegen den AOR und versucht dann ein Dialogzustands-Abonnement für den AOR. Wenn das Abonnement fehlschlägt, zu sich selbst zurückloopt oder einen Fehler zurückgibt, weiß sie, dass es keinen State Agent und daher keinen Appearance Agent gibt und diese Funktion nicht implementiert ist.

2. Wenn das Abonnement eine 200 OK erhält, weiß die UA, dass es einen State Agent gibt und dass die Funktion implementiert ist. Die UA folgt dann den Schritten in dieser Liste.

3. Informationen, die über den Dialogzustand anderer UAs in der Gruppe gelernt wurden, werden dem Benutzer dargestellt.

4. Eingehende Anrufe werden an alle UAs in der Gruppe gefork, und jede kann antworten. UAs erhalten die Erscheinungsnummer zur Verwendung beim Darstellen des eingehenden Anrufs in einem NOTIFY vom Appearance Agent und in der INVITE selbst. Die UA erhält auch eine Benachrichtigung, wenn der Anruf von einer anderen UA in der Gruppe beantwortet wird, damit diese Information dem Benutzer dargestellt werden kann.

5. Für ausgehende Anrufe hängt der Betrieb von der Implementierung ab. Wenn der Benutzer eine bestimmte Erscheinungsnummer für den Anruf besetzt, veröffentlicht die UA die Versuchszustands-Dialoginformationen mit der gewünschten Erscheinungsnummer und wartet auf eine 2xx-Antwort, bevor sie die INVITE sendet.

6. Für ausgehende Anrufe kann, wenn der Benutzer keine bestimmte Erscheinung besetzt oder sich nicht darum kümmert, die INVITE sofort gesendet werden, und die Erscheinungsnummer wird gelernt, während der Anruf von einer Benachrichtigung vom Appearance Agent fortschreitet.

7. Für ausgehende Anrufe, wenn der Benutzer keine Erscheinungsnummer zugewiesen haben möchte (z. B. während eines Konsultationsanrufs oder wenn eine UA "Dienstmedien" wie Musik in der Warteschleife [RFC7088] abruft), veröffentlicht die UA auch vor dem Senden der INVITE, schließt aber keine Erscheinungsnummer in die Veröffentlichung ein.

8. Eingerichtete Anrufe innerhalb der Gruppe können von einer anderen UA verbunden (überbrückt) oder übernommen (aufgenommen) werden. Informationen in den Dialog-Paket-Benachrichtigungen können verwendet werden, um Join- oder Replaces-Header-Felder zu konstruieren. Da für diese Arten von Operationen dieselbe Erscheinungsnummer verwendet wird, werden diese Informationen vor dem Senden der INVITE Join oder INVITE Replaces veröffentlicht.

9. Der Appearance Agent hat möglicherweise keinen direkten Zugriff auf den vollständigen Dialogzustand einiger oder aller UAs in der Gruppe. In diesem Fall wird der Appearance Agent den Dialogzustand einzelner UAs in der Gruppe abonnieren, um diese Informationen zu erhalten. In jedem Fall sendet der Appearance Agent normale Benachrichtigungen (über die von den UAs in Schritt 1 eingerichteten Abonnements) jedes Mal, wenn sich der aggregierte Dialogzustand des AOR ändert, einschließlich wenn Anrufe getätigt, beantwortet, in und aus der Warteschleife gelegt und aufgelegt werden.