Instant Message Disposition Notification

Description

Instant Message Disposition Notification (IMDN) is a protocol mechanism defined within the 3GPP IMS messaging architecture (specified in TS 24.247 and referenced in specs like 23.204) that enables the reporting of message disposition status. Disposition refers to the state or fate of a delivered instant message at the recipient's end. The primary dispositions are 'delivered' (the message reached the recipient's device or service) and 'displayed' (the message was presented to the recipient user, i.e., read). IMDN operates as an extension to the underlying messaging protocol, which is typically the Session Initiation Protocol (SIP) used with the MESSAGE method or the Message Session Relay Protocol (MSRP) for session-based messaging.

The architecture involves three main entities: the Sender User Equipment (UE) or application, the recipient UE/application, and the IMS core network elements (like the CSCF) that route the messages. The process is initiated by the sender including a specific header field (e.g., 'Disposition-Notification' in SIP MESSAGE) in the original instant message request, indicating the types of notifications (delivery, display) it wishes to receive. When the recipient's client successfully receives the message, it generates a SIP MESSAGE request back towards the sender. This notification message contains a 'Message-ID' header correlating it to the original message and a 'Disposition' header with a value like 'delivered' or 'displayed'. This notification is routed through the IMS core just like a regular instant message.

How IMDN works involves careful state management and network intermediation. For a 'delivered' notification, it is typically generated by the recipient's terminating IMS node (e.g., the recipient's S-CSCF or an Application Server) upon successful delivery to the recipient's service domain. A 'displayed' notification is generated explicitly by the recipient's messaging client application after it has rendered the message to the user. The IMS network may include intermediary Application Servers (e.g., a messaging AS) that can store and forward messages, and these servers can also generate or relay disposition notifications. The specifications define the precise XML body format (application/imdn+xml) that carries the notification data, including the original message ID, recipient address, and status. This ensures interoperability between different vendors' clients and network servers. IMDN is a key enabler for reliable messaging services within the IMS ecosystem, providing user confidence similar to that found in popular internet messaging applications.

Purpose & Motivation

IMDN was created to address a key user experience gap in early standardized IP messaging services compared to emerging Over-The-Top (OTT) messaging applications. Prior to its specification, IMS-based instant messaging, as defined in earlier releases, provided a basic 'send and forget' capability without any built-in mechanism for the sender to know if the message was successfully received or seen. This lack of feedback was a significant disadvantage compared to internet messaging apps that offered delivery and read receipts, making IMS messaging seem less reliable and engaging to users.

The primary problem IMDN solves is providing sender awareness and enhancing the reliability perception of IMS messaging. It allows senders to request and receive positive confirmation that their communication attempt was successful at different stages. This is particularly important for potentially important or time-sensitive messages. From a service provider's perspective, it also aids in troubleshooting and provides a value-added feature that can be monetized or used to differentiate their messaging service from simple SMS. It brings carrier-based messaging to feature parity with OTT services in this regard.

Historically, its introduction in 3GPP Release 8 was part of a broader effort to make IMS a competitive platform for rich communication services. It was a foundational component for the later development and standardization of Rich Communication Services (RCS), which aimed to create a globally interoperable, carrier-based messaging service with features surpassing SMS. IMDN provided the standardized 'plumbing' for read receipts, a feature that became a hallmark of modern messaging. It addressed the limitation of the earlier Open Mobile Alliance (OMA) Instant Messaging service, which lacked such a standardized notification mechanism, by defining a clean, SIP-based protocol within the IMS framework, ensuring it worked seamlessly with other IMS services like voice and video.

Key Features

• Supports two primary disposition types: 'delivered' (message reached recipient's service) and 'displayed' (message was read by user).
• Uses SIP MESSAGE method or MSRP with specific headers ('Disposition-Notification', 'Disposition') and XML body format for notifications.
• Provides correlation between original message and notification via the 'Message-ID' header.
• Can be requested selectively by the sender (e.g., only delivery receipt, or both delivery and read receipts).
• Operates within the IMS architecture, routed through CSCFs and potentially mediated by Application Servers.
• Defined as part of the IMS Messaging framework, ensuring interoperability across networks and devices.

Evolution Across Releases

Defining Specifications