5 Protocol using SIP for page-mode messaging

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

5.1 Introduction

5.1.1 Sending immediate message to multiple recipients

The UE may be able to send a single immediate message to multiple recipients by including in the MESSAGE request the list of URIs (i.e., URI-list) that identify the intended recipients.

The UE shall create a MESSAGE request in accordance with 3GPP TS 24.229 [5], and it shall also include a multipart body in the MESSAGE request. The Request-URI shall be set to the SIP URI of the Application Server that implements the role of the List Server. The multipart body shall contain the body carrying the URI-list (in the XML format) whose Content-Disposition type is ‘recipient-list’, and the body that contains the immediate message payload as specified in the RFC 5365 [12].

The handling of the received response shall be in accordance with 3GPP TS 24.229 [5].

5.2 Functional entities

5.2.1 User Equipment (UE)

For the purpose of page-mode messaging, the UE shall implement the role of a Participant as described in clause 5.3.1.

5.2.2 Application Server (AS)

As the functional split for the purposes of page mode messaging between the AS and the MRFC is out of scope of the present document, the procedures are described for a combined AS and MRFC. The AS and MRFC may either be collocated, or interoperate using a proprietary protocol and a proprietary functional split.

For the purpose of page-mode messaging, an Application Server may implement the role of a List Server as described in clause 5.3.3. An Application Server may implement the role of a Participant as described in clause 5.3.1

5.2.3 Media Resource Function Controller (MRFC)

As the function split for the purposes of page mode messaging between the MRFC and the AS is out of scope of the present document, the procedures for the MRFC are described together with those for the AS in clause 5.2.2.

5.3 Role

5.3.1 Participant

5.3.1.1 General

For the purpose of page-mode messaging a participant will send a page-mode message using a SIP MESSAGE request as defined in RFC 3428 [8] to another participant.

5.3.1.2 Sending of an immediate message

When sending a page-mode message to another participant or to a list server, the participant shall construct and send a MESSAGE request in accordance with RFC 3428 [8] and clause 5.1.2A.1 of 3GPP TS 24.229 [5].

The participant may include in a MESSAGE request an isComposing status message as defined in RFC 3994 [13].

The participant shall stop transmitting isComposing status messages if the participant receives a 415 (Unsupported Media Type) status code in a response to a MESSAGE request containing the status indication.

The Request URI shall either be:

– the URI of the other participant; or

– a PSI identifying a group.

5.3.1.3 Receiving an immediate message

Upon receipt of a MESSAGE request, the participant shall perform the procedures as described in RFC 3428 [8] and clause 5.1.2A.2 of 3GPP TS 24.229 [5].

NOTE: A MESSAGE request can be used for applications other than immediate messaging (e.g. 3GPP TS 23.228 [6] clause 5.4.9), and the handling of received MESSAGE requests for such applications is outside the scope of this specification.

5.3.1.4 Consent to list server distribution

A participant capable of receiving message requests should support the requirements of a recipient defined in RFC 5360  [16].

5.3.2 Application Server (AS)

5.3.2.1 Receiving an immediate message for unregistered Public User Identity

When an immediate message destined for an unregistered Public User Identity arrives at the user’s home network, the I-CSCF and S-CSCF perform the actions as specified in 3GPP TS 24.229 [5].

If the Public User Identity has services related to unregistered state activated (i.e., hold the MESSAGE request temporarily in the network.), the MESSAGE request will be routed to an AS, which processes the request further on. The AS may then hold the MESSAGE request and deliver the MESSAGE request when either the UE becomes reachable or the validity of the message expires as specified in RFC 3428 [8].

5.3.3 List Server

5.3.3.1 List server originating case

In addition to the procedure specified in clause 5.3.3.2 the list server shall follow the procedures of 3GPP TS 24.229 [5] clause 5.7.3 when acting as an originating UA.

The PSI is used to address a predefined list of URIs.

The list server shall send a MESSAGE request to each of the entries in the predefined URI list. For each of MESSAGE requests the list server shall populate the header fields as follows:

a) the Request URI header fields set to the URI of one of the entries of the predefined URI list;

b) the From header field set to the same value as the From header field (excluding the "tag" parameter) that was received in the incoming MESSAGE request;

c) the To header fields set to the same value as the To header field that was received in the incoming MESSAGE request;

d) the P-Charging-Vector header that includes:

1) the value of the icid parameter if available; and

2) the value of the orig-ioi parameter if available;

e) the P-Charging-Function-Addresses header containing the values received in the incoming MESSAGE request or, if the P-Charging-Function-Addresses header was not received in the incoming MESSAGE request, indicate the values applicable for the list server in the P-Charging-Function-Addresses header; and

f) the P-Asserted Identity header and Privacy header containing the values received in the MESSAGE request;

The handling of the 200 (OK) response shall be in accordance with 3GPP TS 24.229 [5].

5.3.3.2 List server terminating case

Upon receipt of a MESSAGE request that includes a PSI in the request URI the list server shall:

1) check if the PSI is allocated to a predefined URI list and rejects the request in accordance with RFC 3261 [7] if it is not allocated. The following actions in this clause shall only be performed if the distribution list URI is allocated;

2) verify the identity of the user as described in clause 5.7.1.4 of 3GPP TS 24.229 [5] and authorize the request as described in clause 5.7.1.5 of 3GPP TS 24.229 [5]. The following actions in this clause shall only be performed if the request can be authorized;

3) create a 202 (Accepted) response. The response shall be in accordance with the procedures of 3GPP TS 24.229 [5] clause 5.7.1.2 in relation to the contents of the P-Charging-Function-Addresses header and the P-Charging-Vector header; and :

a) include the P-Charging-Vector header including:

i) the value of the icid parameter as received in the MESSAGE request;

ii) the value of the orig-ioi parameter as received in the MESSAGE request; and

iii) the term-ioi parameter, indicating the network of the list server; and

b) include the P-Charging-Function-Addresses header as received in the MESSAGE request or, if the P-Charging-Function-Addresses header was not received in the MESSAGE request, indicate the values applicable for the list server in the P-Charging-Function-Addresses header; and

4) send the 202 (Accepted) response.

5.3.3.3 List Server processing the MESSAGE URI-list

Upon receiving the MESSAGE request with the URI-list included in the multipart body, the List Server shall inform the UE that it has received the MESSAGE request by returning the 202 (Accepted) response. Subsequently, the List Server shall create a MESSAGE request for each intended recipient listed in the URI-list, and it shall insert the immediate message payload into the body of each outgoing MESSAGES request.

When creating the outgoing MESSAGE requests destined for each recipient, the List Server shall follow the procedures described in the 3GPP TS 24.229 [5]. The List Server shall populate the header fields of each outgoing MESSAGE request as follows:

– the Request-URI set to the SIP URI of the intended recipient;

– the From header field set to the same value as the From header field that was received in the incoming MESSAGE request;

– the To header set to the SIP URI of the intended recipient; and

– the remaining headers set to the values as specified in 3GPP TS 24.229 [5] clause 5.7.3.

The List Server shall also compose the multipart body of the outgoing MESSAGE request as specified in the RFC 5365 [12], and included it in the outgoing MESSAGE request.

When sending the MESSAGE request to each recipient, and processing the respective responses, the List Server shall behave as specified in the 3GPP TS 24.229 [5] clause 5.7.

5.3.3.4 List server support of MESSAGE URI-lists

A list server shall support the relay requirements of RFC 5360 [16]. The list server may also support the store and forward server requirements of RFC 5360 [16].