5. Normative Beschreibung

Dieser Abschnitt beschreibt normativ die Erweiterungen für die Funktion gemeinsamer Erscheinungsbilder. Die folgenden Definitionen werden in diesem Dokument verwendet:

Appearance number (Erscheinungsnummer): Eine Erscheinungsnummer ist eine positive Ganzzahl, die einem oder mehreren Dialogen eines AOR zugeordnet ist. Erscheinungsnummern werden von einem Appearance Agent verwaltet und von UAs, die diese Spezifikation unterstützen, dem Benutzer angezeigt und gerendert.

Seizing (Beschlagnahme): Ein Erscheinungsbild kann vor dem Tätigen eines Anrufs durch Beschlagnahme des Erscheinungsbilds reserviert werden. Ein Erscheinungsbild kann beschlagnahmt werden, indem ein künstlicher Zustand von "trying" vor dem tatsächlichen Initiieren eines Dialogs kommuniziert wird.

Selecting (Auswahl) (oder Not-Seizing): Ein Erscheinungsbild wird lediglich ausgewählt (d.h. nicht beschlagnahmt), wenn es keine solche Kommunikation eines künstlichen Zustands von "trying" vor dem Initiieren eines Dialogs gibt.

5.1. Elemente

Ein vollständiges System zur Implementierung dieser Funktion besteht aus:

1. UAs, die Publikationen, Abonnements und Benachrichtigungen für das SIP-Dialog-Ereignispaket und die Erweiterungen und das Verhalten des gemeinsamen Erscheinungsbild-Dialogpakets unterstützen.

2. Einem Appearance Agent, bestehend aus einem State Agent für das Dialog-Ereignispaket, der einen Event State Compositor (ESC) und die Erweiterungen und das Verhalten des gemeinsamen Erscheinungsbild-Dialogpakets implementiert.

3. Einem Forking-Proxyserver, der mit dem State Agent kommunizieren kann.

4. Einem Registrar, der das Registrierungs-Ereignispaket unterstützt.

Das Verhalten dieser Elemente wird normativ in den folgenden Abschnitten nach den Definitionen der Dialogpaket-Erweiterungen beschrieben.

5.2. Erweiterungen des Dialog-Pakets für gemeinsame Erscheinungen

Diese Spezifikation definiert vier neue Elemente als Erweiterungen des SIP-Dialogereignispakets [RFC4235]. Das Schema ist in Abschnitt 6 definiert. Die Elemente sind <appearance>, <exclusive>, <joined-dialog> und <replaced-dialog>, die Unterelemente des <dialog>-Elements sind.

5.2.1. Das Element <appearance>

Das Element <appearance>, ein Kind des Elements <dialog>, wird verwendet, um die Erscheinungsnummer des durch das übergeordnete <dialog>-Element beschriebenen Dialogs zu übermitteln. Wenn es von einem UA in einem PUBLISH mit dem übergeordneten <dialog> und dem state-Attribut "trying" an den Appearance Agent gesendet wird, fordert der UA die Zuweisung der angegebenen Erscheinungsnummer zum aktuellen oder zukünftigen Dialog mit den angegebenen Dialogbezeichnern an. Wenn ein <appearance>-Element vom Appearance Agent in einer NOTIFY gesendet wird, zeigt es an, dass die Erscheinungsnummer dem angegebenen Dialog zugewiesen wurde.

Beachten Sie, dass ein <dialog-info>-Element die enthaltenen Dialoge aus Sicht des UA (benannt durch das Attribut "entity") beschreibt, unabhängig davon, ob die enthaltende Anforderung vom UA oder vom Appearance Agent gesendet wird. Insbesondere wenn der UA eine Anforderung innerhalb des beschriebenen Dialogs gesendet hat, würde der URI des To-Header-Felds mit dem Wert <remote> <identity> übereinstimmen und der to-tag-Parameter mit dem remote-tag-Attribut. In ähnlicher Weise würde der URI des From-Header-Felds mit dem Wert <local> <identity> übereinstimmen und der from-tag-Parameter mit dem local-tag-Attribut.

5.2.2. Das Element <exclusive>

Das Element <exclusive>, ein Kind des Elements <dialog>, ist ein Boolescher Wert, der, wenn er true ist, angibt, dass der UA nicht bereit ist, eine INVITE mit einem Join- oder Replaces-Header-Feld zu akzeptieren, die auf den durch das <dialog>-Element beschriebenen Dialog gerichtet ist, das das übergeordnete Element des <exclusive>-Elements ist. Beispielsweise erlauben einige Systeme mit gemeinsamen Erscheinungen eine Anrufübernahme nur, wenn der Anruf gehalten wird. In diesem Fall sollte das <exclusive>-Element auf "false" gesetzt werden, wenn der Anruf gehalten wird, und auf "true", wenn der Anruf nicht gehalten wird, anstatt den "exclusive"-Wert durch den Haltezustand implizieren zu lassen.

Es ist wichtig zu beachten, dass dieses Element nur ein Hinweis ist. Um zu verhindern, dass ein anderer UA einen Anruf übernimmt oder ihm beitritt, kann ein UA zusätzlich zum Setzen des <exclusive>-Tags keine vollständigen Dialoginformationen an den Appearance Agent melden. Das Fehlen der vollständigen Dialoginformationen (Call-ID, remote-tag und local-tag) verhindert, dass ein anderer UA ein Join- oder Replaces-Header-Feld konstruiert. Obwohl ein UA <exclusive> auf "true" setzen kann, muss der UA dennoch bereit sein, eine INVITE Join bezüglich dieses Dialogs abzulehnen. Wenn diese Dialogbezeichner bereits mit dem Appearance Agent geteilt wurden, könnte der UA eine INVITE Replaces senden, um sie zu ändern, und dann die neuen nicht an den Appearance Agent melden.

Wenn der Proxy weiß, welche Dialoge als exklusiv markiert sind, KANN der Proxy diese Exklusivität durchsetzen, indem er INVITE Join- und INVITE Replaces-Anforderungen, die diese Dialogbezeichner enthalten, mit einer 403 (Forbidden)-Antwort ablehnt.

Beachten Sie, dass Exklusivität nichts mit der Auswahl oder Belegung von Erscheinungsnummern zu tun hat -- sie betrifft stattdessen Anrufsteuerungsoperationen, die an einem Dialog ausgeführt werden können.

Wenn das Element <exclusive> nicht vorhanden ist, wird angenommen, dass es false ist.

5.2.3. Das Element <joined-dialog>

Das Element <joined-dialog>, ein Kind des Elements <dialog>, wird verwendet, um die Dialogbezeichner aller anderen Dialoge zu übermitteln, die mit dem Dialog verbunden (gemischt oder überbrückt) sind. Nur der UA, der der gemeinsame Endpunkt der gemischten Dialoge ist (und somit den Mischvorgang steuert), sollte dieses Element in Veröffentlichungen an den Appearance Agent aufnehmen. Beachten Sie, dass dieses Element auch dann verwendet werden sollte, wenn das Join-Header-Feld nicht zum Verbinden der Dialoge verwendet wurde. Beispielsweise könnten zwei separate Dialoge auf einem UA ohne SIP-Anrufsteuerungsoperationen verbunden werden. Verbundene Dialoge teilen dieselbe Erscheinungsnummer.

Wenn das <joined-dialog>-Element nicht vorhanden ist, wird angenommen, dass der Dialog nicht mit einem anderen Dialog verbunden ist oder verbunden wird.

5.2.4. Das Element <replaced-dialog>

Das Element <replaced-dialog>, ein Kind des Elements <dialog>, wird verwendet, um die Dialogbezeichner aller anderen Dialoge zu übermitteln, die durch diesen Dialog ersetzt werden oder wurden. Beispielsweise würde ein UA in der Gruppe, der einen Anruf auf einem anderen UA durch Senden einer INVITE mit Replaces übernimmt, dieses Element für den ersetzenden Dialog aufnehmen. Ersetzte Dialoge teilen dieselbe Erscheinungsnummer.

Wenn das <replaced-dialog>-Element nicht vorhanden ist, wird angenommen, dass der Dialog keinen anderen Dialog ersetzt hat und keinen anderen ersetzen wird.

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.

5.3.1. Erscheinungsnummern und Anrufkontext

Es gibt Fälle, in denen zwei separate Dialoge bei einer UA nicht gemischt sind, aber denselben "Kontext" teilen. Das heißt, sie beziehen sich aufeinander und sollten nicht wie zwei andere Dialoge innerhalb der Gruppe behandelt werden. Ein Beispiel hierfür ist ein "Konsultationsanruf", bei dem ein Benutzer einen bestehenden Dialog in die Warteschleife legt, dann einen anderen Benutzer anruft, bevor er zum ursprünglichen Dialog zurückkehrt. Ein anderer Fall, der unten beschrieben wird, tritt während Übertragungsoperationen auf, bei denen eine UA für einen vorübergehenden Zeitraum an Dialogen mit zwei anderen UAs beteiligt ist, aber die Dialoge verwandt sind und nicht als unabhängige Dialoge behandelt werden sollten. Diese Fälle werden am besten dadurch behandelt, dass einem neu erstellten Dialog keine Erscheinungsnummer zugewiesen wird, wenn er einen Kontext mit einem bestehenden Dialog teilt. Wenn der vorbestehende Dialog jedoch beendet wird, sollte seine Erscheinungsnummer dem neu erstellten Dialog neu zugewiesen werden.

Eine UA, die einen Anruf tätigen möchte, aber keine zugewiesene Erscheinungsnummer hat, sendet ein PUBLISH, bevor sie das INVITE sendet. Das PUBLISH hat kein 'appearance' Element vorhanden, hat aber den 'shared' Event-Header-Feldparameter vorhanden. Wenn die Appearance Agent-Richtlinie Anrufe ohne zugewiesene Erscheinungsnummer nicht zulässt, wird vom Appearance Agent eine 400 (Bad Request) Antwort gesendet, und die UA wird entweder erneut veröffentlichen, wobei sie eine Erscheinungsnummer auswählt/besetzt, oder das INVITE ohne Veröffentlichung senden, in welchem Fall der Appearance Agent eine zuweist.

Beachten Sie, dass wenn ein Appearance Agent Anrufe ohne Erscheinungsnummer ablehnt, bestimmte Operationen wie Konsultationsanrufe, Übertragung und Wartemusik negativ beeinflusst werden können.

5.3.2. Erscheinungsnummern und Anrufsteuerung

Wenn ein INVITE generiert wird, um zu versuchen, einen Anruf zu überbrücken oder zu übernehmen (d. h. Join oder Replaces mit einem Dialogidentifikator eines anderen Dialogs in der gemeinsamen Erscheinungsgruppe enthält), MUSS die UA zuerst ein PUBLISH an den Appearance Agent senden. Dieses PUBLISH wird enthalten:

1. Die Erscheinungsnummer des verbundenen oder ersetzten Anrufs im <appearance> Element

2. Die Dialoginformationen aus dem Join-Header-Feld im <joined-dialog> Element, wenn der Dialog verbunden wird

3. Die Dialoginformationen aus dem Replaces-Header-Feld im <replaced-dialog> Element, wenn der Dialog ersetzt wird

Beachten Sie, dass diese Informationen dem Appearance Agent zur Verfügung gestellt werden, damit er ein angemessenes Erscheinungszuweisungsverhalten bereitstellen kann. Wenn das INVITE Join oder Replaces ohne vorherige Veröffentlichung gesendet wurde, könnte der Appearance Agent diesem INVITE eine neue Erscheinungsnummer zuweisen, was ein Fehler wäre. Bei Join hat die Veröffentlichung das <joined-dialog> Element, um zu verhindern, dass der Appearance Agent aufgrund der Wiederverwendung einer Erscheinungsnummer eine 400 (Bad Request) Antwort generiert. Für Replaces besteht der Zweck des <replaced-dialog> darin, eine Wettlaufbedingung zu verhindern, bei der der BYE dazu führen könnte, dass die Erscheinungsnummer freigegeben wird, wenn sie beim ersetzenden Dialog bleiben sollte.

5.3.3. Erscheinungsnummern und Weiterleitung

Während einer Übertragungsoperation ist es wichtig, dass sich die Erscheinungsnummer während der Operation nicht ändert. Betrachten Sie das Beispiel von Alice, einem Mitglied einer gemeinsamen Erscheinungsgruppe, die mit Carol spricht, die außerhalb der gemeinsamen Erscheinungsgruppe ist. Carol überträgt Alice an David, der ebenfalls außerhalb der gemeinsamen Erscheinungsgruppe ist. Wenn Alice beispielsweise Erscheinung 3 für die Sitzung mit Carol verwendet, sollte die resultierende Sitzung mit David ebenfalls Erscheinungsnummer 3 verwenden. Andernfalls kann eine Änderung der Erscheinungsnummer einen "Sprung" auf der Benutzeroberfläche verursachen und den Benutzer verwirren. Es gibt zwei mögliche Szenarien unter Verwendung der Terminologie von RFC 5589: Alice ist der Übertragungsempfänger bei jeder Art von Übertragung (empfängt das REFER) oder das Übertragungsziel bei einer betreuten Übertragung (empfängt das INVITE mit Replaces).

Wenn Alice der Übertragungsempfänger ist, wird das durch REFER ausgelöste INVITE als Konsultationsanruf behandelt. Alice SOLLTE veröffentlichen und anfordern, dass der Appearance Agent diesem INVITE keine Erscheinungsnummer zuweist. Wenn die Übertragung abgeschlossen ist, SOLLTE Alice erneut veröffentlichen, um die Erscheinungsnummer vom Dialog mit Carol zum Dialog mit David zu verschieben. Wenn ein PUBLISH gesendet wird, um die Erscheinungsnummer zu verschieben, MUSS die Veröffentlichung vor dem Senden des BYE an Carol gesendet werden, um eine Wettlaufbedingung zu vermeiden, bei der der Appearance Agent die Erscheinungsnummer nach dem Sehen des BYE neu zuweist.

Wenn Alice das Ziel ist, enthält das eingehende INVITE ein Replaces-Header-Feld. Infolgedessen wird der Appearance Agent die Erscheinungsnummer des Dialogs mit Carol wiederverwendet haben, und diese Erscheinungsnummer wird weiterhin verwendet, nachdem der Dialog mit Carol beendet wurde.

5.4. Erscheinungsagent

Ein in dieser Spezifikation definierter Appearance Agent MUSS einen Dialogpaket-Zustandsagenten für die bei der AOR registrierten UAs implementieren. Der Appearance Agent MUSS die in Abschnitt 5.2 definierten Erweiterungen des Erscheinungs-Dialogpakets unterstützen und den 'shared'-Event-Header-Feldparameter verwenden. Der Appearance Agent MUSS Veröffentlichungen und Abonnements für dieses Ereignispaket unterstützen.

Der Appearance Agent MUSS über eine Möglichkeit verfügen, den Zustand aller mit der AOR verbundenen Dialoge zu ermitteln. Wenn diese Informationen nicht von einem anrufzustandsbehafteten Proxy oder einem Back-to-Back User Agent (B2BUA) verfügbar sind, kann der Appearance Agent das Registrierungsereignispaket [RFC3680] verwenden, um UAs zu ermitteln, die mit der AOR verbunden sind, und deren Dialogereigniszustand zu abonnieren. Ein Appearance Agent kann auch den Dialogereigniszustand eines UA abonnieren, um den Zustand zu rekonstruieren. Infolgedessen MUSS der Registrar das Registrierungsereignispaket unterstützen.

Dialogpaketbenachrichtigungen werden von RFC 4235 empfohlen, "nur Informationen über die Dialoge zu enthalten, deren Zustands- oder Teilnahmeinformationen sich geändert haben". Diese Spezifikation erweitert RFC 4235 wie folgt. Der Appearance Agent SOLLTE Dialogereigniszustandsbenachrichtigungen senden, wann immer die folgenden Ereignisse bei UAs in der AOR-Gruppe auftreten:

1. Ein Anruf wird empfangen, getätigt, beantwortet oder beendet.

2. Ein Anruf wird in die Warteschleife gestellt oder aus der Warteschleife genommen.

3. Ein Anruf wird verbunden oder ersetzt.

4. Eine Erscheinungsnummer wird reserviert oder freigegeben.

Der Appearance Agent MUSS für alle eingehenden Anrufe eine Erscheinungsnummer zuweisen und sofortige Benachrichtigungen an die UAs senden, die die gemeinsame Gruppen-AOR abonniert haben. Eine neue Erscheinungsnummer wird zugewiesen, außer bei einer eingehenden INVITE mit einem Join- oder Replaces-Header-Feld. In diesem Fall sollte die Erscheinungsnummer mit der Erscheinungsnummer des Dialogs übereinstimmen, dem beigetreten wird oder der ersetzt wird. Wenn die INVITE Replaces oder Join von außerhalb der gemeinsame Erscheinungsgruppe kommt, nimmt der Appearance Agent ein <joined-dialog>- oder <replaced-dialog>-Element in die NOTIFY auf, das die Dialoginformationen aus dem Replaces- oder Joined-Header-Feld enthält.

Der Appearance Agent MUSS mit dem Forking-Proxy kommunizieren können, um eingehende Anrufe zu erfahren und außerdem die Erscheinungsnummer an den Proxy weiterzugeben oder sicherzustellen, dass das Alert-Info-Header-Feld mit der entsprechenden Erscheinungsnummer in die INVITE aufgenommen wird.

Beachten Sie, dass UAs eingehende INVITE-Nachrichten ohne zugewiesene Erscheinungsnummer verarbeiten können müssen. Dies könnte durch einen Ausfall des Appearance Agent oder eine andere Fehlerbedingung verursacht werden. Obwohl die ordnungsgemäße Darstellung der INVITE möglicherweise nicht möglich ist, ist dies besser, als die INVITE zu ignorieren oder fehlschlagen zu lassen.

Ein Appearance Agent SOLLTE einem ausgehenden Dialog eine Erscheinungsnummer zuweisen, wenn kein PUBLISH empfangen wurde, das eine bestimmte Erscheinungsnummer auswählt/belegt.

Beachten Sie, dass der Appearance Agent, wenn die gemeinsame Erscheinungsgruppe UAs enthält, die sich der Erscheinungen nicht bewusst sind und Anrufe tätigen, dennoch Erscheinungsnummern für die von diesen UAs gesendeten INVITE-Nachrichten zuweist.

Ein Appearance Agent, der ein PUBLISH mit einer Erscheinungsnummer empfängt, prüft, ob die Veröffentlichung gültig ist. Eine Erscheinungsnummer kann nur einem Dialog zugewiesen werden, es sei denn, es gibt ein <joined-dialog>- oder <replaced-dialog>-Element, das angibt, dass der Dialog ersetzt oder verbunden wird/wurde. Eine 400 (Bad Request)-Antwort wird zurückgegeben, wenn die gewählte Erscheinungsnummer ungültig ist, und eine sofortige NOTIFY SOLLTE an den UA gesendet werden, die den vollständigen Dialogereigniszustand enthält.

Ein Appearance Agent, der ein PUBLISH ohne Erscheinungsnummer, aber mit vorhandenem 'shared'-Event-Header-Feldparameter empfängt, interpretiert dies als Anforderung des UA, keine Erscheinungsnummer zuzuweisen. Wenn die Richtlinie des Appearance Agent dies nicht zulässt, wird eine 400 (Bad Request)-Antwort zurückgegeben. Wenn die Richtlinie dies zulässt, wird eine 200 (OK)-Antwort zurückgegeben und keine Erscheinungsnummer zugewiesen. Ein Appearance Agent muss diese Dialoginformationen nicht mit anderen UAs der Gruppe teilen (d. h. eine NOTIFY senden), da die Informationen von den anderen UAs nicht dargestellt werden.

Der Appearance Agent weist einem Dialog eine Erscheinungsnummer zu, und zwar von dem Zeitpunkt an, an dem die Erscheinung über ein PUBLISH angefordert wird oder die INVITE empfangen wird, bis zu dem Zeitpunkt, an dem der letzte mit der Erscheinung verbundene Dialog beendet wird, einschließlich aller Dialoge, die verbunden oder ersetzt werden. Während des frühen Dialogzustands steuert der Appearance Agent die Rate der Dialogzustandsveröffentlichung mithilfe des Expires-Header-Felds in 200 (OK)-Antworten auf PUBLISH-Anforderungen. Ein Intervall von 3 Minuten wird EMPFOHLEN. Nachdem der mit der Veröffentlichung verbundene Dialog bestätigt wurde, hat der Ablauf des Veröffentlichungszustands keine Auswirkung auf die Erscheinungszuweisung. Wenn die Veröffentlichung keine Dialogzustandsinformationen enthält, MUSS der Appearance Agent die Erscheinungsnummer für den UA reservieren, kann die Erscheinung jedoch keinem bestimmten Dialog des UA zuweisen. Wenn der Veröffentlichungszustand mit Dialoginformationen aktualisiert wird, kann die Erscheinungsnummer dann dem bestimmten Dialog zugewiesen werden. Ein UA, dem mithilfe eines PUBLISH eine Erscheinungsnummer zugewiesen wurde, KANN die Erscheinungsnummer freigeben, indem er den Ereigniszustand mit einem PUBLISH entfernt, wie in [RFC3903] beschrieben.

Wenn eine INVITE von einem Mitglied der Gruppe an die gemeinsame AOR gesendet wird (d. h. sie rufen ihre eigene AOR an), MUSS der Appearance Agent zwei Erscheinungsnummern zuweisen. Die erste Erscheinungsnummer ist diejenige, die für die ausgehende INVITE ausgewählt oder zugewiesen wurde. Die zweite Erscheinungsnummer ist eine weitere, die der Appearance Agent für die INVITE zuweist, wenn sie zurück an die Mitglieder der Gruppe geforkt wird.

Dies dient dazu, ein gemeinsames Verhalten in Alt-Systemen zu bewahren.

Wenn eine INVITE von einem Mitglied der Gruppe unter Verwendung der gemeinsamen AOR gesendet oder an die gemeinsame AOR gesendet wird und keine Erscheinungsnummer verfügbar ist, KANN der Proxy die INVITE mit dem Antwortcode 403 (Forbidden) ablehnen.

Erscheinungsnummern werden nur für Dialoge verwendet, an denen ein oder mehrere der Gruppen-AOR zugeordnete UAs beteiligt sind. Wenn eine eingehende INVITE an die Gruppen-AOR an eine andere AOR weitergeleitet wird, wird die Erscheinungsnummer sofort freigegeben und kann einem anderen Dialog zugewiesen werden.