An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)
updated by
Extracted elements (26)
A single FSM is used for both UAC and UAS roles to simplify the model. The common case of no forking is represented by a single FSM instance, while forked responses (additional 1xx or 2xx with new tags) create additional FSM instances rather than complicating the primary FSM.
The FSM is extended to include states before a full dialog exists (Trying, Proceeding) so that 'half-dialogs'—where only call-id and local-tag are known—can be represented. This allows dialog state to be reported from the moment an INVITE is sent, not just after a tagged response.
The dialog 'id' attribute is a distinct identifier from the SIP dialog ID defined in RFC 3261; it is created at INVITE send/receive time and remains stable even as the dialog is formally established by tagged responses, allowing half-dialogs to be tracked before a full RFC 3261 dialog exists.
A user agent that registers with address-of-record X SHOULD authorize subscriptions from any entity that can authenticate itself as X, and SHOULD send complete dialog state to such subscribers. This enables shared-line / single-line-extension applications.
All subscribers and notifiers MUST support the 'application/dialog-info+xml' data format. If no Accept header is present in SUBSCRIBE, it defaults to 'application/dialog-info+xml'; if Accept is present, it MUST include that type.
All subscriptions SHOULD be authenticated and then authorized before approval. All implementors MUST support the digest authentication mechanism as a baseline.
Dialog information documents MUST be well-formed XML, MUST be based on XML 1.0, and MUST be encoded using UTF-8. They SHOULD be valid per the defined schema.
For congestion control, it is RECOMMENDED that the notifier not generate notifications for a single subscriber faster than once every 1 second.
For unauthenticated or third-party subscribers, it is RECOMMENDED to forbid subscriptions to specific dialogs and instead report only a single 'virtual' FSM whose state aggregates all real dialogs, conveying no dialog identifiers. This prevents disclosure of call details beyond what an INVITE probe would reveal.
Subscribers to the dialog package MUST be prepared to install subscription state for each NOTIFY generated as a result of a single forked SUBSCRIBE, since a forked SUBSCRIBE can install multiple subscriptions.
The 'sip.rendering' parameter MUST only be used in a Contact header field in a dialog created using the INVITE request. Its three legal values are 'yes', 'no', and 'unknown', indicating whether the UA is currently rendering any received media.
The dialog element has a mandatory 'id' attribute (unique among all current dialogs at a UA) and optional attributes: call-id, local-tag, remote-tag, and direction (initiator or recipient). The only mandatory sub-element is 'state'.
The dialog-info XML document root element requires three mandatory attributes: 'version' (non-negative 32-bit integer, incremented per notification per subscription), 'state' (full or partial), and 'entity' (URI of the observed user). It contains zero or more dialog sub-elements.
The event package name is 'dialog', carried in the Event and Allow-Events header fields. It covers INVITE-initiated dialog usages only; non-session dialog usages (e.g., SUBSCRIBE/NOTIFY dialogs) are out of scope.
The 'local' and 'remote' participant elements each contain optional sub-elements: identity (URI with optional display name), target (Contact URI with param sub-elements for feature tags), session-description (MIME-typed SDP), and cseq. If no identity or target element appears in a notification, the subscriber assumes it is unchanged from the previous notification.
The package defines four Event header parameters: call-id, to-tag, from-tag, and include-session-description. To subscribe to a specific dialog, all three of call-id, to-tag, and from-tag MUST be present; to subscribe to all dialogs resulting from a single INVITE, call-id and to-tag MUST be present.
The 'replaces' element in a replacement dialog correlates it with the dialog it replaced; it carries call-id, local-tag, and remote-tag attributes of the replaced dialog. The 'referred-by' element correlates a dialog with the REFER request that triggered it.
The 'sip.byeless' boolean media feature parameter, placed in the SIP Contact header with a '+' prefix, indicates that the UA is incapable of autonomously terminating a session (e.g., announcement services, recording services, or human call centers configured to never send BYE).
The 'state' element carries the FSM state as an enumerated string and has optional 'event' attribute (cancelled, rejected, replaced, local-bye, remote-bye, error, timeout) and optional 'code' attribute (SIP response code 100–699) to describe transitions to the terminated state.
The subscriber maintains a table of dialogs indexed by the 'id' attribute. On receiving a full-state document the table is flushed and repopulated; on partial state, existing rows are updated or new rows added. A document whose version is lower than the local version is discarded; a gap greater than one SHOULD trigger a refresh SUBSCRIBE.
IANA registers the MIME type 'application/dialog-info+xml' for the dialog information XML format used in NOTIFY bodies for this package.
IANA registers the XML namespace URN 'urn:ietf:params:xml:ns:dialog-info' and the schema URN 'urn:ietf:params:xml:schema:dialog-info' for the dialog information document format.
IANA registers two new SIP media feature parameters in the sip tree: 'sip.byeless' (boolean, ASN.1 id 19) and 'sip.rendering' (string with values yes/no/unknown, ASN.1 id 20).
Subscriptions to dialog state reveal sensitive information (who is calling whom, call state). All implementations MUST support digest authentication; end-to-end S/MIME MAY be used to protect notification bodies; implementations SHOULD support SIP over TLS and the sips: scheme.
The sip.byeless and sip.rendering media feature tags can influence application behavior (e.g., cause premature call termination) and may reveal private information. Applications using these tags SHOULD provide integrity protection, and protocols conveying them SHOULD provide authenticity guarantees.
The dialog FSM has five states: Trying, Proceeding, Early, Confirmed, and Terminated. Transitions are driven by SIP responses and events: 1xx-no-tag moves Trying→Proceeding; 1xx-with-tag moves to Early; 2xx moves to Confirmed; cancelled/rejected/replaced/error/timeout/BYE events move to Terminated. A single FSM handles both UAC and UAS roles; forked responses spawn new FSM instances.