7.13 RCS
33.1283GPPProtocol and procedures for Lawful Interception (LI)Release 18SecurityStage 3TS
7.13.1 Provisioning over LI_X1
7.13.1.1 General
If the warrant is for IRI only, the IRI-POI and IRI-TF in the RCS Servers and the IRI-POI in the HTTP Content Server and the S-CSCF shall be provisioned in accordance with clause 7.13.1.2.
If the warrant is for IRI and CC, then the IRI-POI, IRI-TF, CC-POI and CC-TF in the RCS Servers defined in TS 33.127 [5] clause 7.13.2.1 (see RCS definition in GSMA RCC.07 [78]) and the IRI-POI and the CC-POI in the HTTP Content Server and S-CSCF shall be provisioned in accordance with clause 7.13.1.2.
In both cases, the MDF2 shall be provisioned in accordance with clause 7.13.1.3, and the MDF3 shall be provisioned in accordance with clause 7.13.1.4.
The POIs in the HTTP content server may be provisioned directly by the LIPF as described in clause 7.13.1.2. or may be triggered by the TFs in the RCS Server as described in clause 7.13.2.
7.13.1.2 Provisioning of the POIs and TFs in the RCS Server and the POIs in the HTTP Content Server and S-CSCF by the LIPF
The IRI-POI. CC-POI. IRI-TF and CC-TF present in the RCS Server and the IRI-POI and CC-POI in the HTTP Content Server and S-CSCF are provisioned over LI_X1 by the LIPF using the X1 protocol as described in clause 5.2.2.
The POIs and TFs in the RCS Server and the IRI-POIs in the S-CSCF shall support the following target identifier formats in the ETSI TS 103 221-1 [7] messages (or equivalent if ETSI TS 103 221-1 [7] is not used).
– IMPU.
– IMPI.
– IMEI.
– PEIIMEI.
The POIs in the HTTP Content Server shall support the following additional target identifier formats in the ETSI TS 103 221-1 [7] messages (or equivalent if ETSI TS 103 221-1 [7] is not used).
– SIPURI.
– TELURI.
– GPSIMSISDN.
– GPSINAI.
– IMSI.
– SUPIIMSI.
– SUPINAI.
– Email Address.
Table 7.13.1.2-1 shows the minimum details of the LI_X1 ActivateTask message used for provisioning the IRI-POI, CC-POI, IRI-TF and CC-TF in the RCS Servers and the IRI-POI and CC-POI in the HTTP Content Server and S-CSCF.
Table 7.13.1.2-1: ActivateTask message for the IRI-POI, CC-POI, IRI-TF and CC-TF in the RCS Servers and the IRI-POI and CC-POI in the HTTP Content Server and S-CSCF
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
XID |
XID assigned by LIPF. If the CC-TF or IRI-TF is also being tasked for the same interception, the same XID shall be used. The same XID shall be used at the RCS Servers, the S-CSCF and the HTTP Content Server for the same interception. |
M |
|
TargetIdentifiers |
One or more of the target identifiers listed in the paragraphs above. |
M |
|
DeliveryType |
Set to “X2Only”, “X3Only” or “X2andX3” as needed to meet the requirements of the warrant. (NOTE: "X2Only" for IRI-POI, IRI-TF and "X3Only" for CC-TF and CC-POI can also be also be used). |
M |
|
ListOfDIDs |
Delivery endpoints of LI_X2 or LI_X3. These delivery endpoints shall be configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to first use. |
M |
|
ListOfServiceTypes |
Shall be included when the task should only intercept specific CSP service types as described in clause 5.2.4. This parameter is defined in ETSI TS 103 221-1 [7], clause 6.2.1.2, table 4. |
C |
7.13.1.3 Provisioning of the MDF2
The MDF2 listed as the delivery endpoint for xIRI generated by the IRI-POI in the RCS Servers, the IRI-POI in the HTTP Content Server, or the IRI-POI in the S-CSCF shall be provisioned over LI_X1 by the LIPF using the X1 protocol as described in clause 5.2.2. Table 7.13.1.3-1 shows the minimum details of the LI_X1 ActivateTask message used for provisioning the MDF2.
The MDF2 shall support the following target identifier formats in the ETSI TS 103 221-1 [7] messages (or equivalent if ETSI TS 103 221-1 [7] is not used):
– IMPU.
– IMPI.
– IMEI.
– GPSIMSISDN.
– GPSINAI.
– IMSI.
– SUPIIMSI.
– SUPINAI.
– Email Address.
Table 7.13.1.3-1: ActivateTask message for MDF2
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
XID |
Same XID used by the LIPF for provisioning the LI functions of the RCS Servers, the S-CSCF and the HTTP Content Servers for this intercept. |
M |
|
TargetIdentifiers |
One or more of the target identifiers listed in the paragraph above. |
M |
|
DeliveryType |
Set to “X2Only”, “X3Only” or “X2andX3” as needed to meet the requirements of the warrant. (Ignored by the MDF2). |
M |
|
ListOfDIDs |
Delivery endpoints of LI_HI2. These delivery endpoints shall be configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to first use. |
M |
|
ListOfMediationDetails |
Sequence of Mediation Details, see table 7.13.1.3-2. |
M |
Table 7.13.1.3-2: Mediation Details for MDF2
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
LIID |
Lawful Intercept ID associated with the task. |
M |
|
DeliveryType |
Set to "HI2Only". |
M |
|
ListOfDIDs |
Details of where to send the IRI for this LIID. Shall be included if deviation from the ListofDIDs in the ActivateTask message is necessary. If included, the ListOfDIDs in the Mediation Details shall be used instead of any delivery destinations authorised by the ListOfDIDs field in the ActivateTask Message. |
C |
|
ServiceScoping |
Shall be included to Identify the service(s) and associated service-related delivery settings for this LIID. May include more than one instance of this parameter to allow for different combinations of subparameters associated with a single LIID. This parameter is defined in ETSI TS 103 221-1 [7] Annex C table C.2. |
C |
7.13.1.4 Provisioning of the MDF3
The MDF3 listed as the delivery endpoint for the xCC generated by the CC-POI in the RCS Servers, the CC-POI in the HTTP Content Servers and the CC-POI in the S-CSCF shall be provisioned over LI_X1 by the LIPF using the X1 protocol as described in clause 5.2.2. Table 7.13.1.4-1 shows the minimum details of the LI_X1 ActivateTask message used for provisioning the MDF3.
The MDF3 shall support the following target identifier formats in the ETSI TS 103 221-1 [7] messages (or equivalent if ETSI TS 103 221-1 [7] is not used):
– IMPU.
– IMPI.
– IMEI.
– GPSIMSISDN.
– GPSINAI.
– IMSI.
– SUPIIMSI.
– SUPINAI.
– EmailAddress.
Table 7.13.1.4-1: ActivateTask message for MDF3
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
XID |
Same XID used by the LIPF for provisioning the POIs, TFs of the RCS Servers and the POIs of the HTTP Content Servers and the S-CSCF. |
M |
|
TargetIdentifiers |
One or more of the target identifiers listed in the paragraph above. |
M |
|
DeliveryType |
Set to “X2Only”, “X3Only” or “X2andX3” as needed to meet the requirements of the warrant (Ignored by the MDF3). |
M |
|
ListOfDIDs |
Delivery endpoints of LI_HI3 or LI_MDF. These delivery endpoints shall be configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to first use. |
M |
|
ListOfMediationDetails |
Sequence of Mediation Details, see table 7.13.1.4-2. |
M |
Table 7.13.1.4-2: Mediation Details for MDF3
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
LIID |
Lawful Intercept ID associated with the task. |
M |
|
DeliveryType |
Set to "HI3Only". |
M |
|
ListOfDIDs |
Details of where to send the CC for this LIID. Shall be included if deviation from the ListofDIDs in the ActivateTask message is necessary. If included, the ListOfDIDs in the Mediation Details shall be used instead of any delivery destinations authorised by the ListOfDIDs field in the ActivateTask Message. |
C |
|
ServiceScoping |
Shall be included to Identify the service(s) and associated service-related delivery settings for this LIID. May include more than one instance of this parameter to allow for different combinations of subparameters associated with a single LIID. This parameter is defined in ETSI TS 103 221-1 [7] Annex C table C.2. |
C |
7.13.2 Triggering of the IRI-POI and CC-POI in the HTTP Content Server
7.13.2.1 Triggering of the IRI-POI in the HTTP Content Server over LI_T2
7.13.2.2.1 LI_T2 interface Specifics
In order to allow the IRI-POI in the HTTP content server to detect all events related to files uploaded or downloaded by a target, the IRI-TF in the RCS Server sends a trigger to the IRI-POI present in the HTTP Content Server with the necessary information over the LI_T2 interface.
When the IRI-TF in the RCS Server detects that a file is being uploaded or downloaded by a target UE it shall send an activation message to the IRI-POI in the HTTP Content Server over the LI_T2 interface. The activation message shall contain the correlation identifiers that the IRI-POI in the HTTP Content Server shall use with the xIRI. This can be achieved by sending an ActivateTask message as defined in ETSI TS 103 221-1 [7] clause 6.2.1 with the following details.
Table 7.13.2.2-1: ActivateTask message from the IRI-TF in the RCS Server for the IRI-POI in the HTTP Content Server
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
XID |
XID assigned by LIPF. If the CC-TF or IRI-TF is also being tasked for the same interception, the same XID shall be used. The same XID shall be used at the RCS Servers, the S-CSCF and the HTTP Content Server for the same interception. |
M |
|
TargetIdentifiers |
File detection criteria as determined by the IRI-TF in the RCS Server, which enables the IRI-POI in the HTTP Content Server to isolate target files. The IRI-POI in the HTTP Content Server shall support the identifier types given in table 7.13.2.2-2. NOTE: This value is the target identifier for the IRI-POI in the HTTP Content Server and may be different from the target identifier specified in the warrant. |
M |
|
DeliveryType |
Set to "X2Only". |
M |
|
ListOfDIDs |
Delivery endpoints for LI_X2. These delivery endpoints shall be configured by the IRI-TF in the RCS Server using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to first use. |
M |
|
CorrelationID |
Correlation ID to assign to xIRI generated by the IRI-POI in the HTTP Content Server. This field is populated with the same CorrelationID the IRI-POI in the RCS Server uses for the associated xIRI. |
M |
|
ProductID |
Shall be set to the XID of the Task Object associated with the interception at the IRI-TF. This value shall be used by the IRI-POI in the HTTP Content Server to fill the XID of X2 messages. |
M |
|
ListOfServiceTypes |
Shall be included when the task should only intercept specific CSP service types as described in clause 5.2.4. This parameter is defined in ETSI TS 103 221-1 [7], clause 6.2.1.2, table 4. |
C |
Table 7.13.2.2-2: Target Identifier Types for LI_T2
|
Identifier type |
Owner |
ETSI TS 103 221-1 [7] TargetIdentifier type |
Definition |
|
RCS Content URI (See Note) |
3GPP |
TargetIdentifierExtension / RCSContentURI |
RCSContentURI (see XSD schema) |
|
NOTE: If the TargetIdentifier used is an RCS Content URI, only one RCS Content URI shall be included per ActivateTask message. |
|||
7.13.2.3 Triggering of the CC-POI in the HTTP Content Server over LI_T3
7.13.2.3.1 LI_T3 interface Specifics
To support the use-cases where the IRI-POI in the HTTP Content Server does not get the identity of the user involved in the file-transfer (and therefore, the CC-POI in the HTTP Content Server cannot perform the intereption based on the target identity provisioned by the LIPF), the CC-TF present in the RCS Server sends a trigger to the CC-POI present in the HTTP Content Server. When the CC-TF in the RCS Server detects that a file is being uploaded or downloaded by a target UE, it shall send an activation message to the CC-POI in the HTTP Content Server over the LI_T3 interface. The activation message shall contain the correlation identifiers that the CC-POI in the HTTP Content Server shall use with the xCC. This can be achieved by sending an ActivateTask message as defined in ETSI TS 103 221-1 [7] clause 6.2.1 with the following details.
Table 7.13.2.3-1: ActivateTask message from the CC-TF in the RCS Server for the CC-POI in the HTTP Content Server
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
XID |
XID assigned by LIPF. If the CC-TF or IRI-TF is also being tasked for the same interception, the same XID shall be used. The same XID shall be used at the RCS Servers, the S-CSCF and the HTTP Content Server for the same interception. |
M |
|
TargetIdentifiers |
File detection criteria as determined by the CC-TF in the RCS Server, which enables the CC-POI in the HTTP Content Server to isolate target files. The CC-POI in the HTTP Content Server shall support the identifier types given in table 7.13.2.2-2. |
M |
|
DeliveryType |
Set to “X3Only”. |
M |
|
ListOfDIDs |
Delivery endpoints for LI_X3. These delivery endpoints shall be configured by the CC-TF in the RCS Server using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to first use. |
M |
|
CorrelationID |
Correlation ID to assign to xCC generated by the CC-POI in the HTTP Content Server. This field is populated with the same CorrelationID the IRI-POI in the RCS Server uses for the associated xIRI. |
M |
|
ProductID |
Shall be set to the XID of the Task Object associated with the interception at the CC-TF. This value shall be used by the CC-POI in the HTTP Content Server to fill the XID of X3 messages. |
M |
|
ListOfServiceTypes |
Shall be included when the task should only intercept specific CSP service types as described in clause 5.2.4. This parameter is defined in ETSI TS 103 221-1 [7], clause 6.2.1.2, table 4. |
C |
7.13.3 Generation of xIRI at IRI-POI in the RCS Server over LI_X2
7.13.3.1 General
The IRI-POI present in the RCS Servers shall send xIRI over LI_X2 for the events listed in TS 33.127 [5] clause 7.13.4, the details of which are described in the following clauses.
7.13.3.2 Registration
The xIRI containing an RCSRegistration record shall be generated when the IRI-POI in the S-CSCF or in an RCS Server detects that an RCS target matching one of the RCS identifiers, provided via LI_X1 has registered, re-registered or de-registered for RCS services. Accordingly, the IRI-POI in the RCS Server generates the xIRI when the following event is detected:
– When the IRI-POI is located in the S-CSCF:
– If the S-CSCF uses third-party registrations to notify the RCS Server when a UE registers, when the S-CSCF receives a 200 OK from the RCS Server in response to a third-party SIP REGISTER request registering, re-registering or de-registering a target with the RCS Server.
– If the S-CSCF is the NF responsible for handling RCS Registrations:
– When the S-CSCF sends a 200 OK to a target in response to a SIP REGISTER request that includes any of the service feature tags listed in GSMA RCC.07 [78] clause 2.4.4.1 table 3.
– When the S-CSCF sends a 200 OK to a target in response to a SIP REGISTER request for de-registration when the service features supported by the target include any of the service features listed in GSMA RCC.07 [78] clause 2.4.4.1 table 3.
– When the IRI-POI is located in the RCS Server:
– When the RCS Server sends a 200 OK to a target in response to a SIP REGISTER request that includes any of the service feature tags listed in GSMA RCC.07 [78] clause 2.4.4.1 table 3.
– When the RCS Server sends a 200 OK to a target in response to a SIP REGISTER request for de-registration when the service features supported by the target include any of the service features listed in GSMA RCC.07 [78] clause 2.4.4.1 table 3.
7.13.3.3 RCS Message
The IRI-POI present in the RCS Server shall generate an xIRI containing an RCSMessage record when the IRI-POI present in the RCS Server detects that an RCS target has sent or received an RCS message. In this specification, an RCS message refers to any message sent or received in the context of pager mode standalone messaging, large message mode messaging, 1-to-1 chat or group chat. This xIRI is also generated when the target sends or receives a delivery notification or display notification.
Accordingly, the IRI-POI in the RCS Server shall generate the RCSMessage xIRI when it detects the following events:
– The RCS Server receives a SIP MESSAGE from the target or destined to the target, determined by the direction attribute present in the CPM Header, and:
– The "Contact" or "Accept-Contact" header includes +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.oma.cpm.msg".
– The SIP "Content-Type" header is "message/cpim".
– The RCS Server receives an MSRP packet from the target or destined to the target and:
– The content of the MSRP packet is a CPIM (Common Presence and Instant Messaging) object (see definition in IETF RFC 3862 [80]).
7.13.3.4 Session establishment
The IRI-POI present in the RCS Server shall generate an xIRI containing an RCSSessionEstablishment record when the IRI-POI in the RCS Server detects that a SIP session has been established for a large message mode standalone message delivery, a 1-to-1 chat session or a group chat session.
Accordingly, the IRI-POI in the RCS Server shall generate the RCSSessionEstablishment xIRI when it detects the following events:
– The RCS Server receives a SIP 200 OK from the target in response to a SIP INVITE sent to the target with service feature tag +g.gsma.rcs.cpm.pager-large or +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.oma.cpm.largemsg" in the SIP "Contact" header.
– The RCS Server returns a SIP 200 OK to the target in response to a SIP INVITE received from the target with service feature tag +g.gsma.rcs.cpm.pager-large or +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.oma.cpm.largemsg" in the SIP "Contact" header.
– The RCS Server receives a SIP 200 OK from the target in response to a SIP INVITE sent to the target with service feature tag +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.oma.cpm.session" in the SIP "Contact" header.
– The RCS Server returns a SIP 200 OK to the target in response to a SIP INVITE received from the target with service feature tag +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.oma.cpm.session" in the SIP "Contact" header.
– The RCS Server receives a SIP 200 OK from the target in response to a SIP INVITE sent to the target with service feature tag +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.oma.cpm.filetransfer" in the SIP "Contact" header.
– The RCS Server returns a SIP 200 OK to the target in response to a SIP INVITE received from the target with service feature tag +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.oma.cpm.filetransfer" in the SIP "Contact" header.