A.5 Flows demonstrating session-based messaging conferences

24.2473GPPMessaging service using the IP Multimedia (IM) Core Network (CN) subsystemRelease 17Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

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: (…)

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: (…)

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: (…)

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

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

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:

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:

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

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: (…)

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: (…)

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: (…)

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

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:

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:

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:

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