4 Message Waiting Indication (MWI)
24.6063GPPMessage Waiting Indication (MWI) using IP Multimedia (IM) Core Network (CN) subsystemProtocol specificationRelease 17TS
4.1 Introduction
The Message Waiting Indication (MWI) service enables the network, upon the request of a controlling user to indicate to the receiving user, that there is at least one message waiting.
4.2 Description
4.2.1 General description
The MWI service enables the AS to indicate to the subscriber, that there is at least one message waiting.
The indication is delivered to the subscriber’s UE after successful subscription to the Message Waiting Indication service as described in the present document.
Other modes of MWI service invocation are not applicable.
NOTE: Having received this indication, the subscriber user can subsequently access the message account, to have the deposited message delivered. The means by which the subscriber accesses and manages the message account are outside the scope of the present document.
4.3 Functional entities
4.3.1 User Equipment (UE)
The UE shall implement the MWI Subscriber User Agent role as described in subclause 4.4.1.
4.3.2 Application Server (AS)
An AS shall implement the role of a MWI Notifier User Agent as described in subclause 4.4.2.
An AS implementing the role of MWI Notifier User Agent shall implement the role of the AS acting as terminating UA as described in 3GPP TS 24.229 [2], subclause 5.7.2.
Additionally an AS may implement other roles for the receipt and storage of the messages for example Web Server, Mail Transfer and Delivery Agent, Short Message Service centre, etc.
The definition of additional roles for an MWI AS is out of the scope for the current specification.
4.4 Roles
4.4.1 MWI Subscriber User Agent (MSUA)
A MSUA is an entity that is subscribed or requests information about status change of message account from an MWI AS.
Actions performed by a MSUA as a part of the UE are described in subclause 4.7.2.1.
4.4.2 MWI Notifier User Agent (MNUA)
The MNUA is an entity that provides information about changes in message account status to the MSUA.
Actions performed by a MWI Notifier User Agent as a part of the AS are described in subclause 4.7.2.5.
4.4.3 Message Account (MA)
4.4.3.0 General
The definition of the message account from the RFC 3842 [3] applies with following additions:
Message account retains multimedia messages (e.g. voice, video and fax) intended to a particular subscriber.
4.4.3.1 Identification of the message account for the message deposit
Since messages may be intended to the different public user identities that belong to the same subscriber, the message account may be configured to retain messages for any of the subscriber’s public user identities.
Configuration of a message account to retain messages for each public user identity, for a group of public user identities or for all of public user identities that belong to the same subscriber is subject to the operator’s policy.
4.4.3.2 Identification of the message account for the MWI subscription
For the identification of the message account by subscriptions to the MWI service any of a subscriber’s public user identities can be used (see examples in subclause A.1.1.2).
4.5 Operational requirements
4.5.1 Provision/withdrawal
The MWI service is provided after prior arrangement with the service provider. The MWI service shall be withdrawn at the subscriber’s request or for administrative reasons.
Any of the subscriber’s public user identities can be used to access the MWI service, see annex B.
4.5.2 Requirements on the originating network side
No specific requirements are needed on the originating network side.
NOTE: Annex B includes an example of an iFC that can be used to invoke the MWI supplementary service.
4.5.3 Requirements in the network
No specific requirements are needed in the network.
4.5.4 Requirements on the terminating network side
No specific requirements are needed in the network.
4.6 Coding requirements
The application/simple-message-summary MIME type used to provide Message Summary and Message Waiting Indication Information is defined in subclause 5 of RFC 3842 [3].
The coding of the message types in the message-context-class values is defined in the specifications listed in the "reference" column of table 1.
Table 1: Coding requirements
|
Value |
Reference |
|
voice-message |
RFC 3458 [5] |
|
video-message |
RFC 3938 [6] |
|
fax-message |
RFC 3458 [5] |
|
pager-message |
RFC 3458 [5] |
|
multimedia-message |
RFC 3458 [5] |
|
text-message |
RFC 3458 [5] |
|
none |
RFC 3458 [5] |
The coding of the additional information about deposited messages in the application/simple-message-summary MIME body is defined in subclause 25 of RFC 3261 [11] for SIP extension-header (subclause 3.5 of RFC 3842 [3]) and follow the rules defined in the specifications listed in the "reference" column of table 2.
Table 2: Additional information
|
Header |
Description |
Reference |
|
To: |
Indicates the subscriber’s public user identity used by correspondent to deposit a message. |
subclause 3.6.3 of RFC 2822 [7] |
|
From: |
Indicates the correspondent’s public user identity, if available. |
subclause 3.6.2 of RFC 2822 [7] |
|
Subject: |
Indicates the topic of the deposited message as provided by correspondent. |
subclause 3.6.5 of RFC 2822 [7] |
|
Date: |
Indicates the time and date information about message deposit. |
subclause 3.6.1 of RFC 2822 [7] |
|
Priority: |
Indicates the message priority as provided by correspondent. |
RFC 2156 [8] |
|
Message-ID: |
Indicates a single unique message identity. |
subclause 3.6.4 of RFC 2822 [7] |
|
Message-Context: |
Indicates a type or context of message. |
RFC 3458 [5] |
4.7 Signalling requirements
4.7.1 Activation/deactivation
The MWI service is immediately activated after the SUBSCRIBE request from the MSUA is successfully processed, see subclause 4.7.2.
The MWI service is deactivated after subscription expiry or after unsuccessful attempt to deliver a notification about message waiting.
4.7.1A Registration/erasure
The MWI service requires no registration. Erasure is not applicable.
4.7.1B Interrogation
Interrogation of MWI is not applicable.
4.7.2 Invocation and operation
4.7.2.1 Actions at the MSUA
When the MSUA intends to subscribe for status information changes of a message account, the MSUA shall generate a SUBSCRIBE request in accordance with RFC 6665 [4] and RFC 3842 [3] and in alignment with the procedures described in 3GPP TS 24.229 [2]. If the UE receives a 489 (Bad Event) response or a 405 (Method Not Allowed) response to the SUBSCRIBE request, the UE shall not re-try the SUBSCRIBE request until de-registration of the public user identity from IMS.
NOTE: 489 (Bad Event) response or 405 (Method Not Allowed) response to the SUBSCRIBE request indicates that MWI is not supported in the network.
The MSUA will address the SUBSCRIBE request to one of the subscriber’s public user identities (see subclause 4.5.1).
The MSUA shall implement the "application/simple-message-summary" content type as described in RFC 3842 [3].
4.7.2.2 Void
4.7.2.3 Void
4.7.2.4 Void
4.7.2.5 Actions at the MNUA
When the MNUA receives a SUBSCRIBE request for the "message-summary" event package, the MNUA shall identify the message account which status information is requested (see subclause 4.4.3.2), then the MNUA shall attempt to verify the identity of the source of the SUBSCRIBE request as described in 3GPP TS 24.229 [2] subclause 5.7.1.4, then perform authorization according to 3GPP TS 24.229 [2] subclause 5.7.1.5.
In case of successful subscription, the MNUA shall generate a response to the SUBSCRIBE request and notifications in accordance with RFC 6665 [4] and RFC 3842 [3], and as defined by subclause 4.6.
4.7.2.6 Void
4.7.2.7 Void
4.7.2.8 Void
4.7.2.9 Void
4.8 Interaction with other IMS capabilities
4.8.1 Void
4.8.2 Void
4.9 Interaction with other services
4.9.1 Communication Hold (HOLD)
No impact, i.e. neither service shall affect the operation of the other service.
4.9.2 Terminating Identification Presentation (TIP)
No impact, i.e. neither service shall affect the operation of the other service.
4.9.3 Terminating Identification Restriction (TIR)
No impact, i.e. neither service shall affect the operation of the other service.
4.9.4 Originating Identification Presentation (OIP)
No impact, i.e. neither service shall affect the operation of the other service.
4.9.5 Originating Identification Restriction (OIR)
No impact, i.e. neither service shall affect the operation of the other service.
4.9.6 CONFerence calling (CONF)
No impact, i.e. neither service shall affect the operation of the other service.
4.9.7 Communication DIVersion services (CDIV)
4.9.7.0 General
The subscriber of the message waiting indication service receives the notifications about the change in the status of message account only from .
Communication diversion services shall not impact the processing of message waiting indication subscriptions, notifications and responses.
4.9.7.1 Communication Forwarding Unconditional (CFU)
MWI notifications shall not be affected by the communication forwarding unconditional service and always be forwarded to subscribers’ current location (if known).
4.9.7.2 Communication Forwarding Busy (CFB)
MWI notifications shall not be affected by the communication forwarding busy service and always be forwarded to subscribers’ current location (if known).
The UE will inform the AS if it will not be able to process the notification at the time.
4.9.7.3 Communication Forwarding No Reply (CFNR)
MWI notifications shall not be affected by the communication forwarding busy service and always be forwarded to subscribers’ current location (if known).
The S-CSCF will inform the AS if the UE can not be contacted at the time.
4.9.7.4 Communication Forwarding on Not Logged-in (CFNL)
MWI notifications shall not be affected by the communication forwarding busy service and always be forwarded to subscribers’ current location (if known).
The S-CSCF will inform the AS if the UE is not logged-in at the time.
4.9.7.5 Communication Deflection (CD)
MWI notifications shall not be affected by the communication deflection service. The AS shall ignore the redirection information received from the UE and process a 3xx response as a 480 Temporarily Unavailable response.
4.9.8 Malicious Call IDentification (MCID)
No impact, i.e. neither service shall affect the operation of the other service.
4.9.9 Explicit Communication Transfer (ECT)
No impact, i.e. neither service shall affect the operation of the other service.
4.9.10 Enhanced Calling Name (eCNAM)
No impact, i.e. neither service shall affect the operation of the other service.
4.9.11 Multi-Device (MuD)
No impact. Neither service shall affect the operation of the other service.
4.9.12 Multi-Identity (MiD)
No impact. Neither service shall affect the operation of the other service.
NOTE: The subscriber of the MWI service receives the notifications about the change in the status of message account only for the subscriber’s public user identities i.e. the MWI service is not supported for the other identities that UE can use.
4.10 Interactions with other networks
Interaction with other networks is performed according to 3GPP TS 24.229 [2].
4.10.1 Void
4.10.2 Void
4.10.3 Void
4.11 Parameter values (timers)
Not applicable.
Annex A (informative):
Example signalling flows of Message Waiting Indication (MWI) service operation