A.1 Scope of signalling flows
24.6063GPPMessage Waiting Indication (MWI) using IP Multimedia (IM) Core Network (CN) subsystemProtocol specificationRelease 17TS
This annex gives examples of signalling flows for the Message Waiting Indication service within the IM CN subsystem based on the Session Initiation Protocol (SIP).
A.1.1 Introduction
A.1.1.1 General
The signalling flows provided in the following subclauses follow the methodology developed in 3GPP TS 24.228 [12]. The following additional considerations apply.
A.1.1.2 Key required to interpret signalling flows
The key to interpret signalling flows specified in 3GPP TS 24.228 [12] subclauses 4.1 and 4.2 applies with the additions specified below:
– mwi.home1.net: an MWI AS in the home network of the service provider;
– user1_public1@home1.net: subscriber’s first public user identity assigned to the message account;
– user1_public2@home1.net: subscriber’s second public user identity assigned to the message account;
– user2_public1@home2.net: first correspondent of messages in the message account;
– user3_public1@home3.net: second correspondent of messages in the message account.
Each signalling flow table contains descriptions for headers where the content of the header is new to that signalling flow, as is already performed in 3GPP TS 24.228 [12].
However, 3GPP TS 24.228 [12] includes extensive descriptions for the contents of various headers following each of the tables representing the contents of the signalling flows. Where the operation of the header is identical to that shown in 3GPP TS 24.228 [12], then such text is not reproduced in the present document.
Headers following the tables that are represented in fat cursive style describe the contents of the application/simple-message-summary MIME body.
Additional text is also found on the contents of headers within 3GPP TS 24.228 [12] in addition to the material shown in the present document.
A.1.2 Signalling flows demonstrating how UE subscribes to message waiting indication event notification
A.1.2.1 Introduction
Subclause A.1.2 covers the signalling flows that show how UE can request message waiting indication information from an application server.
A.1.2.2 MWI Subscriber subscribing to the status of his message account, MWI AS is in the subscriber’s network
Successful subscription, UE in visited network. This example shows the case when the originating S-CSCF, routes the SUBSCRIE request to an AS that provides the MWI service, based on the resolution of the public service identity of the message account.
For the purpose of the subscriber’s identity verification, the AS is located within the same trusted domain as the subscriber, see 3GPP TS 24.229 [2] subclause 5.7.1.4.
Figure A.1: UE subscription for the message-summary event package
Figure A.1 shows a user equipment subscribing to the message waiting indication notification. The details of the signalling flows are as follows:
1. SUBSCRIBE request (UE to P-CSCF) – see example in table A.1
A subscriber agent in a UE wishes to receive message waiting indication information from an application server. To initiate a subscription, the UE generates a SUBSCRIBE request containing the "message‑summary" event that it wishes to be notified of, together with an indication of the length of time this periodic subscription intends to last.
Table A.1: SUBSCRIBE request (UE to P-CSCF)
SUBSCRIBE sip:user1_ public1@home1.net SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4:1357;branch=z9hG4bKnashds7
Max-Forwards: 70
Route: <sip:pcscf1.visited1.net:7531;lr;>, <sip:orig@scscf1.home1.net;lr>
P-Preferred-Identity: <sip:user1_public1@home1.net>
Privacy: none
From: <sip:user1_public1@home1.net>;tag=31415
To: <sip:user1_ public1@home1.net>
Call-ID: b89rjhnedlrfjflslj40a222
CSeq: 61 SUBSCRIBE
Event: message-summary
Expires: 7200
Accept: application/simple-message-summary
Contact: <sip:user1_public1@1.2.3.4:1357>
Content-Length: 0
Request URI: Public service identity of the user of the message account whose events the subscriber subscribes to. In this case the subscriber subscribes to the message waiting indication events.
Event: This field is populated with the value "message-summary" to specify the use of the Message Summary Package.
Accept: This field is populated with the value "application/simple-message-summary" as described in RFC 3842 [3].
To: Same as the Request-Uri.
2. SUBSCRIBE request (P-CSCF to S-CSCF) – see example in table A.2
The SUBSCRIBE request is forwarded to the I-CSCF.
The P-CSCF looks up the serving network information for the public user identity that was stored during the registration procedure. The SUBSCRIBE request is forwarded to S-CSCF#1. A Route header is inserted into SUBSCRIBE request. The information for the Route header is taken from the service route determined during registration.
Table A.2: SUBSCRIBE request (P-CSCF to S-CSCF)
SUBSCRIBE sip:user1_ public1@home1.net SIP/2.0
Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK120f34.1, SIP/2.0/UDP 1.2.3.4:1357;comp=sigcomp;branch=z9hG4bKehuefdam
P-Access-Network-Info:
Route: <sip:orig@scscf1.home1.net;lr>
Max-Forwards: 69
P-Asserted-Identity: <sip:user1_public1@home1.net>
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=223551024"
Privacy:
Record-Route: <sip:pcscf1.visited1.net;lr>
Route: <sip:scscf1.home1.net;lr>
From:
To:
Call-ID:
CSeq:
Event:
Supported:
Expires:
Accept:
Contact:
Content-Length:
3. Evaluation of initial filter criteria
The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. Assuming that sip:user1_mwiacc1@home1.net is a statically created PSI, sip:user1_mwiacc1@home1.net is included in the service profile of user1_public1@home1.net as part of an originating initial Filter Criteria with Service Trigger Point of Method = SUBSCRIBE AND Event = "message-summary" AND Request-URI = sip:user1_mwiacc1@home1.net, that informs the S-CSCF to route the SUBSCRIBE request to the application server sip:mwi.home1.net.
If there is no initial filter criteria for this PSI (sip:user1_mwiacc1@home1.net), the assumption is that the PSI is a sub domain-based PSI. The procedure defined in RFC 3263 [9] with DNS NAPTR and SRV queries aligned with the operator policy is then be used for the resolution of the PSI.
4. SUBSCRIBE (S-CSCF to AS) – see example in table A.3
The S-CSCF forwards the SUBSCRIBE request to AS.
Table A.3: SUBSCRIBE request (S-CSCF to AS)
SUBSCRIBE sip:user1_ public1@home1.net SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK344a65.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK120f34.1, SIP/2.0/UDP 1.2.3.4:1357;branch=z9hG4bKehuefdam
Max-Forwards: 68
P-Asserted-Identity: <sip:user1_public1@home1.net>, <tel:+1-212-555-1111>
P-Charging-Vector:
P-Charging-Function-Addresses:
Privacy:
Record-Route: <sip:orig@scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>
Route: <sip:mwi.home1.net;lr>, <sip:orig@scscf1.home1.net;lr>
From:
To:
Call-ID:
CSeq:
Event:
Supported:
Expires:
Accept:
Contact:
Content-Length:
5. Identification of the message account and subscriber authorization
Based on the Request-URI the MWI AS identifies the requested message account.
P-Asserted-Identity header information authorizes the subscriber to subscribe to status change of the message account, as one of the identities is authorized for this account.
In this example the authorization is successful, so the AS sends a 200 (OK) response to the S-CSCF. If the previous condition failed, then a 403 (Forbidden) response would be sent to the S-CSCF.
6. 200 (OK) response (MWI AS to S-CSCF) – see example in table A.4
The MWI AS forwards the response to the S-CSCF.
Table A.4: 200 (OK) response (AS to S-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK344a65.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK120f34.1, SIP/2.0/UDP 1.2.3.4:1357;branch=z9hG4bKehuefdam
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=223551024"; orig-ioi=home1.net; term-ioi=home1.net
Record-Route:
From: <sip:user1_public1@home1.net>;tag=31415
To: <sip:user1_ public1@home1.net>;tag=151170
Call-ID: b89rjhnedlrfjflslj40a222
CSeq:
Expires:
Contact: <sip:mwi.home1.net>
Content-Length: 0
7. 200 (OK) response (S-CSCF to P-CSCF )
The S-CSCF forwards the 200 (OK) response to the P-CSCF.
8. 200 (OK) response (P-CSCF to UE)
P-CSCF forwards the 200 (OK) response to the UE.
9. NOTIFY request (MWI AS to S-CSCF) – see example in table A.5
As required by the RFC 6665 [4] the MWI AS immediately after successful subscription sends the NOTIFY request to the S-CSCF to synchronize the current state of the message account at the subscriber’s UE. This initial notification contains no extended information about available message. Further notifications sent by MWI AS is contain either extended or basic set of message waiting information as described in
RFC 3842 [3].
In this example it is assumed that the message account at the moment of subscription has thee voice messages (two new and one old, with one new message being urgent), one old video message and two fax messages (one new and one old with the old message being urgent).
Table A.5: Initial NOTIFY request (MWI AS to S-CSCF)
NOTIFY sip:user1_public1@1.2.3.4:1357 SIP/2.0
Via: SIP/2.0/UDP mwi.home1.net;branch=z9hG4bK332b23.1
Max-Forwards: 70
Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.home1.net;lr>
From: <sip:user1_ public1@home1.net>;tag=31415
To: <sip:user1_public1@home1.net>;tag=151170
Call-ID: b89rjhnedlrfjflslj40a222
CSeq: 42 NOTIFY
Subscription-State: active;expires=7200
Event: message-summary
Contact: <sip:mwi.home1.net>
Content-Type: application/simple-message-summary
Content-Length: (…)
Messages-Waiting: yes
Message-Account: sip:user1_public1@home1.net
Voice-Message: 2/1 (0/0)
Video-Message: 0/1 (0/0)
Fax-Message: 1/1 (0/1)
Content-Type: Set to "application/simple-message-summary" as described in RFC 3842 [3].
The message body in the NOTIFY request that carries the message waiting indication is formed as described in subclause 4.6.
Message-Account: The MWI AS populates this filed with the public user identity used to access the message account that received the subscription.
Voice-Message: The MWI AS populates this filed with the information about voice messages that are waiting in the message account.
Video-Message: The MWI AS populates this filed with the information about video messages that are waiting in the message account.
Fax-Message: The MWI AS populates this filed with the information about fax messages that are waiting in the message account.
12. 200 (OK) response (UE to P-CSCF)
The UE acknowledges the NOTIFY request with a 200 (OK) response to the P-CSCF.
15. notifications on message-summary event package
After the MWI AS generated a NOTIFY request to inform the subscriber’s UE about the subscription state, the MWI AS waits for the change of the message account status. As soon as new messages(s) are deposited into the message account the MWI AS generates a NOTIFY request to indicate the change in the message account status to the subscriber’s UE.
16. NOTIFY request (AS to S-CSCF) – see example in table A.6
The MWI AS uses available information from the interaction with correspondents and message left in the message account to fill the headers in the simple-message-summary MIME body of the NOTIFY request. This notification sent by the MWI AS contains an extended set of message waiting information about newly deposited messages since the last notification as described in RFC 3842 [3].
In this example it is assumed that the subscriber’s message account has received three new messages (two urgent voice and one non urgent video message) since the successful immediate NOTIFY transaction from the correspondents sip:user2_public1@home1.net and sip:user3_public1@home3.net. The correspondents used different public user identities of the subscriber to deposit messages.
Table A.6: NOTIFY request (MWI AS to S-CSCF)
NOTIFY sip:user1_public1@1.2.3.4:1357 SIP/2.0
Via: SIP/2.0/UDP mwi.home1.net;branch=z9hG4bK332b23.1
Max-Forwards: 70
Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.home1.net;lr>
From: <sip:user1_ public1@home1.net>;tag=31415
To: <sip:user1_public1@home1.net>;tag=151170
Call-ID: b89rjhnedlrfjflslj40a222
CSeq: 43 NOTIFY
Subscription-State: active;expires=5000
Event: message-summary
Contact: <sip:mwi.home1.net>
Content-Type: application/simple-message-summary
Content-Length: (…)
Messages-Waiting: yes
Message-Account: sip:user1_public1@home1.net
Voice-Message: 4/1 (2/0)
Video-Message: 1/1 (0/0)
Fax-Message: 1/1 (0/1)
To: <user1_public1@home1.net>
From: <user2_public1@home1.net>
Subject: call me back!
Date: 19 Apr 2005 21:45:31 -0700
Priority: urgent
Message-ID: 27775334485@mwi.home1.net
Message-Context: voice-message
To: <user1_public2@home1.net>
From: <user2_public1@home1.net>
Subject: Where are you that late???
Date: 19 Apr 2005 23:45:31 -0700
Priority: urgent
Message-ID: 27775334485@mwi.home1.net
Message-Context: voice-message
To: <user1_public1@home1.net>
From: <user3_public1@home3.net>
Subject: Did you see that penalty!!!
Date: Tue, 19 Apr 2005 22:12:31 -0700
Priority: normal
Message-ID: 26775334485@mwi.home1.net
Message-Context: video-message
Content-Type: Set to "application/simple-message-summary" as described in RFC 3842 [3].
The message body in the NOTIFY request that carries the message waiting indication is formed as described in the subclause 4.6.
Message-Account: The MWI AS populates this filed with the public user identity used to access the message account that has new messages for the subscriber.
Voice-Message: Since two new urgent voice messages were received by the message account, the number of new voice messages is increased to four and the number of the new urgent messages is increased to two.
Video-Message: One new video message was received by the message account and accordingly the number of new video messages set to one.
Fax-Message: No new fax messages were received by the message account, so the number of fax messages is unchanged.
To: This header in the MIME body populates the information about the public user identity of subscriber, that was used by correspondent to deposit a message.
From: This header in the MIME body populates the information about the public user identity, of correspondent, that left a message to the subscriber.
Subject: This header populates the information about the subject, that was assigned to the left message by correspondent.
Date: This header populates the information about the date and time when a message was left.
Priority: This header populates the information about the message urgency assigned by correspondent.
Message-ID: This header populates the information about the message identity, that is assigned to the message by the MWI AS.
Message-Context: This header populates the information about the type of the deposited message, that has the extended set of message waiting information.
A.1.2.3 Void
A.1.3 Void
A.1.4 Signalling flows demonstrating how a message is deposited into the subscribers message account
A.1.4.1 Introduction
Subclause A.1.4 covers the signalling flows that show how a message is deposited into the subscribers message account.
A.1.4.2 Depositing a message into the subscriber’s message account
A.1.4.2.1 Successful message deposit into the subscriber’s message account
This call-flow shows the deposit of the message in to the subscriber’s message account by a correspondent.
"Integration of resource management and SIP" not required by the MWI AS and not used by correspondent’s UE.
Figure A.5: Correspondent depositing a message into the subscriber’s MA
Figure A.5 shows a correspondent user equipment creating, interacting over RTP and terminating a session with the MWI AS. The details of the signalling flows are as follows:
1. INVITE request (Correspondent to P-CSCF) – see example in table A.15
A correspondent wishes to initiate a session with the MWI subscriber. To initiate the session, the correspondent generates an INVITE request to MWI subscriber.
Table A.15: INVITE request (UE to P-CSCF)
INVITE sip:user1_public1@home1.net SIP/2.0
Via: SIP/2.0/UDP 2.3.4.5:2468;branch=0uetb
Max-Forwards: 70
Route: <sip:pcscf1.visited2.net:8642;lr;>, <sip:orig@scscf1.home3.net;lr>
P-Preferred-Identity: <sip:user3_public1@home3.net>
Privacy: none
From: <sip:user3_public1@home3.net>;tag=31417
To: <sip:user1_public1@home1.net>
Call-ID: apb03a0s09dkjdfglk49111
CSeq: 22 INVITE
Contact: <sip:user3_public1@2.3.4.5:2468>
Content-Type: application/sdp
Content-Length: (…)
v=0
o=user3 2890844526 2890844526 IN IP4 2.3.4.5
s=-
c=IN IP4 2.3.4.5
t=0 0
m=audio 49172 RTF/AVP 0
a=rtpmap:0 PCMU/8000
Request URI: Public user identity of the MWI subscriber.
From: Public user identity of the Correspondent.
To: Same as the Request-Uri.
Content-Type: Set to "application/sdp".
The message body includes the SDP information.
2. INVITE request (P-CSCF to S-CSCF) – see example in table A.16
The INVITE request is forwarded to the S-CSCF in MWI subscriber’s home network.
Table A.16: INVITE request (S-CSCF to S-CSCF)
INVITE sip:user1_public1@home1.net SIP/2.0
Via: SIP/2.0/UDP scscf1.home3.net;branch=z9bhksl3dlc23xm
Via: SIP/2.0/UDP pcscf1.visited2.net;branch=z9hG4bK120f34.1
Via: SIP/2.0/UDP 2.3.4.5:2468;comp=sigcomp;branch=z9hG4bKehuefdam
Record-Route: <sip:orig@scscf1.home3.net;lr>
Record-Route: <sip:pcscf1.visited2.net:8642;lr>
Max-Forwards: 68
Privacy: none
From: <sip:user3_public1@home2.net>;tag=31417
To: <sip:user1_public1@home1.net>
Call-ID: apb03a0s09dkjdfglk49111
CSeq: 22 INVITE
Contact: <sip:user3_public1@2.3.4.5:2468>
Content-Type: application/sdp
Content-Length: (…)
v=0
o=user3 2890844526 2890844526 IN IP4 2.3.4.5
s=-
c=IN IP4 2.3.4.5
t=0 0
m=audio 49172 RTF/AVP 0
a=rtpmap:0 PCMU/8000
3. Evaluation of initial filter criteria
The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. Assuming that MWI service is included in the service profile of user1_public1@home1.net as part of an terminating initial Filter Criteria with Service Trigger Point of Method = INVITE AND Request-URI = sip:user1_public1@home1.net AND subscriber state = logout, that informs the S-CSCF to route the INVITE request to the application server sip:mwi.home1.net when the state of user1_public1@home1.net is logout.
4. INVITE (S-CSCF to AS) – see example in table A.17
The S-CSCF forwards the INVITE request to AS.
Table A.17: INVITE request (S-CSCF to AS)
INVITE sip:user1_public1@home1.net SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9ack2k2bjbm0fu
Via: SIP/2.0/UDP scscf1.home3.net;branch=z9bhksl3dlc23xm
Via: SIP/2.0/UDP pcscf1.visited2.net;branch=z9hG4bK120f34.1
Via: SIP/2.0/UDP 2.3.4.5:2468;comp=sigcomp;branch=z9hG4bKehuefdam
Record-Route: <sip:scscf1.home1.net;lr>
Record-Route: <sip:orig@scscf1.home3.net;lr>
Record-Route: <sip:pcscf1.visited2.net:8642;lr>
Max-Forwards: 67
Privacy: none
From: <sip:user3_public1@home2.net>;tag=31417
To: <sip:user1_public1@home1.net>
Call-ID: apb03a0s09dkjdfglk49111
CSeq: 22 INVITE
Contact: <sip:user3_public1@2.3.4.5:2468>
Content-Type: application/sdp
Content-Length: (…)
v=0
o=user3 2890844526 2890844526 IN IP4 2.3.4.5
s=-
c=IN IP4 2.3.4.5
t=0 0
m=audio 49172 RTF/AVP 0
a=rtpmap:0 PCMU/8000
5. Identification of the message account and subscriber authorization
Based on the Request-URI the MWI AS identifies the requested message account.
In the requested message account is valid, AS sends a 200 (OK) response to the S-CSCF.
6. 200 (OK) response (MWI AS to S-CSCF) – see example in table A.18
The MWI AS forwards the response to the S-CSCF.
Table A.18: 200 (OK) response (AS to S-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9ack2k2bjbm0fu
Via: SIP/2.0/UDP scscf1.home3.net;branch=z9bhksl3dlc23xm
Via: SIP/2.0/UDP pcscf1.visited2.net;branch=z9hG4bK120f34.1
Via: SIP/2.0/UDP 2.3.4.5:2468;comp=sigcomp;branch=z9hG4bKehuefdam
Record-Route: <sip:scscf1.home1.net;lr>
Record-Route: <sip:orig@scscf1.home3.net;lr>
Record-Route: <sip:pcscf1.visited2.net:8642;lr>
From: <sip:user3_public1@home2.net>;tag=31417
To: <sip:user1_public1@home1.net>
Call-ID: apb03a0s09dkjdfglk49111
CSeq: 22 INVITE
Contact: <sip:user1_mwiacc1@mwi.home1.net>
Content-Type: application/sdp
Content-Length: (…)
v=0
o=user3 2890844527 2890844527 IN IP4 12.13.14.15
s=-
c=IN IP4 12.13.14.15
t=0 0
m=audio 3456 RTF/AVP 0
a=rtpmap:0 PCMU/8000
The Content-Type is set to "application/sdp" and the SDP information in AS is included in the message body.
9. ACK request (Correspondent to P-CSCF) – see example in table A.19
The correspondent sends an ACK request to P-CSCF.
Table A.19: ACK request (UE to P-CSCF)
ACK sip:user1_public1@home1.net SIP/2.0
Via: SIP/2.0/UDP 2.3.4.5:2468;branch=0uetb
Max-Forwards: 70
Route: <sip:pcscf1.visited2.net:8642;lr;>, <sip:orig@scscf1.home3.net;lr>
From: <sip:user3_public1@home3.net>;tag=31417
To: <sip:user1_public1@home1.net>
Call-ID: apb03a0s09dkjdfglk49111
CSeq: 22 ACK
Content-Length: 0
12. The Correspondent deposits a message to the message account
The correspondent interacts with MWI AS and deposits a message via RTP into the subscriber’s message account.
13. BYE request (Correspondent to P-CSCF) – see example in table A.20
After deposits a message to the subscriber’s message account successfully, the correspondent sends a BYE to release the session.
Table A.20: BYE request (UE to P-CSCF)
BYE sip:user1_public1@home1.net SIP/2.0
Via: SIP/2.0/UDP 2.3.4.5:2468;branch=0uetb
Max-Forwards: 70
Route: <sip:pcscf1.visited2.net:8642;lr;>, <sip:orig@scscf1.home3.net;lr>
From: <sip:user3_public1@home3.net>;tag=31417
To: <sip:user1_public1@home1.net>
Call-ID: apb03a0s09dkjdfglk49111
CSeq: 22 BYE
Content-Length: 0
16. 200 (OK) response (MWI AS to S-CSCF) – see example in table A.21
The MWI AS forwards the response to the S-CSCF.
Table A.21: 200 (OK) response (AS to S-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP 2.3.4.5:2468;branch=0uetb
Max-Forwards: 70
Route: <sip:pcscf1.visited2.net:8642;lr;>, <sip:orig@scscf1.home3.net;lr>
From: <sip:user3_public1@home3.net>;tag=31417
To: <sip:user1_public1@home1.net>
Call-ID: apb03a0s09dkjdfglk49111
CSeq: 22 BYE
Content-Length: 0
19. Status of subscriber’s MA gets modified
The MWI AS updates the status of the subscriber’s message account.
If the MWI service is already invoked by the subscriber, MWI notifies the subscriber about new message being deposited into the subscriber’s message account as described in subclause A.1.2.3.
Annex B (informative):
Example of a filter criteria
This annex provides an example of a filter criterion that triggers SIP requests that are subject to initial filter criteria evaluation.
Following example shows the Service Point Triggers in an Initial Filter Criteria of the service profile for the subscriber with the public user identity user1_public1@home1.net. This Initial Filter Criteria informs the S-CSCF to route the SUBSCRIBE request to the application server sip:mwi.home1.net that provides MWI service addressed with the public user identity sip:user1_user1_public1@home1.net.
Method: SUBSCRIBE
Event: message-summary
Request-URI: sip:user1_public1@home1.net
Application Server: sip:mwi.home1.net
Annex C (informative):
(void)
Annex D (informative):
Change history
|
Change history |
|||||||
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Subject/Comment |
Old |
New |
|
2006-03 |
Publication as ETSI TS 183 006 |
1.1.1 |
|||||
|
2007-03 |
Publication as ETSI TS 183 006 |
1.2.1 |
|||||
|
2007-12 |
Conversion to 3GPP TS 24.206 |
1.2.2 |
|||||
|
2008-01 |
Technically identical copy as 3GPP TS 24.606 as basis for further development |
1.2.3 |
|||||
|
2008-02 |
Implemented C1-080098 |
1.3.0 |
|||||
|
2008-03 |
Rapporteur corrected systematic errors that happened during implementation of C1-080098 (typos, wrong formatting) |
1.3.1 |
|||||
|
2008-04 |
Implemented C1-080880, C1-080881, C1-081046, C1-081084, C1-081085. |
1.4.0 |
|||||
|
2008-05 |
Implemented C1-081902, C1-081907, C1-081910. |
1.5.0 |
|||||
|
2008-05 |
Editorial changes done by MCC |
1.5.0 |
1.5.1 |
||||
|
2008-06 |
CT-40 |
CP-080327 |
CP-080327 was approved by CT#40 and version 8.0.0 is created by MCC for publishing |
1.5.1 |
8.0.0 |
||
|
2008-09 |
CT-41 |
CP-080533 |
0001 |
Correction of minors mistakes in signalling flows |
8.0.0 |
8.1.0 |
|
|
2008-09 |
CT-41 |
CP-080533 |
0002 |
Applicability statement in scope |
8.0.0 |
8.1.0 |
|
|
2008-09 |
CT-41 |
CP-080533 |
0003 |
Terminology alignment and modal auxilary verb usage |
8.0.0 |
8.1.0 |
|
|
2009-12 |
CT-46 |
Upgrade to Rel-9 |
8.1.0 |
9.0.0 |
|||
|
2010-03 |
CT-47 |
CP-100121 |
0006 |
1 |
Interaction with presence and messaging |
9.0.0 |
9.1.0 |
|
2011-03 |
CT-51 |
Upgrade to Rel-10 |
9.1.0 |
10.0.0 |
|||
|
2011-09 |
CT-53 |
CP-110659 |
0009 |
Non-configurable MWI account URI |
10.0.0 |
10.1.0 |
|
|
2011-09 |
CT-53 |
CP-110657 |
0012 |
Updating of references to 24.228 |
10.0.0 |
10.1.0 |
|
|
2012-06 |
CT-56 |
CP-120291 |
0016 |
Removal of misleading material from examples annex |
10.1.0 |
11.0.0 |
|
|
2012-09 |
CT-57 |
CP-120583 |
0017 |
1 |
Support of non support of MWI |
11.0.0 |
11.1.0 |
|
2013-12 |
CT-62 |
CP-130770 |
0018 |
2 |
Updating TS 24.606 to RFC 6665 |
11.1.0 |
12.0.0 |
|
2015-12 |
CT-70 |
Upgrade to Rel-13 |
12.0.0 |
13.0.0 |
|||
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2017-03 |
CT-75 |
Upgrade to Rel-14 |
14.0.0 |
||||
|
2017-12 |
CT-78 |
CP-173071 |
0020 |
2 |
B |
Message Waiting Indication (MWI) using IP Multimedia (IM) Core Network (CN) subsystem |
15.0.0 |
|
2019-09 |
CT-85 |
CP-192037 |
0025 |
A |
Removal of misleading flow and Editor’s Note |
15.1.0 |
|
|
2019-12 |
CT-86 |
CP-193111 |
0026 |
B |
Adding interactions with "Multi-Device" and "Multi-Identity" services |
16.0.0 |
|
|
2022-04 |
CT-95e- |
– |
– |
– |
– |
Update to Rel-17 version (MCC) |
17.0.0 |