A.5 Flows demonstrating session-based messaging conferences
24.2473GPPMessaging service using the IP Multimedia (IM) Core Network (CN) subsystemRelease 17Stage 3TS
A.5.1 User connecting into a messaging conference
Figure A.5.1-1: User connecting into a messaging conference – network MRFC/AS is not located in user’s home network – conference URI resolved by the terminating home network
Figure A.5.1-1 shows an user calling into a messaging conference by using a conference URI. The focus of that conference is at a MRFC/AS which are located in another network. The conference URI in this example cannot be resolved by the originating home network
The details of the flows are as follows:
1. INVITE request (UE to P-CSCF) – see example in table A.5.1-1
A UE wants to join a messaging conference. For this purpose the UE is aware of the related conference URI that was obtained by means outside the present document (e.g. via other protocols, such as http).
The originating UE creates a local MSRP URL, which can be used for communication for the messaging conference. It builds a SDP Offer containing the generated MSRP URL and assigns a local port number for the MSRP communication.
The UE sends the INVITE request to the P-CSCF.
Table A.5.1-1: INVITE request (UE to P-CSCF)
INVITE sip:conference1@home2.net SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 70
Route: <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>, <sip:orig@scscf1.home1.net;lr>
P-Preferred-Identity: "John Doe" <sip:user1_public1@home1.net>
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11
Privacy: none
From: <sip:user1_public1@home1.net>; tag=171828
To: <sip:conference1@home2.net>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 INVITE
Require: sec-agree
Proxy-Require: sec-agree
Supported: gruu
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531
Contact: <sip: user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 ;comp=sigcomp>
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY
Accept:application/sdp, application/3gpp-ims+xml
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=message 2855 TCP/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrp://[5555::aaa:bbb:ccc:ddd]:2855/s111271;tcp
a=max-size:131072
a=msrp-cema
a=setup:active
SDP The SDP contains a set of content types supported by UE#1 and desired by the user at UE#1 for this session in the accept-types attribute and indicates the maximum size message that can be received by UE#1 in the max-size attribute.
2. 100 (Trying) response (P-CSCF to UE) – see example in table A.5.1-2
The P-CSCF responds to the INVITE request (1) with a 100 (Trying) response provisional response.
Table A.5.1-2: 100 (Trying) response (P-CSCF to UE)
SIP/2.0 100 (Trying) response
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq:
Content-Length: 0
3. INVITE request (P-CSCF to S-CSCF) – see example in table A.5.1-3
The P-CSCF forwards the INVITE request to the S-CSCF.
Table A.5.1-3: INVITE request (P-CSCF to S-CSCF)
INVITE sip:conference1@home2.net SIP/2.0
Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 69
Route: <sip:orig@scscf1.home1.net;lr>
Record-Route: <sip:pcscf1.visited1.net;lr>
P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>
P-Access-Network-Info:
P-Charging-Vector: ####
Privacy:
From:
To:
Call-ID:
Cseq:
Supported:
Contact:
Allow:
Accept:
Content-Type:
Content-Length: (…)
v=
o=
s=
c=
t=
m=
a=
4. 100 (Trying) response (S-CSCF to P-CSCF) – see example in table A.5.1-4
The S-CSCF responds to the INVITE request (3) with a 100 (Trying) response provisional response.
Table A.5.1-4: 100 (Trying) response (S-CSCF to P-CSCF)
SIP/2.0 100 (Trying) response
Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq:
Content-Length: 0
5. Evaluation of initial filter criteria
The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria.
6. INVITE request (S-CSCF to I-CSCF) – see example in table A.5.1-6
The S-CSCF performs an analysis of the destination address, and determines the network operator to whom the destination subscriber belongs. Since the originating operator does not desire to keep their internal configuration hidden, the S-CSCF forwards the INVITE request directly to the I-CSCF in the destination network.
As the S-CSCF does not know whether the I-CSCF at home2.net is a loose router or not, it does not introduce a Route header.
Table A.5.1-6: INVITE request (S-CSCF to I-CSCF)
INVITE sip:conference1@home2.net SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 68
Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>
P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>, <tel:+358-50-4821437>
P-Charging-Vector: ####
Privacy:
From:
To:
Call-ID:
Cseq:
Supported:
Contact:
Allow:
Accept:
Content-Type:
Content-Length: (…)
v=
o=
s=
c=
t=
m=
a=
7. 100 (Trying) response (I-CSCF to S-CSCF) – see example in table A.5.1-7 (related to table A.5.1-6)
The I-CSCF responds to the INVITE request (6) with a 100 (Trying) response provisional response.
Table A.5.1-7: 100 (Trying) response (I-CSCF to S-CSCF)
SIP/2.0 100 (Trying) response
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq:
Content-Length: 0
8. Public service identity (PSI) location query
The I-CSCF sends a query to the HSS to find out the MRFC/AS at which the conference has been created. The HSS responds with the address of the MRFC/AS at which the conference is hosted. The HSS responds with the address of the MRFC/AS.
For detailed message flows see [5].
9. INVITE request (I-CSCF to MRFC/AS) – see example in table A.5.1-9
I-CSCF forwards the INVITE request to the MRFC/AS that was resolved during the PSI location query (8). The I-CSCF does not re-write the Request URI.
Table A.5.1-9: INVITE request (I-CSCF to MRFC/AS)
INVITE sip:conference1@home2.net SIP/2.0
Via: SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 67
Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>
P-Asserted-Identity:
P-Charging-Vector: ####
Privacy:
From:
To:
Call-ID:
Cseq:
Supported:
Contact:
Allow:
Accept:
Content-Type:
Content-Length: (…)
v=
o=
s=
c=
t=
m=
a=
10. 100 (Trying) response (MRFC/AS to I-CSCF) – see example in table A.5.1-10 (related to table A.5.1-9)
The MRFC/AS responds to the INVITE request (9) with a 100 (Trying) response provisional response.
Table A.5.1-10: 100 (Trying) response (MRFC/AS to I-CSCF)
SIP/2.0 100 (Trying) response
Via: SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq:
Content-Length: 0
11. H.248 interaction to create conference connection resources for UE#1
MRFC initiates a H.248 interaction to create an connection point for UE#1 in MRFP.
12. 200 (OK) response (MRFC/AS to I-CSCF) – see example in table A.5.1-12 (related to table A.5.1-9)
The MRFC/AS sends a 200 (OK) response for the INVITE request containing SDP that indicates that the MRFC/AS has accepted the message session and listens on the MSRP TCP port returned in the path attribute in the answer for a TCP SETUP from the originating UE. The MRFC/AS sends a 200 (OK) response final response to the INVITE request (9) to the I-CSCF.
Table A.5.1-12: 200 (OK) response (MRFC/AS to I-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>
P-Asserted-Identity: "Conference Server" <sip:mrfc1.home2.net>
P-Charging-Vector: ####
P-Charging-Function-Addresses: ####
Privacy: none
From:
To: <sip:conference1@home2.net>; tag=314159
Call-ID:
CSeq:
Contact: <sip:conference1@home2.net>;isfocus
Allow-Events: conference, pending-additions
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933623 2987933623 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=message 2855 TCP/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrp://[9999:: aaa:bbb:ccc:ddd]:2855/s317122;tcp
a=max-size:32768
a=msrp-cema
a=setup:passive
SDP The SDP contains a set of offered content types supported by the MRFC/AS for this session in the accept-types attribute and indicates the maximum size message that can be received by the MRFC/AS in the max-size attribute.
13. 200 (OK) response (I-CSCF to S-CSCF) – see example in table A.5.1-13
The I-CSCF sends a 200 (OK) response final response along the signalling path back to the S-CSCF.
Table A.5.1-13: 200 (OK) response (I-CSCF to S-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route:
P-Asserted-Identity:
P-Charging-Vector: ####
Privacy:
From:
To:
Call-ID:
CSeq:
Contact:
Allow-Events:
Allow:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
a=
a=
14. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.5.1-14
The S-CSCF sends a 200 (OK) response final response along the signalling path back to the P-CSCF.
Table A.5.1-14: 200 (OK) response (S-CSCF to P-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route:
P-Asserted-Identity:
P-Charging-Vector: ####
P-Charging-Function-Addresses: ####
Privacy:
From:
To:
Call-ID:
CSeq:
Contact:
Allow-Events:
Allow:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
a=
a=
15. Authorize QoS Resources
The P-CSCF authorizes the resources necessary for this session.
16. 200 (OK) response (P-CSCF to UE) – see example in table A.5.1-16
The P-CSCF forwards the 200 (OK) response final response including the media authorisation token to the session originator.
Table A.5.1-16: 200 (OK) response (P-CSCF to UE)
SIP/2.0 200 OK
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>
P-Asserted-Identity:
Privacy:
From:
To:
Call-ID:
CSeq:
Contact:
Allow-Events:
Allow:
Content-Type:
Content-Length:
17. ACK request (UE to P-CSCF) – see example in table A.5.1-17
The UE starts the media flow for this session, and responds to the 200( OK) response (16) with an ACK request sent to the P-CSCF.
Table A.5.1-17: ACK request (UE to P-CSCF)
ACK sip:conference1@home2.net:2342 SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 70
Route: <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>, <sip:scscf1.home1.net;lr>
From: <sip:user1_public1@home1.net>; tag=171828
To: <sip:conference1@home2.net>;tag=314159
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 ACK
Content-Length: 0
18. ACK request (P-CSCF to S-CSCF) – see example in table A.5.1-18
The P-CSCF forwards the ACK request to the S-CSCF.
Table A.5.1-18: ACK request (P-CSCF to S-CSCF)
ACK sip:conference1@home2.net:2342 SIP/2.0
Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 69
Route: <sip:scscf1.home1.net;lr>
From:
To:
Call-ID:
Cseq:
Content-Length:
19. ACK request (S-CSCF to I-CSCF) – see example in table A.5.1-19
The S-CSCF performs an analysis of the destination address, and determines the network operator to whom the destination subscriber belongs. Since the originating operator does not desire to keep their internal configuration hidden, the S-CSCF forwards the ACK request directly to the I-CSCF in the destination network.
As the S-CSCF does not know whether the I-CSCF at home2.net is a loose router or not, it does not introduce a Route header.
Table A.5.1-19: ACK request (S-CSCF to I-CSCF)
ACK sip:conference1@home2.net:2342 SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 68
From:
To:
Call-ID:
Cseq:
Content-Length:
20. ACK request (I-CSCF to MRFC/AS) – see example in table A.5.1-20
I-CSCF forwards the ACK request to the MRFC/AS that was resolved during the PSI location query (8). The I-CSCF does not re-write the Request URI.
Table A.5.1-20: ACK request (I-CSCF to MRFC/AS)
ACK sip:conference1@home2.net:2342 SIP/2.0
Via: SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 67
From:
To:
Call-ID:
Cseq:
Content-Length:
21. Reserve IP-CAN bearer for media
The UE reserves an IP-CAN bearer for the message session media component.
22. TCP setup
Originating UE establishes a TCP connection using the IP-CAN bearers established in step 21to the host address and port as specified in the MSRP URL received in the SDP Answer from MRFC/AS.
23. MSRP SEND request (UE to MRFP) – see example in table A.5.1-23
The originating UE sends the first message over the MSRP session with an MSRP SEND request using the established TCP connection.
Table A.5.1-23: MSRP SEND request (UE to MRFP)
MSRP a97ghjut SEND
To-path:msrp://[9999::ccc:aaa:bbb:ddd]:2855/s317122;tcp
From-path:msrp://[5555::aaa:bbb:ccc:ddd]:2855/s111271;tcp
Message-ID: 9972
Byte-Range: 1-77/77
Content-Type: "text/plain"
those are my principles. If you don’t like them I have others – Groucho Marx.
——-a97ghjut$
To-path: The sender’s remote path
From-path: The sender’s local URL
Message-ID: A unique message ID for MSRP message.
Byte-Range: The Byte Range for this message.
Content-Type: The format of the body of the request.
24. MSRP 200 (OK) response (MRFP to UE) – see example in table A.5.1-24
The MRFP acknowledges the reception of the MSRP SEND request with an MSRP 200 (OK) response using the established TCP connection.
Table A.5.1-24: MSRP 200 (OK) response (MRFP to UE)
MSRP a97ghjut 200 OK
To-path:msrp://[9999::ccc:aaa:bbb:ddd]:2855/s317122;tcp
From-path:msrp://[5555::aaa:bbb:ccc:ddd]:2855/s111271;tcp
——-a97ghjut$
A.5.2 MRFC/AS invites a user to a messaging conference
Figure A.5.2-1 shows an MRFC/AS inviting a user to a messaging conference. The invitation is sent as a result of user1@home1.net sending a REFER request to the MRFC/AS. The MRFC/AS is located in a different network than user’s S-CSCF. The flows for inviting a user to a conference using REFER are shown in TS 24.147 [10].
Figure A.5.2-1: MRFC/AS inviting a user to a messaging conference – MRFC/AS routes directly to I-CSCF
The details of the flows are as follows:
1. INVITE request (MRFC/AS to I-CSCF) – see example in table A.5.2-1
In this example, the MRFC/AS is capable of resolving the terminating users I-CSCF address for this request. As a result of a DNS query, it has received the address of the I-CSCF as the next hop.
The MRFC/AS invites a user to a messaging conference as it received a REFER request from another user.
The MRFC/AS creates a local MSRP URL, which can be used for communication for the messaging conference. It builds a SDP Offer containing the generated MSRP URL and assigns a local port number for the MSRP communication.
Table A.5.2-1: INVITE request (MRFC/AS to I-CSCF)
INVITE sip:user2_public1@home2.net SIP/2.0
Via: SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846
Max-Forwards: 70
P-Asserted-Identity: <sip:conference1@mrfc1.home1.net>
P-Charging-Vector: ####
Privacy: none
From: <sip:conference1@mrfc1.home1.net>;tag=171828
To: <sip:user2_public1@home2.net>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 INVITE
Referred-By: <sip:user1_public1@home1.net>
Contact: <sip:conference1@mrfc1.home1.net>;isfocus
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH
Allow-Events: conference, pending-additions
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP6 5555::abc:def:abc:def
s=-
c=IN IP6 5555::abc:def:abc:def
t=0 0
m=message 2855 TCP/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrp://[5555::abc:def:abc:def]:2855/s111271;tcp
a=max-size:32768
a=msrp-cema
a=setup:active
SDP The SDP contains a set of content types supported by the MRFC/AS for this session in the accept-types attribute and indicates the maximum size message that can be received by the MRFC/AS in the max-size attribute.
2. 100 (Trying) response (I-CSCF to MRFC/AS) – see example in table A.5.2-2
The I-CSCF responds to the INVITE request with a 100 (Trying) provisional response.
Table A.5.2-2: 100 (Trying) response (I-CSCF to MRFC/AS)
SIP/2.0 100 Trying
Via: SIP/2.0/UDP conference1@mrfc1.home1.net;branch=z9hG4bK23273846
From:
To:
Call-ID:
CSeq:
Content-Length: 0
3. Cx: User Location Query procedure
The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the address of the current S-CSCF for the terminating subscriber.
For detailed message flows see 3GPP TS 29.228[11].
4. INVITE request (I-CSCF to S-CSCF) – see example in table A.5.2-4
The INVITE request is forwarded to the S-CSCF.
Table A.5.2-4: INVITE request (I-CSCF to S-CSCF)
INVITE sip:user2_public1@home2.net SIP/2.0
Via: SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK241d17.2, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846
Max-Forwards: 69
P-Asserted-Identity:
P-Charging-Vector:
Privacy:
From:
To:
Call-ID:
Cseq:
Referred-By:
Contact:
Allow:
Allow-Events:
Content-Type:
Content-Length: (…)
v=
o=
s=
c=
t=
m=
a=
a=
a=
5. 100 (Trying) response (S-CSCF to I-CSCF) – see example in table A.5.2-5
The S-CSCF responds to the INVITE request (3) with a 100 (Trying) provisional response.
Table A.5.2-5: 100 (Trying) response (S-CSCF to I-CSCF)
SIP/2.0 100 Trying
Via: SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846
From:
To:
Call-ID:
CSeq:
Content-Length: 0
6. Evaluation of initial filter criteria
The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria.
7. INVITE request (S-CSCF to P-CSCF) – see example in table A.5.2-7
S-CSCF remembers (from registration procedures) the contact address of UE#2 and determines the P-CSCF assigned for UE#2 and routes message there.
Table A.5.2-7: INVITE request (S-CSCF to P-CSCF)
INVITE sip:[5555::eee:fff:aaa:bbb]:8805;comp=sigcomp SIP/2.0
Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK241d17.2, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846
Max-Forwards: 68
Record-Route: <sip:scscf1.home1.net;lr>
P-Asserted-Identity:
P-Charging-Vector: ####
Privacy:
From:
To:
Call-ID:
Cseq:
Referred-By:
Contact:
Allow:
Allow-Events:
P-Called-Party-ID: <sip:user2_public1@home2.net>
Content-Type:
Content-Length: (…)
v=
o=
s=
c=
t=
m=
a=
a=
a=
8. 100 (Trying) response (P-CSCF to S-CSCF) – see example in table A.5.2-8
The P-CSCF responds to the INVITE request (6) with a 100 (Trying) provisional response.
Table A.5.2-8: 100 (Trying) response (P-CSCF to S-CSCF)
SIP/2.0 100 Trying
Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK241d17.2, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846
From:
To:
Call-ID:
CSeq:
Content-Length: 0
9. Authorize QoS resources
The P-CSCF authorizes the resources necessary for this session.
10. INVITE request (P-CSCF to UE#2) – see example in table A.5.2-10
P-CSCF forwards the request to UE#2 including the Media Authorisation token.
Table A.5.2-10: INVITE request (P-CSCF to UE#2)
INVITE sip:[5555::eee:fff:aaa:bbb]:8805;comp=sigcomp SIP/2.0
Via: SIP/2.0/UDP pcscf2.visited2.net:5088;comp=sigcomp;branch=z9hG4bK240f34.1 SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK241d17.2, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846
Max-Forwards: 67
Record-Route: <sip:pcscf2.visited2.net:5088;lr;comp=sigcomp>, <sip:scscf2.home2.net;lr>
P-Asserted-Identity:
Privacy:
From:
To:
Call-ID:
Cseq:
Referred-By:
Contact:
Allow:
Allow-Events:
P-Called-Party-ID:
Content-Type:
Content-Length: (…)
v=
o=
s=
c=
t=
m=
a=
a=
a=
11. 100 (Trying) response (UE#2 to P-CSCF) – see example in table A.5.2-11
UE#2 responds to the INVITE request (10) with a 100 (Trying) provisional response.
Table A.5.2-11: 100 (Trying) response (UE#2 to P-CSCF)
SIP/2.0 100 Trying
Via: SIP/2.0/UDP pcscf2.visited2.net:5088;comp=sigcomp;branch=z9hG4bK240f34.1 SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK241d17.2, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846
From:
To:
Call-ID:
CSeq:
Content-Length: 0
12. Resource reservation
After determining the media streams, UE#2 initiates the reservation procedures for the resources needed for this session.
13. 200 (OK) response (UE#2 to P-CSCF) – see example in table A.5.2-13 (related to table A.5.2-10)
After reserving an IP-CAN bearer for the message session media component the receipt of the MSRP 200 (OK) response to the MSRP VISIT request, the terminating UE#2 sends a 200 (OK) response for the INVITE request containing SDP that indicates that UE#2 has successfully visited AS#2, accepted the message session and listens on the MSRP TCP port returned in the path attribute in the answer for a TCP SETUP from the MRFC/AS.
Table A.5.2-13: 200 (OK) response (UE#2 to P-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP pcscf2.visited2.net:5088;comp=sigcomp;branch=z9hG4bK240f34.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK241d17.2, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846
Record-Route: <sip:pcscf2.visited2.net:5088;lr;comp=sigcomp>, <sip:scscf2.home2.net;lr>
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11
Privacy: none
From:
To: <sip:user2_public1@home2.net>; tag=314159
Call-ID:
CSeq: 127 INVITE
Supported: gruu
Contact: <sip: user2_public1@home2.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74 ;comp=sigcomp>
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933623 2987933623 IN IP6 5555::eee:fff:aaa:bbb
s=-
c=IN IP6 5555::eee:fff:aaa:bbb
t=0 0
m=message 2855 TCP/MSRP *
a=accept-types:text/plain text/html message/cpim
a=path:msrp://[5555::eee:fff:aaa:bbb]:2855/s417121;tcp
a=max-size:65536
a=msrp-cema
a=setup:passive
SDP The SDP contains a set of offered content types supported by UE#2 and desired by the user at UE#2 for this session in the accept-types attribute and indicates the maximum size message that can be received by UE#2 in the max-size attribute.
14. 200 (OK) response (P-CSCF to S-CSCF) – see example in table A.5.2-14
The P-CSCF forwards the 200 (OK) response to the S-CSCF.
Table A.5.2-14: 200 (OK) response (P-CSCF to S-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK241d17.2, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846
Record-Route: <sip:pcscf2.visited2.net;lr>, <sip:scscf2.home2.net;lr>
P-Asserted-Identity: "John Smith" <sip:user2_public1@home2.net>
P-Access-Network-Info:
P-Charging-Vector: ####
Privacy:
From:
To:
Call-ID:
CSeq:
Supported:
Contact:
Allow:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
a=
a=
a=
15. 200 (OK) response (S-CSCF to I-CSCF) – see example in table A.5.2-15
The S-CSCF sends a 200 (OK) response final response along the signalling path back to I-CSCF.
Table A.5.2-15: 200 (OK) response (S-CSCF to I-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK241d17.2, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846
Record-Route:
P-Asserted-Identity: "John Smith" <sip:user2_public1@home2.net>, <tel:+1-212-555-2222>
P-Charging-Vector: ####
P-Charging-Function-Addresses: ####
Privacy:
From:
To:
Call-ID:
CSeq:
Supported:
Contact:
Allow:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
a=
a=
a=
16. 200 (OK) response (I-CSCF to MRFC/AS) – see example in table A.5.2-16
The I-CSCF forwards the 200 (OK) response final response to the session originator.
Table A.5.2-16: 200 (OK) response (I-CSCF to MRFC/AS)
SIP/2.0 200 OK
Via: SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846
Record-Route:
P-Asserted-Identity:
Privacy:
From:
To:
Call-ID:
CSeq:
Supported:
Contact:
Allow:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
a=
a=
a=
17. ACK request (MRFC/AS to S-CSCF) – see example in table A.5.2-17
The MRFC/AS responds to the 200 (OK) response (16) with an ACK request sent to the S-CSCF.
Table A.5.2-17: ACK request (MRFC/AS to S-CSCF)
ACK sip:user2_public1@home2.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74 ;comp=sigcomp SIP/2.0
Via: SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846
Max-Forwards: 70
Route: <sip:scscf2.home2.net;lr>, <sip:pcscf2.visited2.net;lr>
From: <sip:conference1@mrfc1.home1.net>; tag=171828
To: <sip:user2_public1@home2.net>;tag=314159
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 ACK
Content-Length: 0
18. ACK request (S-CSCF to P-CSCF) – see example in table A.5.2-18
The S-CSCF forwards the ACK request to the P-CSCF.
Table A.5.2-18: ACK request (S-CSCF to P-CSCF)
ACK sip:[5555::eee:fff:aaa:bbb]:8805;comp=sigcomp SIP/2.0
Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846
Max-Forwards: 69
Route: <sip:pcscf2.visited2.net;lr>
From:
To:
Call-ID:
Cseq:
Content-Length:
19. ACK request (P-CSCF to UE#2) – see example in table A.5.2-19
The P-CSCF forwards the ACK request to the UE#2.
Table A.5.2-19: ACK request (P-CSCF to UE#2)
ACK sip:[5555::eee:fff:aaa:bbb]:8805;comp=sigcomp SIP/2.0
Via: SIP/2.0/UDP pcscf2.visited2.net:5088;comp=sigcomp;branch=z9hG4bK240f34.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846
Max-Forwards: 68
From:
To:
Call-ID:
Cseq:
Content-Length:
20. H.248 interaction to create conference connection resources for UE#2
MRFC initiates a H.248 interaction to create an connection point for UE#2 in MRFP.
21. TCP setup
MRFP establishes a TCP connection using the IP-CAN bearers established in step 12 to the host address and port as specified in the MSRP URL received in the SDP Answer UE#2.
22. MSRP SEND request (MRFP to UE#2) – see example in table A.5.2-22
The MRFP sends the first message over the MSRP session with an MSRP SEND request using the established TCP connection.
Table A.5.2-22: MSRP SEND request (MRFP to UE#2)
MSRP y56hkseg SEND
To-path:msrp://[5555::eee:fff:aaa:bbb]:2855/s417121;tcp
From-path:msrp://[5555::abc:def:abc:def]:2855/s111271;tcp
Message-ID: 10568
Byte-Range: 1-89/89
Content-Type: "text/plain"
I will never be a member of a club that accepts people like me as members – Groucho Marx.
——-y56hkseg$
To-path: The sender’s remote path
From-path: The sender’s local URL
Message-ID: A unique message ID for MSRP message.
Byte-Range: The Byte Range for this message.
Content-Type: The format of the body of the request.
23. MSRP 200 (OK) response (UE#2 to MRFP) – see example in table A.5.2-23
The terminating UE acknowledges the reception of the MSRP SEND request with an MSRP 200 (OK) response using the established TCP connection.
Table A.5.2-23: MSRP 200 (OK) response (UE#2 to MRFP)
MSRP y56hkseg 200 OK
To-path:msrp://[5555::eee:fff:aaa:bbb]:2855/s417121;tcp
From-path:msrp://[5555::abc:def:abc:def]:2855/s111271;tcp
——-y56hkseg$
Annex B (informative):
Change history
Change history |
|||||||
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Subject/Comment |
Old |
New |
2003-06 |
Version 0.0.1: Initial version for discussion |
0.0.1 |
|||||
2003-06 |
CN#31 |
Version 0.0.2: Title and text changed in order to reflect that Messaging is a service. |
N1-031123 |
N1-031281 |
|||
2003-09 |
Version 0.1.0: Title changed |
0.0.2 |
0.1.0 |
||||
2003-12 |
Version 0.2.0: Incorporated the following CRs as approved at CN#32 meeting: N1-031676: Message Sessions in IMS – Call Flow N1-031677: Immediate Messaging – Call Flow reference to 24.228 N1-031722: Message Sessions in IMS – Text (created Annex B) N1-031723: Immediate Messaging – Text Additionally the editor took the freedom to change the heading formats in clause B.5. Also the title <void> of clause B.5 was replaced with the title of clause 5 in the main part of the text and clauses B.5.1 and B.5.2 were added (both <void>). |
0.1.0 |
0.2.0 |
||||
2003-12 |
Version 0.2.1: Including minor issues that were left out by mistake when creating version 0.2.0 |
0.2.0 |
0.2.1 |
||||
2004-01 |
Version 0.3.0: Incorporated the following CRs as approved at CN#32bis meeting: N1-040151 – Message Session in IMS N1-040189 – Deletion of imported and unused Definitions N1-040197 – UE to UE message session flow N1-040198 – Message Session Initiation – mobile originating case N1-040199 – Message Session Initiation – mobile terminating case N1-040200 – Use of MESSAGE versus MSRP |
0.2.1 |
0.3.0 |
||||
2004-01 |
Version 0.3.1: Including N1-040200, that was left out (although listed) by mistake when creating version 0.3.0 |
0.3.0 |
0.3.1 |
||||
2004-02 |
Version 0.4.0: Incorporated the following CRs as approved at CN1#33 meeting: – N1-040261 – Update of Scope – N1-040262 – Correction of Flows – N1-040280 – Editorial Changes – N1-040306 – Corections to Annex A.4.3 – N1-040307 – Corrections to Annex B – N1-040426 – SDP for session-based messaging – N1-040429 – Corrections to Annex A.1 – A.4.2 – N1-040486 – Definition of MSRP Role for AS and MRFP – N1-040488 – Session-based Messaging with Intermediate Node Flow A.4.3 |
0.3.1 |
0.4.0 |
||||
2004-02 |
Version 0.4.1: Added clause 9.2.2, which was missing from last update. Minor editorials |
0.4.0 |
0.4.1 |
||||
2004-04 |
Version 0.5.0: Incorporated the following CRs as approved as CN1#33bis meeting: – N1-040561 – MSRP in AS – N1-040648 – Editorial changes to Annex A – N1-040738 – MSRP terminating UE hosting flow as well as minor editorial changes |
0.4.1 |
0.5.0 |
||||
2004-05 |
Version 1.0.0: Incorporated the following CRs as approved during CN1#34 meeting: – N1-041038 – Shifting Material from Annex B to main body – N1-041036 – Corrections to Message Sessions Flows – N1-041040 – Ut for Messaging – N1-040850 – Correction of signalling flow example – N1-041037 – Establishing a session with active intermediate nodes, with originating UE hosting, and without SBLP – N1-041039 – Addition of Note to 5.3.1.1 – several smaller editorial changes Note: the material was first shifted from Annex B to the main body (approved CR in N1-041038), all CRs that were written against material in Annex B were afterwards applied against the material in the main body. |
0.5.0 |
1.0.0 |
||||
2004-05 |
Version 1.0.1 produced to correct smaller editorial mistakes. |
1.0.0 |
1.0.1 |
||||
2004-06 |
Version 1.1.0 produced as outcome of CN#34bis meeting in Helsinki, Finland. Todc N1-041172 (Changes in MSRP) and smaller editorial changes incorporated. |
1.0.1 |
1.1.0 |
||||
2004-08 |
Version 1.2.0 produced as outcome CN#35 meeting in Sophia Antipolis, France. Tdoc N1-041585 (AS section) and smaller editorial changes incorporated. |
1.1.0 |
1.2.0 |
||||
2004-11 |
Version 6.0.0 produces as outcome of CN#36 meeting in Seoul, South Korea. The following documents were incorporated: N1-041714 – deletion of intro claus N1-041716 – Terminology alignment N1-041989 – Data Manipulation for IMS Messaging in Rel-6 N1-041995 – Session establishment for session-mode messaging N1-041996 – Session-based messaging conferences N1-041997 – clause 8 rework N1-041998 – general clause in participant section N1-041999 – clause 9 rework N1-042001 – Participant in immediate messaging N1-042114 – clause 10 rework N1-042115 – clause 6 rework |
1.2.0 |
2.0.0 |
||||
2004-12 |
CN-26 |
NP-040611 |
Version 2.0.0 is approved and the TS is brought under the change control. As an erroneous v6.0.0 is presented in CN-26, the first officially published version is 6.0.1. |
2.0.0 |
6.0.1 |
||
2005-03 |
CN-27 |
NP-050073 |
011 |
1 |
Corrections to Message Session Flows to align with draft-ietf-simple-message-sessions-09 |
6.0.1 |
6.1.0 |
2005-03 |
CN-27 |
NP-050073 |
008 |
1 |
Alignment between TS 23.228/ TS 22.340 and TS 24.247 for immediate messaging |
6.0.1 |
6.1.0 |
2005-03 |
CN-27 |
NP-050073 |
001 |
1 |
Resolution of references to 24.228 |
6.0.1 |
6.1.0 |
2005-03 |
CN-27 |
NP-050073 |
003 |
|
MESSAGE to unregistered user |
6.0.1 |
6.1.0 |
2005-03 |
CN-27 |
NP-050073 |
010 |
2 |
Removing CPCP from 24.247 |
6.0.1 |
6.1.0 |
2005-03 |
CN-27 |
NP-050075 |
009 |
2 |
Clarifications to TS 24.247 clause 9.3 |
6.0.1 |
6.1.0 |
2005-03 |
CN-27 |
NP-050075 |
002 |
3 |
MESSAGE to multiple recipients |
6.0.1 |
6.1.0 |
2005-03 |
CN-27 |
NP-050075 |
007 |
2 |
Alignment between TS 22.340 and on TS 24.247 for "is composing" |
6.0.1 |
6.1.0 |
2005-06 |
CP-28 |
CP-050060 |
13 |
1 |
List server – sending requests |
6.1.0 |
6.2.0 |
2005-06 |
CP-28 |
CP-050060 |
15 |
1 |
Adding of reference TS 26.241 to TS 24.247 |
6.1.0 |
6.2.0 |
2005-06 |
CP-28 |
CP-050060 |
16 |
1 |
Corrections to Message Session Flows to Align with draft-IETF-simple-message-sessions-10 |
6.1.0 |
6.2.0 |
2005-09 |
CP-29 |
CP-050359 |
17 |
Corrections to TS 24.247 to align with draft-ietf-simple-message-sessions-11 |
6.2.0 |
6.3.0 |
|
2005-12 |
CP-30 |
CP-050544 |
18 |
1 |
Call flow corrections |
6.3.0 |
6.4.0 |
2005-12 |
CP-30 |
CP-050544 |
19 |
Corrections to TS 24.247 to align with Draft-ietf-simple-message-sessions12 |
6.3.0 |
6.4.0 |
|
2006-03 |
CP-31 |
CP-060110 |
20 |
Corrections to references in TS 24.247 to align with draft-ietf-simple-message-sessions-13 and draft-ietf-sipping-uri-list-message-06 |
6.4.0 |
6.5.0 |
|
2006-09 |
CP-33 |
CP-060504 |
22 |
Removal of Editor’s notes in 24.247 |
6.5.0 |
6.6.0 |
|
2006-11 |
CP-34 |
CP-060655 |
23 |
1 |
Correction of the i-d name for Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP |
6.6.0 |
6.7.0 |
2006-11 |
CP-34 |
CP-060661 |
24 |
2 |
Addition of MSRP file transfer |
6.7.0 |
7.0.0 |
2007-03 |
CP-35 |
CP-070130 |
26 |
IETF reference corrections |
7.0.0 |
7.1.0 |
|
2007-06 |
CP-36 |
CP-070430 |
27 |
File transfer |
7.1.0 |
7.2.0 |
|
2007-12 |
CP-38 |
CP-070788 |
32 |
IETF reference updates |
7.2.0 |
7.3.0 |
|
2007-12 |
CP-38 |
CP-070810 |
29 |
Incorporation of roles relating draft-ietf-consent-framework |
7.3.0 |
8.0.0 |
|
2008-03 |
CP-39 |
CP-080140 |
0033 |
1 |
Messaging references |
8.0.0 |
8.1.0 |
2008-12 |
CP-42 |
CP-080854 |
0035 |
Addition of media control for session-based messaging |
8.1.0 |
8.2.0 |
|
2008-12 |
CP-42 |
CP-080841 |
0038 |
Reference updates (release 6 ietf dependencies) |
8.1.0 |
8.2.0 |
|
2008-12 |
CP-42 |
CP-080846 |
0042 |
1 |
Corrections of reference and flows in 24.247 |
8.1.0 |
8.2.0 |
2008-12 |
CP-42 |
Editorial cleanup by MCC |
8.1.0 |
8.2.0 |
|||
2009-06 |
CP-44 |
CP-090424 |
0044 |
1 |
Alternative connection model for MSRP |
8.2.0 |
8.3.0 |
2009-12 |
CP-46 |
Upgrade to Rel-9 |
8.3.0 |
9.0.0 |
|||
2010-06 |
CP-48 |
CP-100351 |
0046 |
1 |
MSRP allignment |
9.0.0 |
9.1.0 |
2010-12 |
CP-50 |
CP-100726 |
0050 |
1 |
Inclusion of file transfer attributes |
9.1.0 |
9.2.0 |
2010-12 |
CP-50 |
CP-100874 |
0052 |
2 |
Reference update: draft-ietf-simple-msrp-sessmatch & draft-ietf-simple-msrp-acm |
9.1.0 |
9.2.0 |
2011-03 |
CP-51 |
CP-110172 |
0054 |
Reference update: draft-ietf-simple-msrp-sessmatch & draft-ietf-simple-msrp-acm |
9.2.0 |
9.3.0 |
|
2011-03 |
CP-51 |
Upgrade to Rel-10 |
9.3.0 |
10.0.0 |
|||
2011-06 |
CP-52 |
CP-110454 |
0057 |
Reference update: RFC 6135 |
10.0.0 |
10.1.0 |
|
2011-09 |
CP-53 |
CP-110662 |
0060 |
1 |
Reference update: draft-ietf-simple-msrp-sessmatch |
10.1.0 |
10.2.0 |
2011-12 |
CP-54 |
CP-110864 |
0066 |
1 |
Reference update: draft-ietf-simple-msrp-cema |
10.2.0 |
10.3.0 |
2011-12 |
CP-54 |
CP-110881 |
0063 |
1 |
Correction of charging headers |
10.3.0 |
11.0.0 |
2012-06 |
CP-57 |
CP-120573 |
0070 |
1 |
Reference update: draft-ietf-simple-msrp-cema |
11.0.0 |
11.1.0 |
2012-12 |
CP-58 |
CP-120793 |
0071 |
1 |
Corrections to references and editorial errors |
11.1.0 |
11.2.0 |
2012-12 |
CP-58 |
CP-120781 |
0075 |
Reference update: RFC 6714 |
11.1.0 |
11.2.0 |
|
2012-12 |
CP-58 |
CP-120781 |
0079 |
1 |
Procedure update: RFC 6714 |
11.1.0 |
11.2.0 |
2013-12 |
CP-62 |
CP-130763 |
0080 |
1 |
MSRP-CEMA and privacy |
11.2.0 |
12.0.0 |
2015-12 |
CP-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 |
CT75 |
Upgrade to Rel-14 |
14.0.0 |
||||
2018-06 |
SA-80 |
– |
– |
– |
Update to Rel-15 version (MCC) |
15.0.0 |
|
2020-07 |
SA-88e |
– |
– |
– |
Update to Rel-16 version (MCC) |
16.0.0 |
|
2022-03 |
CT-95e |
– |
– |
– |
– |
Update to Rel-17 version (MCC) |
17.0.0 |