A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)
Extracted elements (27)
A notifier MAY quarantine NOTIFY requests for a short period when message status is changing rapidly, replacing stale queued notifications with newer ones, to reduce notification volume. This is encouraged for implementations with heavy interactive use.
A simple text-based format was chosen for the NOTIFY body to prevent an undue burden on low-end user agents such as inexpensive IP phones with no display. Although text-based, the format is intended for machine consumption only.
SIP-Specific Event Notification (RFC 3265) was chosen as the mechanism for MWI because it preserves the user mobility and rendezvous features that SIP provides, while allowing status information orthogonal to a session to be conveyed.
Although the application/simple-message-summary format is similar to RFC 2822, it is not identical: line folding rules are SIP-specific and included URIs can contain non-ASCII characters. Protocols with line length or character-set restrictions MUST use a reversible transfer encoding such as base64.
Forked SUBSCRIBE requests are allowed for this event type and may install multiple subscriptions. If any forked 'Messages-Waiting' line reports 'yes', the merged state is 'yes'; otherwise it is 'no'. Summary lines MAY be merged in an implementation-specific way.
A messaging system which includes RFC 2822 style message headers in a NOTIFY MUST provide an administrator configurable mechanism to select which headers are sent.
If no 'Accept' header is present in the SUBSCRIBE request, the body type application/simple-message-summary MUST be assumed by the notifier.
If re-subscription fails, the Subscriber SHOULD periodically retry until a subscription is successful, taking care to backoff to avoid network congestion. If a subscription has expired, new re-subscriptions MUST use a new Call-ID.
If the Request-URI or To header corresponds to a group or collection of individual messaging accounts, the notifier MUST specify to which account the message-summary body corresponds using the Message-Account field. The account URI MUST NOT be delimited with angle brackets.
Immediately after a subscription is accepted, the Notifier MUST send a NOTIFY with the current message summary information for state resynchronization. This initial synchronization NOTIFY MUST NOT include optional RFC 2822 style message headers.
Message counter values have a maximum of 4,294,967,295 (2^32 - 1). Notifiers MUST NOT generate a request with a larger value, and Subscribers MUST treat a larger value as 2^32-1.
Message headers MUST NOT be included in an initial NOTIFY, as new messages could be essentially unbounded in size. Message headers in subsequent notifications MUST only correspond to messages added since the previous notification for that subscription.
Notifiers SHOULD NOT generate NOTIFY requests more frequently than once per second.
NOTIFY messages sent to subscribers of a group or alias MUST contain the message account name in the notification body.
Subscriptions to the message-summary event package MAY range from minutes to weeks; subscriptions in hours or days are more typical and are RECOMMENDED. The default subscription duration is one hour.
The messaging notifier MUST NOT consider a message 'old' merely because it generated a notification, as this could prevent another subscription from accurately receiving message-summary notifications.
The Subscriber MUST be prepared to receive and process a NOTIFY with new state immediately after sending a new SUBSCRIBE, a SUBSCRIBE renewal, an unsubscribe, a fetch, or at any other time during the subscription.
The Subscriber MUST be prepared to receive NOTIFYs from different Contacts corresponding to the same SUBSCRIBE, as the SUBSCRIBE may have been forked.
When a SIP Messaging System receives SUBSCRIBE messages with the message-summary event-type, it SHOULD authenticate the subscription request.
When a user de-registers from a device, subscribers SHOULD unsubscribe by sending a SUBSCRIBE message with an Expires header of zero.
The event package name for message waiting indication is 'message-summary', as defined per RFC 3265. Subscribers use this token in the Event header of SUBSCRIBE requests.
The message-summary body begins with a mandatory 'Messages-Waiting' status line (yes/no), an optional 'Message-Account' URI line, and optional per-context summary lines of the form 'context-class: new/old (urgent-new/urgent-old)'.
The msg-summary-line format is: message-context-class ':' newmsgs '/' oldmsgs ['(' new-urgentmsgs '/' old-urgentmsgs ')']. Message-context-class values (e.g., voice-message, fax-message) are defined in RFC 3458.
This document registers the 'message-summary' SIP event package in the IANA SIP Event Package registry.
This document registers the MIME type application/simple-message-summary for carrying message waiting status and summary information in SIP NOTIFY bodies.
Message summaries and optional message bodies contain privacy-sensitive information. Subscriptions to this event package SHOULD be authenticated and properly authorized, and notifications SHOULD be encrypted and integrity protected using end-to-end mechanisms or hop-by-hop protection via SIPS URIs.
The application/simple-message-summary body consists of a msg-status-line (Messages-Waiting: yes/no), an optional Message-Account URI, optional msg-summary-line entries per message-context-class with new/old and urgent counts encoded as DIGIT strings not exceeding 2^32-1, and optional RFC 2822-style extension headers.