Skip to main content

7. Alert-Info Appearance Parameter Definition

This specification extends [RFC3261] to add an 'appearance' parameter to the Alert-Info header field and also to allow proxies to modify or delete the Alert-Info header field.

The changes to the ABNF [RFC5234] in RFC 3261 are:

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

A proxy inserting an 'appearance' Alert-Info parameter follows normal Alert-Info policies. To indicate the appearance number for this dialog, the proxy adds the Alert-Info header field with the 'appearance' parameter to the INVITE. If an Alert-Info is already present, the proxy adds the 'appearance' parameter to the Alert-Info header field. If an appearance number parameter is already present (associated with another AOR or by mistake), the value is rewritten adding the new appearance number. There MUST NOT be more than one appearance parameter in an Alert-Info header field.

If no special ringtone is desired, a normal ringtone SHOULD be indicated using the urn:alert:service:normal in the Alert-Info, as per [RFC7462]. The appearance number present in an Alert-Info header field SHOULD be rendered by the UA to the user, following the guidelines in Section 5.3. If the INVITE is forwarded to another AOR, the appearance parameter in the Alert-Info SHOULD be removed before forwarding outside the group.

The determination as to what value to use in the appearance parameter can be done at the proxy that forks the incoming request to all the registered UAs.

There is a variety of ways the proxy can determine what value it should use to populate this parameter. For example, the proxy could fetch this information by initiating a SUBSCRIBE request with Expires: 0 to the Appearance Agent for the AOR to fetch the list of lines that are in use. Alternatively, it could act like a UA that is a part of the shared appearance group and SUBSCRIBE to the State-Agent like any other UA. This would ensure that the active dialog information is available without having to poll on a need basis. It could keep track of the list of active calls for the appearance AOR based on how many unique INVITE requests it has forked to or received from the appearance AOR. Another approach would be for the Proxy to first send the incoming INVITE to the Appearance Agent, which would redirect to the shared appearance group URI and escape the proper Alert-Info header field for the Proxy to recurse and distribute to the other UAs in the group.

The Appearance Agent needs to know about all incoming requests to the AOR in order to seize the appearance number. One way in which this could be done is for the Appearance Agent to register against the AOR with a higher q value. This will result in the INVITE being sent to the Appearance Agent first, then being offered to the UAs in the group.