Guidelines for Implementing the Dialog Event Package in User Agents

SIP implements telephony and similar applications over the Internet. SIP largely conforms to the "end-to-end princple", putting the major responsibility for "call-control features" in the user agents (telephones) themselves, in constrast to traditional telephony, where the intelligence is concentrated in a small number of centralized switches. In order for a user agent to interact with dialogs (calls) that are present on other user agents, those user agents must publish the state of the dialogs in which they are participating in a dialog event package. A user agent can retrieve another user agent's dialog event package to obtain the identifiers of the second user agent's dialogs, and using those identifiers, it can manipulate those dialogs. Unfortnately, the dialog event package was specified before the breadth of its importance was fully understood, so its specification is relatively loose. Loose enough that many implementations within the standard are not usable for end-point call control (EPCC). It is the purpose of this memo to provide a specification of the dialog event package that is tight enough to ensure that a user agent can fully participate in current and future EPCC operations.

This section contains the guidelines for implementing high-quality dialog event packages, and a brief discussion of the motiviation for each guideline.

UAs accept requests bearing one of a set of request-URIs. Since the UA does not control which "host parts" of URIs can route to it; Guideline 1: A UA should not be sensitive to the host part of the request-URI in processing a request, as long as the host part resolves to specify the UA. Since a subscriber to the dialog event package may know only an AOR (address of record) to identify the UA with which it desires to communicate, the UA may have to route its SUBSCRIBE through a proxy via the AOR. The proxy will send the SUBSCRIBE to the registered contact URIs for that AOR. Guideline 2: A UA should accept SUBSCRIBEs to all URIs that it uses as contacts for AORs. A single UA may have contacts for multiple AORs, some of which may have contacts at other UAs. So dialog events "for an AOR" should only contain information about dialogs that were somehow addressed to that AOR. Guideline 3: A SUBSCRIBE to a URI that the UA uses as a contact for an AOR should obtain dialog events that describe only INVITEs to that URI (and URIs that the UA treats as equivalent).

Attendant consoles and other status reporting devices sometimes want information about the status of a UA, rather than about all dialogs that were addressed to a particular AOR. Guideline 4: A UA should accept SUBSCRIBEs to URIs with a null "user". These subscriptions should report dialog events that describe all dialogs at the UA.

In order to implement EPCC, the dialog event package needs to contain enough information to allow the subscriber to construct requests (REFER, INVITE with Replaces, etc) that can operate on the dialog. Guideline 5: The dialog event package should include the call-id, local-tag, remote-tag, and direction attributes of the dialog element. In order to allow a variety of EPCC functions, the data in the dialog event package needs to comprehensively describe the dialog's endpoints in a standard way. Guideline 6: The dialog event package should use the following sources for the following elements: the "From" header of the INVITE the "Contact" header of the latest INVITE the "To" header of the INVITE, or the "From" header that would be used when initiating a call from the "user" specified in the SUBSCRIBE the "Contact" header of the latest 2xx response to an INVITE Note that both Contact headers can be updated by re-INVITE and UPDATE requests during the dialog: Guideline 7: The data in the dialog event package should be updated when the contacts of the endpoints change.

Because an agent that knows a dialog's parameters has total control over the dialog, dissemination of that information should be restricted to trusted agents. (E.g., imagine the Jerkey Boys subscribing to dialog events for your organization's customer service line.) Guideline 8: A UA should have a way of restricting dialog information to trusted subscribers. A UA should provide one of the following methods to determine which subscribers are trusted: only SUBSCRIBEs coming directly from a specified IP address are trusted, or only SUBSCRIBEs authorized by trusted keys are trusted. Untrusted SUBSCRIBEs may come from any place on the Internet. Because the dialog event package provides presence information even if the dialog identifiers are removed: Guideline 9: A UA receiving an untrusted SUBSCRIBE should reject it rather than providing an edited version (e.g., omitting the dialog identifiers and only providing the state).

This section compares the dialog event packages generated by five current, popular commercial UAs. The data was taken by a test tool from current products that claimed to implement the dialog event package. The first table lists the responses to SUBSCRIBEs and INVITEs to both the URI specifying the first "line number" supported by the UA and to the URI that gives the phone's IP address but no user. Only one of the five implementations will accept SUBSCRIBES to both URIs (Guidelines 2 and 4). Method/user combinations accepted: User Agent SUBSCRIBE to Line 1 SUBSCRIBE to no user INVITE to Line 1 INVITE to no user A200404200404 B200404200404 C404200200200 D200200200200 E200404200404 The second table lists which INVITEs will be reported in the dialog event packages returned for which SUBSCRIBEs. Only one of the five UAs accepts all recommended SUBSCRIBEs, and it does not return all the dialogs specified by Guideline 4. Which SUBSCRIBEs report which INVITEs: User Agent INVITE on Line 1, SUBSCRIBE on Line 1 INVITE on Line 1, SUBSCRIBE on no user INVITE on no user, SUBSCRIBE on Line 1 INVITE on no user, SUBSCRIBE on no user AY--- BY--- C-Y-Y DYNNY EY--- "Y" means that the INVITE is reported for the SUBSCRIBE, "N" means that it is not, "-" means that the UA does not accept the INVITE or SUBSCRIBE The third table lists the data items present in the dialog events generated by each UA. Four of the five UAs provide all of the dialog identifiers (Guideline 5), but the populating of the identity and target fields is quite weak (Guideline 6). Which data are present in the dialog events (for incoming calls): User Agent Call-Id, Tags Direction ANN BYY CYY DYY EYY Which data are present in the dialog events (part 2): User Agent Local identity Local target Remote identity Remote target A---- BToContactFrom- C-ToContact- DToToFromFrom EToFixed valueFromContact "To" means value of the To header, "Contact" means value of the appropriate Contact header, "From" means value of the From header, "Fixed value" means a fixed string, "-" means no value