5.3. Benutzeragenten mit gemeinsamer Erscheinung

UAs, die die gemeinsame Erscheinungsfunktion unterstützen, verwenden das Dialogstatuspaket [RFC4235] mit den gemeinsamen Erscheinungserweiterungen und dem in Abschnitt 13 definierten 'shared' Event-Header-Feldparameter.

UAs verwenden die Dialogpaketerweiterungen in Abschnitt 5.2 zusammen mit SUBSCRIBE [RFC6665], NOTIFY [RFC6665] und PUBLISH [RFC3903]. SUBSCRIBE-, NOTIFY- und PUBLISH-Anfragen für das Dialogereignispaket enthalten den 'shared' Event-Header-Feldparameter, wie von dieser Spezifikation gefordert.

Das Vorhandensein des 'shared' Event-Header-Feldparameters teilt dem Appearance Agent mit, dass die UA diese Spezifikation unterstützt.

Bei der Initialisierung MUSS die UA das Dialogereignispaket des AOR abonnieren und das Abonnement gemäß dem SIP Events Framework [RFC6665] aktualisieren. Wenn die SUBSCRIBE-Anfrage fehlschlägt, ist möglicherweise kein Appearance Agent vorhanden und diese Funktion ist für diesen AOR nicht aktiv. Die UA KANN das Abonnement regelmäßig wiederholen, um festzustellen, ob sich die Bedingungen geändert haben, in Intervallen von nicht weniger als vier Stunden.

Vier Stunden wurden gewählt, um den Abonnementtest auf sechs pro Tag pro UA zu begrenzen. Eine Erhöhung dieses Intervalls würde diesen Fehlerverkehr reduzieren, würde aber länger dauern, bis ein neu aktivierter Appearance Agent entdeckt wird.

UAs können auch das Vorhandensein des 'shared' Event-Header-Feldparameters in NOTIFYs verwenden, um das Vorhandensein eines Appearance Agents für den AOR zu entdecken.

UAs, die die gemeinsame Erscheinungsfunktion, Anrufübernahme, Verbindung und Überbrückung implementieren, MÜSSEN das Senden eines INVITE mit Replaces [RFC3891] oder Join [RFC3911] unterstützen. Der User Agent Client (UAC) muss die to-tag- und from-tag-Informationen im Replaces- oder Join-Header einschließen, damit der korrekte Dialog vom User Agent Server (UAS) gemäß den Regeln in RFCs 3891 und 3911 abgeglichen wird.

Alle UAs, die die gemeinsame Erscheinungsfunktion implementieren und INVITE unterstützen, MÜSSEN den Empfang eines INVITE mit einem Replaces [RFC3891] oder einem Join [RFC3911] Header-Feld unterstützen.

Beim Veröffentlichen oder Benachrichtigen von Dialogpaketinformationen schließt eine UA die größte zum Zeitpunkt der Veröffentlichung verfügbare Dialogidentifikationsmenge ein, mit der Ausnahme, dass eine UA Informationen weglassen kann, wenn sie verhindern möchte, dass andere UAs einem Anruf beitreten oder ihn übernehmen. Die Dialogidentifikation umfasst lokale und entfernte Ziel-URIs, call-id, to-tag und from-tag. Während diese Dialogidentifikationsinformationen in [RFC4235] optional sind, sind sie in der gemeinsamen Erscheinungsfunktion wesentlich und ermöglichen Anrufsteuerungsoperationen. Verwenden Sie beim Halten von Anrufen das "+sip.rendering=no" Feature-Tag, um dies in Dialogpaketbenachrichtigungen anzuzeigen. Die Verwendung der vollständigen SDP-Sitzungsbeschreibung zwingt den Endpunkt stattdessen, viel zusätzliche Analyse durchzuführen, was den Code unnötig kompliziert und zu Fehlern einlädt.

Die genaue Darstellung des Leerlauf/Aktiv/Alarmierungs/Haltezustands anderer UAs in der Gruppe ist ein wichtiger Teil der gemeinsamen Erscheinungsfunktion.

Eine UA, die keine bestimmte Erscheinungsnummer besetzen muss (oder der es egal ist), würde einfach ein INVITE wie gewohnt senden, um einen ausgehenden Anruf zu tätigen.

Wenn der Anruf ein Notfallanruf ist, DARF eine UA niemals auf eine bestätigte Besetzung warten, bevor sie ein INVITE sendet. Stattdessen MUSS der Notfallanruf fortgesetzt werden, ohne auf die PUBLISH-Transaktion zu warten.

Wenn eine UA eine bestimmte Erscheinungsnummer benötigt, MUSS die UA eine Dialogpaket-PUBLISH-Anfrage senden und auf eine 2xx-Antwort warten, bevor sie das INVITE sendet. Dies ist in den folgenden Situationen erforderlich:

1. Wenn der Benutzer eine bestimmte Erscheinungsnummer für einen ausgehenden Anruf besetzt (z. B. die Erscheinung besetzen und "abheben", wenn die Benutzeroberfläche der UA diese Metapher verwendet).

2. Wenn der Benutzer angefordert hat, dass eine Erscheinungsnummer nicht für einen ausgehenden Anruf verwendet wird (d. h. während eines Konsultationsanrufs, eines "Servicemedien"-Anrufs wie für Wartemusik [RFC7088] oder für einen Anruf, der nicht als Teil der gemeinsamen Erscheinungsgruppe betrachtet wird).

3. Wenn der Benutzer ausgewählt hat, einem vorhandenen Anruf beizutreten (oder zu überbrücken).

4. Wenn der Benutzer ausgewählt hat, einen vorhandenen Anruf zu ersetzen (oder zu übernehmen).

Beachten Sie, dass wenn eine UA eine Erscheinung vor der Einrichtung eines Dialogs besetzt (Nummern 1 und 2 in der obigen Liste), nicht alle Dialoginformationen verfügbar sein werden. Insbesondere wenn eine UA einen Versuch veröffentlicht, eine Erscheinung zu besetzen, bevor sie die Ziel-URI kennt, können minimale oder keine Dialoginformationen verfügbar sein. In einigen Fällen ist beispielsweise nur die lokale Ziel-URI für den Anruf bekannt: keine Dialoginformationen. Wenn das From-Tag und die Call-ID im anfänglichen PUBLISH nicht vorhanden waren, MUSS ein neues PUBLISH gesendet werden, sobald diese Informationen verfügbar sind.

Die erste Veröffentlichung wird dazu führen, dass der Appearance Agent die Erscheinungsnummer für diese UA reserviert. Wenn die Veröffentlichung keine Dialogidentifikatoren (z. B. Call-ID oder local-tag) hat, kann der Appearance Agent die Erscheinungsnummer einem bestimmten Dialog der UA nicht zuweisen, bis die zweite Veröffentlichung erfolgt, die einige Dialogidentifikatoren enthalten wird.

Dieser Veröffentlichungszustand wird wie in [RFC3903] beschrieben während des frühen Dialogzustands aktualisiert, oder der Appearance Agent kann die Erscheinungsnummer neu zuweisen. Sobald der Dialog in den bestätigten Zustand übergegangen ist, sind keine Veröffentlichungsaktualisierungen mehr erforderlich.

Diese Spezifikation geht davon aus, dass der Appearance Agent neben der UA-Veröffentlichung andere Mittel hat, um über den Zustand von UA-Dialogen zu erfahren. In dieser Spezifikation wird PUBLISH verwendet, um gewünschte und beabsichtigte Erscheinungsnummernoperationen anzuzeigen. Sobald ein Dialog von früh zu bestätigt übergeht, ist diese Rolle vorbei; daher sind keine Veröffentlichungsaktualisierungen erforderlich.

Erscheinungsnummern sind eine Kurzbezeichnung für aktive und ausstehende Dialoge, die sich auf einen AOR beziehen. Viele der mit dieser Erweiterung erstellten Funktionen und Dienste hängen von der korrekten Darstellung dieser Informationen für den menschlichen Benutzer ab. Darüber hinaus bedeutet die Gruppennatur der Funktion, dass die Darstellung zwischen verschiedenen Anbietern und verschiedenen Modellen ähnlich sein muss. Andernfalls wird der Wert und die Nützlichkeit dieser Protokollerweiterungen erheblich reduziert. In einer korrekt entworfenen Benutzeroberfläche für diese Funktion wird die Erscheinungsnummer für jeden aktiven und ausstehenden Dialog explizit (d. h. nach Erscheinungsnummer) oder implizit (unter Verwendung einer Benutzeroberflächenmetapher, die die Nummerierung und Reihenfolge für den Benutzer klar macht) für den Benutzer dargestellt. Die Identität des entfernten Endes jedes Dialogs (z. B. die Identität der entfernten Partei) ist kein nützlicher Ersatz für die Erscheinungsnummer. Der Zustand jeder Erscheinung muss ebenfalls dargestellt werden (Leerlauf, Aktiv, Besetzt, Verbunden usw.). UAs können erkennen, dass eine Reihe von Dialogen zusammen verbunden (überbrückt oder gemischt) sind, durch das Vorhandensein eines oder mehrerer <joined-dialog> Elemente, die andere SIP-Dialogidentifikatoren enthalten. Erscheinungsnummern von Dialogen können durch Dialogpaketbenachrichtigungen mit dem <appearance> Element vom Appearance Agent oder vom 'appearance' Alert-Info-Parameter in einem eingehenden INVITE gelernt werden. Sollten sie in Konflikt geraten, hat die Dialogpaketbenachrichtigung Vorrang.

Ein Benutzer kann eine Erscheinungsnummer auswählen, aber dann das Tätigen eines Anrufs abbrechen (wieder auflegen). In diesem Fall gibt die UA die Erscheinungsnummer frei, indem sie den Ereigniszustand mit einem PUBLISH wie in [RFC3903] beschrieben entfernt. Wenn dies nicht geschieht, sind unnötige Operationen durch den Appearance Agent erforderlich und belegen Erscheinungsnummern, die sonst von anderen UAs in der gemeinsamen Erscheinungsgruppe verwendet werden könnten.

Eine UA SOLLTE sich nur dann gegen den AOR registrieren, wenn es wahrscheinlich ist, dass die UA eingehende Anrufe beantwortet. Wenn die UA hauptsächlich den Status der gemeinsamen Erscheinungsgruppenanrufe überwacht und Anrufe übernimmt oder verbindet, SOLLTE die UA nur den AOR abonnieren und sich nicht gegen den AOR registrieren. Wenn eine überwachende UA sich registriert, anstatt nur zu abonnieren, erzeugt sie große Mengen unnötigen Netzwerkverkehrs.

Alle abonnierten UAs erhalten Dialogpaket-NOTIFYs des Versuchszustands für eingehende INVITEs.

Eine UA DARF KEINEN 'appearance' Parameter in ein Alert-Info-Header-Feld in einem INVITE oder einer anderen Anfrage einfügen.

Der Appearance Agent ist allein dafür verantwortlich, dies zu tun.