9 Protocol using MSRP for session-mode messaging and session-mode 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

9.1 Introduction

9.2 Functional entities

9.2.1 User Equipment (UE)

9.2.1.1 General

The UE shall:

– implement the role of an MSRP sender as described in clause 9.3.1; and

– implement the role of an MSRP receiver as described in clause 9.3.2.

9.2.2 Application Server (AS)

The AS shall implement the role of a MSRP sender, as described in clause 9.3.1, and a MSRP receiver, as described in clause 9.3.2 when engaged in a session mode session between a MSRP sender and MSRP receiver.

NOTE: An AS, that is on the signalling path for the related SIP signalling, is not mandated to terminate the related MSRP.

9.2.3 Media Resource Function Processor (MRFP)

The MRFP shall implement the role of an intermediate node as described in clause 9.3.3.

The MRFP may implement the role of an MSRP sender as described in clause 9.3.1.

The MRFP may implement the role of an MSRP receiver as described in clause 9.3.2.

9.3 Role

9.3.1 MSRP sender

9.3.1.1 MSRP sender sends a message

When a MSRP sender wishes to send a message, the MSRP sender shall ensure that the message length does not exceed the SDP max-size attribute value associated with the MSRP session. Depending on the message length the message may be included in one SEND request or chunked into multiple SEND requests, in accordance with RFC 4975 [9].

The SEND request shall include a Byte-Range header. The MSRP sender shall populate the Byte-Range header fields as follows:

– the range end set to * (interruptible), to make the chunks interruptible, if the SEND request is longer than 2048 octets; and

– the total field set to the total size of the message.

The MSRP sender shall create a SEND request in accordance with RFC 4975 [9] and RFC 6135 [18], where the value of To-Path is the MSRP URI shall be set to value of path attribute received in a SDP offer or a SDP answer.

If it is possible to exchange isComposing information, the MSRP sender may include in a SEND request an isComposing status message as defined in RFC 3994 [13].

9.3.2 MSRP receiver

When a MSRP receiver receives a SEND request, the MSRP receiver shall parse the SEND request. The MSRP receiver shall either send a response including:

a) a 200 (OK) status-code , as specified in RFC 4975 [9], for the concerned SEND message if the parsing was successful; or

b) an appropriate status-code, as specified in RFC 4975 [9], for the concerned SEND message if the parsing was unsuccessful.

The MSRP receiver shall send a REPORT request if this is explicit or implicit requested in the SEND request(s) belonging to the message. It shall either be:

a) a successful REPORT request including status-code 200 (OK) if a complete message is received and the Report-Success header in the SEND request was set to "yes"; or

b) an unsuccessful REPORT request including status-code other than 200 (OK) as defined in RFC 4975 [9] if the MSRP receiver can conclude that a complete message is not received and the Report-Failure header is set to "yes" or not included. The criteria to conclude that a complete message is not received are specified in RFC 4975 [9].

9.3.3 Intermediate node

9.3.3.1 Intermediate node terminating case

When an intermediate node receives a SEND request, the intermediate node shall:

1) parse the SEND request and either send a response including:

a) a 200 (OK) status-code, as specified in RFC 4975 [9], for the concerned SEND message, if the parsing was successful; or

b) an appropriate status-code, as specified in RFC 4975 [9], for the concerned SEND message if the parsing was unsuccessful.; and

2) determine that a complete message has been received. The following actions in this clause shall only be performed if a complete message is received.

The MSRP receiver shall send a REPORT request if this is explicit or implicit requested in the SEND request(s) associated to the same message. It shall either be:

a) a successful REPORT request including status-code 200 (OK) if the intermediate node concludes that all available users on the distribution list has received the complete message or a concerned user has received the complete message and the Report-Success header in the SEND request was set to "yes"; or

b) an unsuccessful REPORT request including status-code other than 200 (OK) as defined in RFC 4975 [9] if the intermediate node conclude that a complete message has not been received or that a complete message has not been able to be delivered to all available users on the distribution list or to a particular member of the distribution list.

9.3.3.2 Intermediate node originating case

When an intermediate node wishes to send a message, the intermediate shall ensure that the message length does not exceed the SDP max-size attribute value associated with the MSRP session. Depending on the message length the message may be included in one SEND request or chunked into multiple SEND requests, in accordance with RFC 4975 [9].

The SEND request shall include a Byte-Range header. The MSRP sender shall populate the Byte-Range header fields as follows:

– the range-end field set to * (interruptible), to make the chunks interruptible, if the SEND request is longer than 2048 octets; and

– the total field set to the total size of the message.

The intermediate shall create a SEND request in accordance with RFC 4975 [9] and RFC 6135 [18] with the following clarifications: