7. Alert-Info Erscheinungsparameter-Definition

Diese Spezifikation erweitert [RFC3261], um einen 'appearance' Parameter zum Alert-Info Header-Feld hinzuzufügen und auch Proxies zu erlauben, das Alert-Info Header-Feld zu ändern oder zu löschen.

Die Änderungen an der ABNF [RFC5234] in RFC 3261 sind:

alert-param      =  LAQUOT absoluteURI RAQUOT *( SEMI
                      (generic-param / appearance-param) )
appearance-param = "appearance" EQUAL 1*DIGIT

Ein Proxy, der einen 'appearance' Alert-Info Parameter einfügt, folgt normalen Alert-Info Richtlinien. Um die Erscheinungsnummer für diesen Dialog anzuzeigen, fügt der Proxy das Alert-Info Header-Feld mit dem 'appearance' Parameter zum INVITE hinzu. Wenn bereits ein Alert-Info vorhanden ist, fügt der Proxy den 'appearance' Parameter zum Alert-Info Header-Feld hinzu. Wenn bereits ein Erscheinungsnummernparameter vorhanden ist (mit einem anderen AOR verknüpft oder fälschlicherweise), wird der Wert neu geschrieben und die neue Erscheinungsnummer hinzugefügt. Es DARF NICHT mehr als einen Erscheinungsparameter in einem Alert-Info Header-Feld geben.

Wenn kein spezieller Klingelton gewünscht wird, SOLLTE ein normaler Klingelton unter Verwendung von urn:alert:service:normal im Alert-Info gemäß [RFC7462] angezeigt werden. Die in einem Alert-Info Header-Feld vorhandene Erscheinungsnummer SOLLTE von der UA dem Benutzer gemäß den Richtlinien in Abschnitt 5.3 dargestellt werden. Wenn das INVITE an einen anderen AOR weitergeleitet wird, SOLLTE der Erscheinungsparameter im Alert-Info vor der Weiterleitung außerhalb der Gruppe entfernt werden.

Die Bestimmung, welcher Wert im Erscheinungsparameter verwendet werden soll, kann beim Proxy erfolgen, der die eingehende Anfrage an alle registrierten UAs verzweigt.

Es gibt verschiedene Möglichkeiten, wie der Proxy bestimmen kann, welchen Wert er zum Ausfüllen dieses Parameters verwenden sollte. Beispielsweise könnte der Proxy diese Informationen abrufen, indem er eine SUBSCRIBE-Anfrage mit Expires: 0 an den Appearance Agent für den AOR initiiert, um die Liste der verwendeten Leitungen abzurufen. Alternativ könnte er wie eine UA handeln, die Teil der gemeinsamen Erscheinungsgruppe ist, und den State-Agent wie jede andere UA SUBSCRIBE. Dies würde sicherstellen, dass die aktiven Dialoginformationen verfügbar sind, ohne bei Bedarf abfragen zu müssen. Er könnte die Liste der aktiven Anrufe für den Erscheinungs-AOR basierend darauf verfolgen, wie viele eindeutige INVITE-Anfragen er an den Erscheinungs-AOR verzweigt oder von diesem empfangen hat. Ein anderer Ansatz wäre, dass der Proxy zunächst das eingehende INVITE an den Appearance Agent sendet, der zur URI der gemeinsamen Erscheinungsgruppe umleitet und das entsprechende Alert-Info Header-Feld maskiert, damit der Proxy rekursiert und an die anderen UAs in der Gruppe verteilt.

Der Appearance Agent muss über alle eingehenden Anfragen an den AOR informiert sein, um die Erscheinungsnummer zu besetzen. Eine Möglichkeit, dies zu tun, besteht darin, dass sich der Appearance Agent gegen den AOR mit einem höheren q-Wert registriert. Dies führt dazu, dass das INVITE zuerst an den Appearance Agent gesendet und dann den UAs in der Gruppe angeboten wird.