Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 33.128  Word version:  18.7.0

Top   Top   Up   Prev   Next
0…   4…   5…   5.7…   6…   6.2.2.2A…   6.2.3…   6.2.3.2.7…   6.2.3.3…   6.2.4…   6.3…   6.3.2.2A…   6.3.3…   6.3.3.2…   6.3.3.2.4…   6.3.3.2A…   7…   7.3…   7.3.3…   7.3.3.2.21…   7.3.3.2.42…   7.3.3.2.63…   7.3.4…   7.4…   7.4.3.8…   7.5…   7.6…   7.7…   7.7.4…   7.8…   7.8.4…   7.9…   7.10…   7.10.4…   7.11…   7.12…   7.13…   7.13.3…   7.13.3.4…   7.14…   7.15…   8…   A…   D…   E…   M…
7.13.3.4 RCS Session reporting7.13.3.4.1 General7.13.3.4.2 Session establishment attempt7.13.3.4.2.1 RCSSessionEstablishmentAttempt record7.13.3.4.2.2 Large Message Mode CPM Standalone session7.13.3.4.2.3 CPM 1-to-1 Chat session establishment7.13.3.4.3 Session modification7.13.3.4.3.1 RCSSessionModification record7.13.3.4.3.2 CPM Standalone Message session modification7.13.3.4.3.3 CPM 1-to-1 Chat session modification7.13.3.4.4 Session release7.13.3.4.4.1 RCSSessionRelease record7.13.3.4.4.2 CPM Standalone Message session release7.13.3.4.4.3 CPM 1-to-1 Chat session release7.13.3.4.5 RCS session parameters7.13.3.4.5.1 Type: RCSSessionType7.13.3.4.5.2 Type: RCSSessionEndpoints7.13.3.4.5.3 Type: RCSSIPSessionMessage7.13.3.4.5.4 Type: RCSSessionLeg7.13.3.4.5.6 Type: RCSSessionResult7.13.3.4.5.7 MSRPPath7.13.3.5 Capability discovery7.13.3.5.1  RCS Capability discovery record7.13.3.6 RCS reported at the start of intercept7.13.4 Generation of IRI over LI_HI27.13.5 Redaction of unauthorised information from encapsulated RCS payloads7.13.5.1 General7.13.5.2 Redaction of location information7.13.5.2.1 General7.13.5.2.2 Redaction of location information from presence information7.13.5.2.3 Redaction of location information from CPIM messages7.13.5.3 Redaction of communications content7.13.5.3.1 General7.13.5.3.2 Redaction of text content7.13.5.3.3 Redaction of content from the Subject header field7.13.5.3.4 Redaction of content from Geolocation PUSH messages7.13.5.3.5 Redaction of URLs from file transfer messages7.13.6 Generation of xCC over LI_X37.13.7 Generation of CC over LI_HI3
...

 

7.13.3.4  RCS Session reportingp. 354

7.13.3.4.1  Generalp. 354
The IRI-POI present in the RCS Server shall generate xIRIs to report the establishment, modification and release of RCS Sessions. There are multiple types of RCS Sessions that shall be reported:
  • Standalone SIP Sessions:
  • CPM Sessions which can be broken down into:
When reporting sessions established to transfer a Large Message Mode RCS Standalone Message, the rCSSessionType parameter shall be set to "LargeMessageStandalone".
When reporting a CPM 1-to-1 Session, the rCSSessionType parameter shall be set to "1to1Chat".
Up
7.13.3.4.2  Session establishment attemptp. 355
7.13.3.4.2.1  RCSSessionEstablishmentAttempt recordp. 355
The IRI-POI in the RCS Server shall generate an RCSSessionEstablishmentAttempt record when the IRI-POI in the RCS Server detects any of the following:
  • A SIP Session has been requested to transfer a Large Message Mode CPM Standalone message to or from a target (see clause 7.13.3.4.2.2).
  • A CPM 1-to-1 Chat Session has been requested for the target's communications (see clause 7.13.3.4.2.3).
Field name Type Cardi­nality Description M/C/O
rCSTargetIdentitiesSEQUENCE OF RCSIdentity1..MAXRCS target identities. All identities associated to the target known at the POI shall be included.M
conversationIDRCSConversationID1Set to the value of the Conversion-ID header in the SIP INVITE request.M
contributionIDRCSContributionID1Set to the value of the Contribution-ID header in the SIP INVITE request.M
inReplyToContributionIDRCSContributionID0..1 InReplyTo-Contribution-ID identifying the Contribution-ID of the CPM Standalone Message, CPM File Transfer or CPM Session that is being replied to (see OMA-TS-CPM_Conversation_Function [109] clause 5.3). Shall be included if the InReplyTo-Contribution-ID header field is present for the message being reported.C
sessionReplacesRCSContributionID0..1 The Contribution-ID present in the Session-Replaces header of the SIP INVITE identifying the Contribution-ID of the CPM 1-to-1 Chat Session that is being replaced to (see OMA-TS-CPM_Conversation_Function [109] clause 5.3). Shall be included if the Session-Replaces header field is present for the message being reported.C
rCSSessionTypeRCSSessionType1Indicates the type of RCS Session.M
sessionDirectionDirection1 Shall be provided to identify the direction of the session relative to the target: "toTarget" or "fromTarget". M
rCSSIPSessionMessageRCSSIPSessionMessage1Shall contain the SIP INVITE and the leg identificaiton.M
locationLocation0..1Shall include the target's location when reporting of the target's location information is authorized and available.C
Up
7.13.3.4.2.2  Large Message Mode CPM Standalone sessionp. 355
The IRI-POI in the RCS Server shall generate the RCSSessionEstablishmentAttempt xIRI when it detects the following events:
  • The RCS Server receives a SIP INVITE sent to or from the target with a service feature tag among the feature tags listed in OMA-TS-CPM_Conv_Function [109] Table 7 indicating the Large Message Mode CPM Standalone Message or the Deferred CPM Message features for which a SIP session was not already established.
Up
7.13.3.4.2.3  CPM 1-to-1 Chat session establishmentp. 356
The IRI-POI in the RCS Server shall generate the RCSSessionEstablishmentAttempt xIRI when it detects the following events:
  • The RCS Server receives a SIP INVITE sent to or from the target with a service feature tag among the feature tags listed in OMA-TS-CPM_Conv_Function [109] Table 7 indicating the CPM Session feature for which there is not an existing CPM Session.
7.13.3.4.3  Session modificationp. 356
7.13.3.4.3.1  RCSSessionModification recordp. 356
The IRI-POI in the RCS Server shall generate an RCSSessionModification record when the IRI-POI in the RCS Server detects any of the following:
  • A request is sent to request the next leg of a SIP Session or a response is received establishing a SIP Session for the transfer of a Large Message Mode CPM Standalone message or a CPM 1-to-1 Chat Session.
  • A previously established SIP session for the transfer of a Large Message Mode CPM Standalone message to or from a target has been modified (see clause 7.13.3.4.3.2).
  • A CPM 1-to-1 Chat Session established for the target's communications has been modified (see clause 7.13.3.4.3.3).
Field name Type Cardi­nality Description M/C/O
rCSTargetIdentitiesSEQUENCE OF RCSIdentity1..MAXRCS target identities. All identities associated to the target known at the POI shall be included.M
conversationIDRCSConversationID1Set to the value of the Conversion-ID header in the original SIP INVITE request.M
contributionIDRCSContributionID1Set to the value of the Contribution-ID header in the original SIP INVITE request.M
inReplyToContributionIDRCSContributionID0..1 InReplyTo-Contribution-ID identifying the Contribution-ID of the CPM Standalone Message, CPM File Transfer or CPM Session that is being replied to (see OMA-TS-CPM_Conversation_Function [109] clause 5.3). Shall be included if the InReplyTo-Contribution-ID header field is present for the message being reported.C
sessionReplacesRCSContributionID0..1 The Contribution-ID present in the Session-Replaces header of the SIP INVITE identifying the Contribution-ID of the CPM 1-to-1 Chat Session that is being replaced to (see OMA-TS-CPM_Conversation_Function [109] clause 5.3). Shall be included if the Session-Replaces header field is present for the message being reported.C
rCSSessionTypeRCSSessionType1Indicates the type of RCSSession.M
sessionDirectionDirection1 Shall be provided to identify the direction of the session relative to the target: "toTarget" or "fromTarget". M
sessionEndpointsRCSSessionEndpoints1Indicates whether the session continues through the server or is terminated at the server.M
rCSSIPSessionMessageRCSSIPSessionMessage1Shall contain the SIP message that triggered the xIRI, an indication of whether the the establishment or removal of a leg has been attempted or completed.M
locationLocation0..1Shall include the target's location when reporting of the target's location information is authorized and available.C
Up
7.13.3.4.3.2  CPM Standalone Message session modificationp. 357
The IRI-POI in the RCS Server shall generate the RCSSessionModification xIRI when it detects the following events:
  • The RCS Server sends a SIP INVITE to or from a target with a service feature tag among the feature tags listed in OMA-TS-CPM_Conv_Function [109] Table 7 indicating the Large Message Mode CPM Standalone Message or the Deferred CPM Message features.
  • The RCS Server sends or receives SIP response within a SIP dialog where the original SIP INVITE had any service feature tag among the feature tags listed in OMA-TS-CPM_Conv_Function [109] Table 7 indicating the Large Message Mode CPM Standalone Message or the Deferred CPM Message features and at least one of the legs of the session known by the RCS Server remain.
Up
7.13.3.4.3.3  CPM 1-to-1 Chat session modificationp. 357
The IRI-POI in the RCS Server shall generate the RCSSessionModification xIRI when it detects the following events:
  • The RCS Server sends a SIP INVITE to or from a target with a service feature tag among the feature tags listed in OMA-TS-CPM_Conv_Function [109] Table 7 indicating the CPM Session feature.
  • The RCS Server sends or receives SIP response or SIP BYE within a SIP dialog where the original SIP INVITE had any service feature tag among the feature tags listed in OMA-TS-CPM_Conv_Function [109] Table 7 indicating the CPM Session feature.
Up
7.13.3.4.4  Session releasep. 357
7.13.3.4.4.1  RCSSessionRelease recordp. 357
The IRI-POI in the RCS Server shall generate an RCSSessionRelease record when the IRI-POI in the RCS Server detects any of the following:
  • A SIP Session for the transfer of a Large Message Mode CPM Standalone message to or from a target has been released (see clause 7.13.3.4.4.2).
  • A CPM 1-to-1 Chat Session established for the target's communications has been released (see clause 7.13.3.4.4.3).
Field name Type Cardi­nality Description M/C/O
rCSTargetIdentitiesSEQUENCE OF RCSIdentity1..MAXRCS target identities. All identities associated to the target known at the POI shall be included.M
conversationIDRCSConversationID1Set to the value of the Conversion-ID header in the original SIP INVITE request.M
contributionIDRCSContributionID1Set to the value of the Contribution-ID header in the original SIP INVITE request.M
rCSSessionTypeRCSSessionType1Indicates the type of RCSSession.M
sessionDirectionDirection1 Shall be provided to identify the direction of the session relative to the target: "toTarget" or "fromTarget". M
sessionEndpointsRCSSessionEndpoints1Indicates whether the session continued through the server or is terminated at the server.M
rCSSIPSessionMessageRCSSIPSessionMessage1Shall contain the SIP message that triggered the xIRI, an indication of whether the the establishment or removal of a leg has been attempted or completed.M
locationLocation0..1Shall include the target's location when reporting of the target's location information is authorized and available.C
Up
7.13.3.4.4.2  CPM Standalone Message session releasep. 358
The IRI-POI in the RCS Server shall generate the RCSSessionRelease xIRI when it detects the following events:
  • The RCS Server returns a SIP 200 OK in response to a SIP BYE sent to or from the target for a SIP session established to transfer a Large Message Mode CPM Standalone Message.
7.13.3.4.4.3  CPM 1-to-1 Chat session releasep. 358
The IRI-POI in the RCS Server shall generate the RCSSessionRelease xIRI when it detects the following events:
  • The RCS Server returns a SIP 200 OK in response to a SIP BYE sent to or from the target for the last active leg of a SIP session established for a CPM Session.
7.13.3.4.5  RCS session parametersp. 358
7.13.3.4.5.1  Type: RCSSessionTypep. 358
The RCSSessionType shall be set to indicate the type of RCS Session being reported.
Enumeration Description
largeMessageStandaloneShall be selected if the session being reported is related to a Large Message Mode CPM Standalone Message.
oneTo1Chat Shall be selected if the session being reported is a one-to-one chat session (see GSMA RCC.07 [78] clause 3.2.3).
Up
7.13.3.4.5.2  Type: RCSSessionEndpointsp. 358
The RCSSessionEndpoints shall be set to indicate whether the RCS Session is currently established between the server and the remote endpoint, between the server and the local client or from the remote endpoint to the local client.
Enumeration Description
remoteOnlyShall be selected if the session has been established only between the RCS Server and the remote endpoint.
localOnlyShall be selected if the session has been established only between the RCS Server and the local client.
localAndRemoteShall be selected if the session has been established between the local RCS Client and a remote endpoint.
Up
7.13.3.4.5.3  Type: RCSSIPSessionMessagep. 358
Field name Type Cardi­nality Description M/C/O
sessionLegRCSSessionLeg1Identifies the leg of the RCS session.M
sIPMessageIMSPayload1Contains the SIP Message.M
rCSSessionResultRCSSessionResult1Contains an indication of the resulting state of the RCS Session Leg.M
Up
7.13.3.4.5.4  Type: RCSSessionLegp. 358
The RCSSessionLeg shall be set to indicate whether the SIP Session Exchange is between the server and a remote endpoint or between the server and the local client.
Enumeration Description
remoteLegShall be selected if the exchange took place between the server and a remote endpoint.
localLegShall be selected if the exchange took place between the server and the local client.
Up
7.13.3.4.5.5Void
7.13.3.4.5.6  Type: RCSSessionResultp. 359
The RCSSessionResult shall be set to indicate whether the addition, removal or modification of the leg has been requested or completed.
Enumeration Description
newLegRequestedShall be selected if the message that triggered the event was a SIP INVITE for a new SIP Session leg.
newLegEstablishedShall be selected if the message that triggered the event was a 200 OK response to a SIP INVITE for a new SIP Session leg.
legModificationRequestedShall be selected if the message that triggered the event was a SIP INVITE for an existing SIP Session leg.
legModificationCompleteShall be selected if the message that triggered the event was a 200 OK response to a SIP INVITE for an existing SIP Session leg.
legRemovalRequestShall be selected if the message that triggered the event was a SIP BYE.
legRemovalCompleteShall be selected if the message that triggered the event was a SIP 200 OK response to a SIP BYE or an error response to a SIP INVITE.
Up
7.13.3.4.5.7  MSRPPathp. 359

7.13.3.5  Capability discoveryp. 359

7.13.3.5.1  RCS Capability discovery recordp. 359
The IRI-POI present in the RCS server shall generate an xIRI containing an RCSCapabilityDiscovery when the IRI-POI present in the RCS server detects that an RCS target has received RCS service capabilities for his contact(s) or has sent capabilities to a contact.
Accordingly, the IRI-POI in the RCS server generates the xIRI when any of the following events is detected:
  • The RCS server receives a SIP OPTIONS request sent by a target which contains the capabilities of the target in the Contact header.
  • The RCS server returns a SIP response with the response code is 200, 480, 408, 404 or 604 for a SIP OPTIONS request sent by the target.
  • The RCS server receives a SIP OPTIONS request for the target which contains the capabilities of the target's contact in the Contact header.
  • The RCS server returns a SIP response for a SIP OPTIONS request received from a target's contact.
  • The RCS server sends a SIP NOTIFY request to the target with the Event header set to "presence.winfo". The SIP NOTIFY request contains the RCS state and RCS capabilities of a target's contact.
  • The RCS server receives a SIP SUBSCRIBE request from a target's contact with the Event header set to "presence.winfo".
  • The RCS server receives a SIP PUBLISH request from the target to initially announce, update and remove RCS capabilities.
Field name Type Cardi­nality Description M/C/O
rCSTargetIdentitiesSEQUENCE OF RCSIdentity1..MAXRCS target identities. All identities associated to the target known at the POI shall be included.M
rCSTargetContactIdentitiesSEQUENCE OF RCSIdentity1..MAXRCS target's contact identities. All identities associated to the target's contact known at the POI shall be included.C
sIPMessageIMSPayload1The SIP Message may be either an OPTIONS request, or SIP OPTIONS response, or SIP SUBSCRIBE request, or SIP NOTIFY request or SIP PUBLISH requestM
directionDirection1 Shall be provided to identify the direction of the message relative to the target: "toTarget" or "fromTarget". M
locationLocation0..1Shall include the target's location when available according to the location reporting type provisioned for the task.C
Up

7.13.3.6  RCS reported at the start of interceptp. 360

7.13.4  Generation of IRI over LI_HI2p. 363

When an xIRI is received over LI_X2 from the IRI-POI in the RCS server, the MDF2 shall send the IRI message over LI_HI2 without undue delay. The IRI message shall contain a copy of the relevant record received from LI_X2. The record may be enriched by other information available at the MDF (e.g. additional location information).
The timestamp field of the ETSI TS 102 232-1 [9] PSHeader structure shall be set to the time at which the RCS server event was observed (i.e. the timestamp field of the xIRI).
Table 7.13.4-1 shows the IRI type (see ETSI TS 102 232-1 [9] clause 5.2.10) to be used for each record type.
IRI message Record type
RCSRegistrationREPORT
RCSCapabilityDiscoveryREPORT
RCSMessageREPORT
RCSSessionEstablishmentAttemptREPORT
RCSSessionModificationREPORT
RCSSessionReleaseREPORT
Up

7.13.5  Redaction of unauthorised information from encapsulated RCS payloadsp. 364

7.13.5.1  Generalp. 364

RCS consists of multiple layers of protocols, each of which may include information that, depending on the warrant, is not authorized for delivery. If the RCS implementation uses protocols other than SIP and MSRP, the modifications specified below shall be adapted as required to redact the unauthorised information and the modifications made shall be described within the IRI delivered to the LEA using the structure described in Annex M.2.2.
All of the requirements for the redaction of unauthorised information from IMS record payloads (see clause 7.12.9) shall also apply to encapsulated RCS payloads.
Up

7.13.5.2  Redaction of location informationp. 364

7.13.5.2.1  Generalp. 364
Depending on the RCS event being reported and the implementation, location information may be present in the headers of one or more protocol layers, the body of one or more protocol layers, or both.
In all cases, if content is authorised, location information present in the content portion of a user generated payload shall not be redacted.
When location is not authorised, all location information shall be redacted from the encapsulated RCS payload prior to its delivery over LI_HI2. As such, when location is not authorised, the MDF2 and, optionally, the IRI-POIs in the RCS Server, the supporting IMS elements, and any RCS file transfer elements shall be provisioned with the payload modifications detailed in the subclauses below.
Additionally, if the location present in the RCS payload is the location of the non-target party, and this information is not authorised, the location shall be redacted.
If an implementation has location information in other portions of the payload, when the location is included the appropriate modifications shall be made to the encapsulated payload in addition to those specified below prior to the delivery of the message over LI_HI2.
Up
7.13.5.2.2  Redaction of location information from presence informationp. 364
If the geopriv element of presence information is considered to be location, the Content-Type of any body part at any layer of the RCS message is "application/pidf+xml", and if the presence information contains a geopriv element, the character data of each element within each location-info element shall be overwritten with the zero character such that the length of the element does not change.
7.13.5.2.3  Redaction of location information from CPIM messagesp. 364
In some cases, the information that would normally be present in the P-Access-Network-Info or Cellular-Network-Info headers of a SIP message is sent as implementation specific headers within the CPIM headers. In this case, these headers shall be redacted as described in clause 7.12.9.2 when the delivery of P-Access-Network-Info or Cellular-Network-Info is not authorised.

7.13.5.3  Redaction of communications contentp. 365

7.13.5.3.1  Generalp. 365
In some cases portions of an encapsulated RCS payload may contain communications content. Unless otherwise specified, all communications content shall be redacted from the encapsulated payload prior to its delivery over LI_HI2. As such, the MDF2 and, optionally, the IRI-POIs in the RCS Server, the supporting IMS elements, and any RCS file transfer elements shall be provisioned with the payload modifications detailed in the subclauses below.
If an implementation has communications content in other portions of the payload, the appropriate modifications shall be made to the encapsulated payload in addition to those specified below prior to the delivery of the message over LI_HI2.
Up
7.13.5.3.2  Redaction of text contentp. 365
If the Content-Type of any body part at any layer of the RCS message is "text" or any of the subtypes of "text", the contents of that body part shall be overwritten with the space character in the original encoding such that the length of the body remains unchanged.
7.13.5.3.3  Redaction of content from the Subject header fieldp. 365
If the delivery of the content of the Subject header is unauthorised, each character of the field-value of the Subject header of any body part of any layer of the RCS message shall be replaced with a space.
7.13.5.3.4  Redaction of content from Geolocation PUSH messagesp. 365
If the delivery of Geolocation PUSH messages is unauthorised, if the Content-Type of any body part at any layer of the RCS message is "application/vnd.gsma.rcs-ft-http+xml":
  • the value of the label attribute of the data element of the rcspushlocation element shall be overwritten with the "space" character such that the length of the attribute does not change.
  • the value of the id attribute of the data element of the rcspushlocation element shall be overwritten with the "space" character such that the length of the attribute does not change.
  • the character data of each element within each location-info element shall be overwritten with the zero character such that the length of the element does not change.
Up
7.13.5.3.5  Redaction of URLs from file transfer messagesp. 365
If the delivery of the URL of a file being transferred is not authorised, if the Content-Type of any body part at any layer of the RCS message is "application/vnd.gsma.rcs-ft-http+xml":
  • the value of any url attribute of the data element of the file-info element shall be overwritten with the "space" character such that the length of the attribute does not change.

7.13.6  Generation of xCC over LI_X3p. 365

7.13.7  Generation of CC over LI_HI3p. 366


Up   Top   ToC