7.12 LI for IMS based services

33.1283GPPProtocol and procedures for Lawful Interception (LI)Release 18SecurityStage 3TS

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

7.12.1 General

The present document provides two options for stage 3 definitions for implementing IMS LI:

– Use LI_X1, LI_X2 and LI_X3 interfaces specified below in the present document.

– Use TS 33.107 [36] and TS 33.108 [12] natively as defined in that document.

In both cases, the present document specifies the stage 3 for the LI_HI1, LI_HI2 and LI_HI3 interfaces.

7.12.2 Overview

7.12.2.1 General

This clause defines protocol and procedures to support the LI for IMS-based services. The scope of LI functions defined here are based on the IMS LI architecture defined in TS 33.127 [5] that includes:

– Target type – local ID, non-local ID.

– Roaming considerations – local break-out (LBO), home-routed (HR).

– Service specific aspects – normal sessions, redirected sessions, conferencing, STIR/SHAKEN, RCD/eCNAM.

– Location reporting.

The IMS LI shall apply to all IMS-based services unless restricted by the service scoping as defined in clause 4.4 of the present document. When restricted by the service scoping, the IMS LI applies only to service types listed in table C.2 of ETSI TS 103 221-1 [7]). Clause 7.12.2.5 provides further details of IMS LI with service scoping.

As defined in TS 33.127 [5], the NFs that provide the IRI-POI and CC-TF are in the IMS signaling functions that handle the SIP messages and the NFs that provide the CC-POI are in the IMS media functions. The media interception in the packet core network (EPC or 5GC) is outside the scope of the present document.

For some of the services listed above, an alternate deployment option in addition to the default option is also specified in TS 33.127 [5]. The NFs that provide the IRI-POI, CC-TF and CC-POI in the alternate deployment option can be different.

The LIPF provisioning scenarios for IMS LI is illustrated in Annex G LIPF Logic of the present document.

7.12.2.2 Target type and target identifiers

An IMS user served by the CSP can be the target or can be in communication with a target non-local ID. In the former case, the target can also be an outbound roaming IMS user or an inbound roaming IMS user (see clause 7.12.2.3).

NOTE: A target non-local ID is identified distinctly through the provisioning.

The following target identifier formats (ETSI TS 103 221-1 [7]) can be used to identify a target for IMS based services:

– IMPU.

– IMPI.

– PEIIMEI.

– IMEI.

When service scoping is applicable, additional target identities may be used in LI for IMS based specific services (e.g. MCPTT ID for PTC). The details of such additional target identities are provided in the service specific clauses of the present document.

The target identity in the IMPI format may contain a value derived from a SUPI or an IMSI. The target identity in the IMPU format containing a SIP URI or TEL URI may contain a value derived from a SIP URI, TEL URI, GPSI, MSISDN, an E.164 number or IMSI. Only IMPU is used for target non-local ID.

7.12.2.3 Roaming considerations

An IMS user who is the target, or in communication with the target non-local ID, can be part of the following roaming scenarios for the LI purpose:

– Non-roaming.

– Outbound roaming with HR.

– Outbound roaming with LBO.

– Inbound roaming with HR.

– Inbound roaming with LBO.

The details of LI functions for the case of inbound roaming with HR are described in clause 7.10.

7.12.2.4 Service specific aspects

7.12.2.4.1 General

The NFs that provide the IRI-POI, CC-TF and CC-POI functions can be different depending on the IMS session scenarios the target, or the IMS user in communication with a target non-local ID, is involved in.

An IMS user shall be considered to be in communications with a target non-local ID even if the session is redirected from that target non-local ID.

7.12.2.4.2 LI for normal sessions

This includes LI for session originations and session terminations.

LI for session originations applies when an IMS session is originated by an IMS user whose communications are intercepted either because that originating IMS user happens to be a target or because that originating IMS user happens to be in communications with a target non-local ID. The originating IMS user can also be inbound roaming (LBO or HR) or outbound roaming (LBO or HR).

LI for session terminations applies when an IMS session is terminated to an IMS user whose communications are intercepted either because that terminating IMS user happens to be a target or because that terminating IMS user happens to be in communications with a target non-local ID. The terminating IMS user can also be inbound roaming (LBO or HR) or outbound roaming (LBO or HR).

The other party can be within the same CSP domain (intra-CSP sessions) or in another CSP domain (inter-CSP sessions). In the latter case, the other CSP can be CS-based or IP-based. For target non-local ID, the session is always an inter-CSP session.

7.12.2.4.3 LI for redirected sessions

This includes LI for the incoming IMS sessions that are redirected.

LI for redirected sessions applies when a terminating session to a target is redirected to (or forwarded to) another user. Either the target (i.e. redirecting party) or the redirected-to party can be outbound roaming (LBO or HR).

The redirected-to party can be in the same CSP domain as that of initial terminating party (i.e. redirecting party) or can be a another CSP domain. In the latter case, the other CSP can be CS-based or IP-based. The LI for redirected sessions in the VPLMN are handed as LI for session terminations.

7.12.2.4.4 LI for conferencing

This includes the LI for conferencing services.

LI for conferencing services applies when a target initiates a multi-party conferencing session or when a target joins a "meet-me" conferenceing session or when a "meet me" conferencing session is established with conferencing URI itself being the target.

When a target happens to be one of the participant of a conference initiated by another IMS user, the LI for normal sessions (see clause 7.12.2.4.2) applies.

7.12.2.4.5 STIR/SHAKEN

This includes the LI for STIR/SHAKEN when signature is signed or verified in an IMS session involving a target as described in TS 33.127 [5].

The further details of LI for STIR/SHAKEN are described in clause 7.11.

7.12.2.4.6 RCD/eCNAM

This includes the LI for RCD/eCNAM when enhanced calling name is included in a terminating IMS session involving a target as described in TS 33.127 [5].

The further details of LI for RCD/eCNAM are described in clause 7.11.

7.12.2.5 Service scoping

7.12.2.5.1 General

LI for IMS-based services shall support service scoping with the following specific service types:

– Voice.

– PTC.

– Messaging.

– RCS.

– LALS.

When an NF is involved in the handling of one or more of the above mentioned IMS-based services (e.g. voice, messaging at the S-CSCF), the LI functions within that NF shall limit the interception to the service type to which the warrant applies. However, type of service used by a UE may not be known when an IMS session begins, or if known, may change while, or after, the session is established. Therefore, the present document limits the applicability of service-based interception to the media only.

The present document supports service-based interception to signaling as well media when the NF is involved in the handling of a specific service mentioned above (e.g. PTC server for PTC).

When service scoping is not applicable, the delivery of IRI and CC for IMS-based services are done independent of service types. Location reporting aspects that are also part of the service scoping are described in clause 7.12.2.6.

7.12.2.5.2 LI for voice

This includes the LI for IMS-based voice services.

LI for IMS-based voice services applies to the interception of IMS-based voice media for the IMS sessions involving the targets if and only if the m-line in the SDP answer includes either one of the following:

– Audio.

– Text.

For the generation and delivery of IRI for the IMS sessions, the LI for IMS-based voice is handled independent of the m-line in the SDP.

If the m-line includes "audio" and "video" then only audio part of the media is intercepted.

It is possible that SDP offer and SDO answer may have different information in m-line. The determination on whether to intercept the voice media is based on the final outcome of SDP offer and answer, which happens to be in the SDP answer.

The media associated with an IMS session may also change in the middle of a session using the re-INVITE procedures invoked by either of the parties involved in the session. Accordingly, the interception of voice media may resume or cease in the middle of an IMS session based media type negotiated at the conclusion the related SDP offer and answer.

NOTE: The present document excludes the m-line values of video, msrp, image, application and other, for Service Type of "voice" while determining the media interception (i.e. CC delivery).

7.12.2.5.3 LI for Messaging

This includes LI for SMS over IP and MSRP originated from, or terminated to, a target.

LI for SMS over IP originated from a target applies to the interception of a SIP MESSAGE originated from an IMS user who happens to be a target or happens to be receiving a SIP MESSAGE that has originated from a target non-local ID. That IMS user can also be inbound roaming (LBO or HR) or outbound roaming (LBO or HR).

LI for SMS over IP terminated to a target applies to the interception of a SIP MESSAGE terminated to an IMS user who happens to be a target or happens to be sending the SIP MESSAGE to a target non-local ID. That IMS user can also be inbound roaming (LBO or HR) or outbound roaming (LBO or HR).

LI for MSRP applies to the interception of media for the IMS sessions involving the targets if and only if MSRP is included in the m-line of the SDP answer. For the generation and delivery of IRI for the IMS sessions, the LI for messaging is handled independent of the m-line in the SDP.

When service scoping applies, the LI for Messaging (i.e. SMS over IP or MSRP) is provided if and only if the "messaging" service type is included as a part of LI provisioning. If no service type is provisioned, service scoping does not apply and the LI for messaging shall be provided (per clause 4.4.2).

7.12.2.5.4 LI for voice-mail

This includes LI for IMS-based voice services (see clause 7.12.2.5.3) when an incoming voice session to an IMS user who happens to be a target or an incoming voice session to an IMS user from a target non-local ID is redirected to a voice mail server.

When the incoming session happens to be from a target non-local ID to an IMS user, the retrieval of the voice message from the voice mail server is not intercepted. However, when the IMS user who happens to be the target, the retrieval of the voice message from the voice-mail server may be intercepted in the network that handles the IMS session initiated from the target used to retrieve the voice message.

When service scoping applies, LI for voice-mail is provided if and only if "voice" service type is included as a part of LI provisioning. If no service type is provisioned, service scoping does not apply and the LI for voice-mail shall be provided (per clause 4.4.2).

7.12.2.5.5 LI for RCS

This includes the LI for RCS services when a target executes one of the RCS related services described in TS 33.127 [5].

The further details of LI for RCS are described in clause 7.13.

7.12.2.5.6 LI for PTC service

This includes LI for PTC when a target is engaged in a PTC service as described in TS 33.127 [5].

The further details of LI for PTC are described in clause 7.5.

7.12.2.5.7 LALS triggering

This includes the reporting of location by the LI-LCS Client triggered by the LTF as described in TS 33.127 [5].

The further details of LALS triggering are defined in clause 7.3.

7.12.2.6 Location reporting

When the location reporting is only required at the beginning and end of an IMS session, the location is reported when an IMS session is originated (SIP INVITE) from a target or terminating session is answered (SIP 200 OK for INVITE) from the target or either of the two sessions are released (SIP BYE from the target or SIP 200 OK for BYE from the target).

7.12.2.7 Deployment considerations

As described in TS 33.127 [5], some of the service types may have two deployment options denoted as "default option" and "alternate option".

As illustrated in Annex G, the LIPF provisions the LI functions in a NF based on the option the CSP has deployed within the network.

7.12.2.8 Identifying the intercepted IMS-based communications

7.12.2.8.1 General concepts

An IMS based communication is intercepted when one of the following is true:

– The calling party identity on session originations or SMS originations is a target.

– The called party identity on session originations is a target non-local ID.

– The destination party identity in SMS originations is a target non-local ID.

– The called party identity on session terminations or SMS terminations is a target.

– The calling party identity on session terminations is a target non-local ID.

– The origination party identity in SMS terminations is target non-local ID.

– The redirecting party identity on session terminations is a target non-local ID.

– In the alternate deployment option for redirected sessions (see TS 33.127 [5]), redirecting party is a target.

– The redirected-to party identity is a target non-local ID.

– The conference URI in a conferencing session is a target.

The above identities are used to identify that an IMS session is intercepted in the IRI-POI and in the CC-TF, the latter when the LI requires CC interception. In addition, the CC-TF uses the redirecting party identity to trigger the CC-POI even if the target is not a non-local ID.

7.12.2.8.2 Target match

7.12.2.8.2.1 General

When an IMS UE performs an IMS registration (using SIP REGISTER) request, the IRI-POI/CC-TF examines the following for a target match:

– From header and To header of the SIP REGISTER when the target identity is IMPU.

– +sip.instance-id of Contact header of the SIP REGISTER when the target identity is PEIIMEI or IMEI.

– Digest username of Authorization header of the SIP REGISTER when the target identity is IMPI.

NOTE: The SIP REGISTER that carries the Authorization header is sent in response when the initial Registration is challenged.

A target match for SIP REGISTER can only be done when the NF where the IRI-POI resides is in the path of the SIP REGISTER flow (e.g. P-CSCF, S-CSCF).

7.12.2.8.2.2 Session based IMS services

This clause describes the method used to identify a session-based IMS service such as IMS-based voice service.

When an IMS session is originated from an IMS UE (using SIP INVITE), the IRI-POI/CC-TF examines the following to verify for a target match:

– P-Asserted Identity header and From header present in the SIP INVITE when the target identity is IMPU.

– Request URI header and To header present in the SIP INVITE when the target identity is IMPU and target is non-local ID.

– Digest username of Authorization header of the SIP REGISTER when the target identity is IMPI.

– +sip.instance-id of Contact header received in the SIP REGISTER request when the target identity is PEIIMEI or IMEI.

The use of Request URI header and To header present in the SIP INVITE for matching target non-local ID is done on the redirected sessions irrespective of whether the session is originated from an IMS UE.

When an IMS session is terminated at an IMS UE (using SIP INVITE), the IRI-POI/CC-TF examines the following to verify for a target match:

– Request URI and To header present in the SIP INVITE when the target identity is IMPU.

– P-Asserted-Identity, From header, History Info header and Diversion header present in the SIP INVITE when the target identity is IMPU and target is non-local ID.

– Digest username of Authorization header of the SIP REGISTER when the target identity is IMPI.

– +sip.instance-id of Contact header received in the SIP REGISTER request when the target identity is PEIIMEI or IMEI.

NOTE: IRI-POI/CC-TF that uses the information received in the SIP REGISTER to perform a target match cannot do such a target match unless the NF is on the signaling path of SIP REGISTER flow.

In addition, the IRI-POI in the alternate deployment option (TS 33.127 [5]) and CC-TF, examine the following to verify a target match when an IMS session is terminated to an IMS UE:

– History Info header and Diversion header present in the SIP INVITE when the target identity is IMPU and the target is not a non-local ID.

For conference sessions, the IRI-POI and CC-TF examine the following to verify a target match:

– P-Asserted-Identity, From header present in the SIP INVITE when a target initiates a conference session or when the target joins a "meet-me" conference session.

– Conference URI present in the SIP INVITE when the conference URI is the target.

IRI-POI/CC-TF may use the Via header or the Route header to determine whether the SIP INVITE is for an originating IMS session or a terminating IMS session. IRI-POI/CC-TF stores (locally) the SIP Call Id to associate the subsequent SIP messages received on the same session for a target match.

7.12.2.8.2.3 Session independent IMS services

This clause describes the method used to identify a session-independent IMS service (i.e. SMS over IP).

For SMS over IP, the SIP MESSAGE includes "vnd.3gpp.sms" as the MIME Content Type in the payload with RP-DATA or RP-ACK as the content, see 3GPP TS 24.341 [102].

For MSISDN-less SMS over IP (i.e. SIP URI instead of MSISDN), SIP MESSAGE additionally includes "vnd.3gpp.sms+xml" as the MIME Content Type in the payload with destination or origination addresses, see 3GPP TS 24.341 [102].

The target match for the SIP MESSAGE is done as shown below:

– For MO-SMS over IP, the P-Asserted Identity header and From header present in the SIP MESSAGE when the target identity is IMPU.

– For MO-SMS over IP, the TP-DA field of SMS-SUBMIT within the Message-body of SIP MESSAGE when the target identity is IMPU for target non-local ID.

– For MO-SMS over IP, the <To> field within the XML body of the content type "vnd.3gpp.sms+xml" present in the Message-body of SIP MESSAGE when the target identity is IMPU for target non-local ID. In this case, the TP_DA field of SMS-SUBMIT is be set to dummy MSISDN, see 3GPP TS 24.341 [102].

– For MT-SMS over IP, the Request URI and To header present in the SIP MESSAGE when the target identity is IMPU.

– For MT-SMS over IP, the TP-OA field or TP-RA field of SMS-DELIVER or SMS-STATUS-REPORT within the Message-body SIP MESSAGE when the target identity IMPU for target non-local ID.

– For MSISDN-less MT-SMS over IP, the <From> field within the XML body of the content type "vnd.3gpp.sms+xml" present in the Message-body of SIP MESSAGE when the target identity is IMPU for target non-local ID. In this case, the TP_OA of SMS-DELIVER or TP-RA field of SMS-STATUS-REPORT may be set to dummy MSISDN, see 3GPP TS 24.341 [102].

– Digest username of Authorization header of the SIP REGISTER when the target identity is IMPI.

– +sip.instance-id of Contact header received in the SIP REGISTER request when the target identity is PEIIMEI or IMEI.

NOTE: IRI-POI/CC-TF that uses the information received in the SIP REGISTER to perform a target match cannot do such a target match unless the NF is on the signaling path of SIP REGISTER flow.

IRI-POI may use the Via header or the Route header to determine whether the SIP MESSAGE is for MO-SMS over IP or MT-SMS over IP.

7.12.2.9 Handling of correlation information

The IRI records delivered to the LEMF over the LI_HI2 and the CC delivered to the LEMF over LI_HI3 shall be correlated.

According to the protocol defined in ETSI TS 103 221-1 [7] and ETSI TS 103 221-2 [8], the xIRI messages and the xCC carry the CorrelationID which enables the MDF2 and MDF3 to provide the needed correlation between the IRI and CC.

When the CC-POI is triggered by a CC-TF, the CC-TF sends the CorrelationID to the CC-POI over the LI_T3 interface in the ActivateTask message. The CC-POI uses that CorrelationID in the xCC sent to the MDF3.

NOTE: The IRI-POI and CC-POI may be provided within the same NF (e.g. PTC Server, RCS Server). When the CC-POI is triggered from a CC-TF, the IRI-POI and CC-TF may be provided within the same NF (e.g. P-CSCF, AS/MRFC) or in different NFs (e.g. IRI-POI in S-CSCF and CC-TF in P-CSCF).

When the IRI-POI and CC-POI (or CC-TF in a triggerred CC-POI case) are in the same NF, the procedures can be similar to the way the correlation of xIRI and xCC are done in the packet core system (e.g. IRI-POI and CC-TF in the SMF). The details of any needed interactions between those LI functions are not defined in the present document.

When the IRI-POI and CC-TF are in separate NFs, any additional procedures that may be needed are also implementation specific and the details of the same are not described in the present document.

7.12.3 Provisioning over LI_X1

7.12.3.1 General

The LIPF shall provision the IRI-POIs, CC-TFs, MDF2 and MDF3 over LI_X1 for IMS-based services using the X1 protocol as described in clause 5.2.2.

The clause 7.12.2.2 provides a list of target identifiers that shall be supported for IMS based services in a general sense.

The target identifiers used during the provisioning over LI_X1 for a specific IMS-based service (e.g. PTC) are listed in the respective service specific clauses.

7.12.3.2 Provisioning of IRI-POI

7.12.3.2.1 Session-based IMS services

The table 7.12.3.2-1 below shows the applicability of NFs in which the IRI-POIs are provisioned with the target identifiers listed in clause 7.12.2.2 for session based IMS sessions (e.g. voice). See TS 33.127 [5] and Annex G.

When the service scoping is applicable, the IRI-POIs in the NFs shown in table 7.12.3.2-1 are provisioned only when the type of service is voice/text or messaging (i.e. MSRP-based).

Table 7.12.3.2-1: IRI-POIs in the NFs that need to be provisioned for session-based IMS service

NF (IMS signaling function)	Not a target non-local ID		Target non-local ID		Reference
NF (IMS signaling function)	Default	Alternate option	Default	Alternate option	Reference
P-CSCF	YES	YES	YES	NO	In this clause
S-CSCF	YES	NO	NO	YES	In this clause
E-CSCF	YES	NO	NO	NO	In this clause
IBCF	NO	YES	YES	YES	In this clause
MGCF	NO	YES	YES	NO	In this clause
AS	YES	YES	YES	YES	In this clause
HSS	YES	YES	NO	NO	7.2.3

Table 7.12.3.2-2 shows the minimum details of the LI_X1 ActivateTask message used for provisioning the IRI-POIs in the NFs listed in tables7.12.3.2-1 for session based IMS-based services.

Table 7.12.3.2-2: ActivateTask message for activating IRI-POI for session-based IMS service

ETSI TS 103 221-1 [7] field name	Description	M/C/O
XID	XID assigned by LIPF. The value used here shall be the same when IRI-POIs in multiple NFs are provisioned for a warrant. The value used here shall also be same as the value used for provisioning the CC-TFs (see table 7.12.3.3-1), MDF2 (see 7.12.3.4-1) and MDF3 (see table 7.12.3.5-1).	M
TargetIdentifiers	One or more of the target identifiers listed in the clause 7.12.2.2 with the embedded conditions implied.	M
DeliveryType	Set to “X2Only.	M
ListOfDIDs	Delivery endpoints of LI_X2. 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	Present if interception is to be done on one or more a specific service type. Using the format defined in ETS TS 103 221 [7] based on the service scoping listed below this table. When multiple intercepts are activated on a target identifier, the service scoping shall be the union of all of them.	C

When service scoping is required, the IRI-POIs present in the NFs listed in table 7.12.3.2-1 shall support the following service types from the structure defined in ETSI TS 103 221-1 [7]:

– The enumerated value of "voice" or "messaging" in the service type field.

The ModifyTask and DeactivateTask messages that the LIPF may send to the IRI-POIs present in the NFs listed in table 7.12.3.2-1 shall include the XID of the Task created by the above ActivateTask message.

7.12.3.2.2 Session-independent IMS services

Table 7.12.3.2-3 below shows the applicability of NFs in which the IRI-POIs are provisioned with the target identifiers listed in clause 7.12.2.2 for session independent services (e.g. SMS over IP). See TS 33.127 [5] and Annex G.

When the service scoping is applicable, the IRI-POIs in the NFs shown in table 7.12.3.2-3 are provisioned only when the service type is messaging (i.e. SMS over IP).

Table 7.12.3.2-3: IRI-POIs in the NFs that need to be provisioned for session-independent IMS-based service

NF (IMS signaling function)	Not a target non-local ID		Target non-local ID		Reference
NF (IMS signaling function)	Default	Alternate option	Default	Alternate option	Reference
P-CSCF	YES	YES	YES	YES	In this clause
S-CSCF	YES	NO	YES	NO	In this clause
E-CSCF	YES	NO	NO	NO	In this clause
IBCF	NO	YES	NO	YES	In this clause
MGCF	NO	NO	NO	NO	In this clause
AS	NO	NO	NO	NO	In this clause
HSS	YES	YES	NO	NO	7.2.3

Table 7.12.3.2-4 shows the minimum details of the LI_X1 ActivateTask message used for provisioning the IRI-POIs in the NFs listed in table 7.12.3.2-3 for session independent IMS-based voice services.

Table 7.12.3.2-4: ActivateTask message for activating IRI-POI for session independent IMS-based service

ETSI TS 103 221-1 [7] field name	Description	M/C/O
XID	XID assigned by LIPF. The value used here shall be the same when IRI-POIs in multiple NFs are provisioned for a warrant.	M
TargetIdentifiers	One or more of the target identifiers listed in the clause 7.12.2.2 with the embedded conditions implied.	M
DeliveryType	Set to “X2Only.	M
ListOfDIDs	Delivery endpoints of LI_X2. 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	Present if interception of one or more listed service types is required. Using the format defined in ETS TS 103 221 [7] based on the service scoping listed below this table. When multiple intercepts are activated on a target identifier, the service scoping shall be the union of all of them.	C

When service scoping is required, the IRI-POIs present in the NFs listed in table 7.12.3.2-3 shall support the following service types from the structure defined in ETSI TS 103 221-1 [7]:

– The enumerated value of "messaging" in the service type field.

The ModifyTask and DeactivateTask messages that the LIPF may send to the IRI-POIs present in the NFs listed in table 7.12.3.2-3 shall include the XID of the Task created by the above ActivateTask message.

7.12.3.3 Provisioning of CC-TF

The table 7.12.3.3-1 below shows the applicability of NFs in which the CC-TFs are provisioned with the target identifiers listed in clause 7.12.2.2 for session-based IMS services (e.g. voice). See TS 33.127 [5] and Annex G.

Table 7.12.3.3-1: CC-TFs in the NFs that need to be provisioned for session-based IMS service

NF (IMS signaling function)	Not a target non-local ID		Target non-local ID
NF (IMS signaling function)	Default	Alternate option	Default	Alternate option
P-CSCF	YES	YES	YES	NO
IBCF	YES	YES	YES	YES
MGCF	YES	YES	YES	NO
AS/MRFC	YES	YES	YES	YES
Conferencing AS/MRFC	YES	YES	YES	YES

Table 7.12.3.3-2 shows the minimum details of the LI_X1 ActivateTask message used for provisioning the CC-TFs in the NFs listed in table 7.12.3.3-1 for session-based IMS services.

Table 7.12.3.3-2: ActivateTask message for activating CC-TF for session-based IMS services

ETSI TS 103 221-1 [7] field name	Description	M/C/O
XID	XID assigned by LIPF. The value used here shall be the same when IRI-POIs in multiple NFs are provisioned for a warrant. The value used here shall also be same as the value used for provisioning the IRI-POIs (see table 7.12.3.2-2), MDF2 (see 7.12.3.4-1) and MDF3 (see table 7.12.3.5-1).	M
TargetIdentifiers	One or more of the target identifiers listed in the clause 7.12.2.2 with the embedded conditions implied.	M
DeliveryType	Set to “X3Only.	M
ListOfDIDs	Delivery endpoints of 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	Present if interception of one or more listed service types is required. The value provisioneUsing the format defined in ETS TS 103 221 [7] based on the service scoping listed below this table. When multiple intercepts are activated on a target identifier, the service scoping shall be the union of all of them.	C

When service scoping is required, the CC-TF present in the NFs listed in table 7.12.3.3-1 shall support the following service scoping from the structure defined in ETSI TS 103 221-1 [7]:

– The enumerated value of "voice" or "messaging" in the service type field.

The ModifyTask and DeactivateTask messages that the LIPF may send to the CC-TFs present in the NFs listed in table 7.12.3.3-1 shall include the XID of the Task created by the above ActivateTask message.

7.12.3.4 Provisioning of the MDF2

The MDF2 listed as the delivery endpoint over LI_X2 for xIRI generated by the IRI-POIs shall be provisioned over LI_X1 by the LIPF.

Table 7.12.3.4-1 shows the minimum details of the LI_X1 ActivateTask message used for provisioning the MDF2.

Table 7.12.3.4-1 ActivateTask message for MDF2

ETSI TS 103 221-1 [7] field name	Description	M/C/O
XID	XID assigned by LIPF. The value used here shall also be same as the value used for provisioning the IRI-POIs, CC-TFs, and and MDF3 (see table 7.12.3.5-1).	M
TargetIdentifiers	One or more of the target identifiers listed in the clause 7.12.2.2 with the embedded conditions implied.	M
DeliveryType	Not used.	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.12.3.4-2.	M

Table 7.12.3.4-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	Present if service scoping is required. Using the format defined in ETS TS 103 221 [7] include the service scoping as applicable to this LIID based on the service scoping listed below the table.	C

The MDF2 shall support the following service scoping from the structure defined in ETSI TS 103 221-1 [7]:

– The enumerated value of "voice" or "messaging" in the service type field.

– When location reporting is required, one or both of "reportBeginingAndEnd", "reportUponChange".

The ModifyTask and DeactivateTask messages that the LIPF may send to the MDF2 present in the NFs listed in table 7.12.3.4-1 shall include the XID of the Task created by the above ActivateTask message.

7.12.3.5 Provisioning of the MDF3

The MDF3 listed as the delivery endpoint over LI_X3 for xCC generated by the IRI-POIs shall be provisioned over LI_X1 by the LIPF.

Table 7.12.3.5-1 shows the minimum details of the LI_X1 ActivateTask message used for provisioning the MDF3.

Table 7.12.3.5-1 ActivateTask message for MDF3

ETSI TS 103 221-1 [7] field name	Description	M/C/O
XID	XID assigned by LIPF. The value used here shall also be same as the value used for provisioning the IRI-POIs, CC-TFs, and MDF2 (see table 7.12.3.4-1).	M
TargetIdentifiers	One or more of the target identifiers listed in the clause 7.12.2.2 with the embedded conditions implied.	M
DeliveryType	Not used.	M
ListOfDIDs	Delivery endpoints of LI_HI3. 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.12.3.5-2.	M

Table 7.12.3.5-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 CCI 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	Present if service scoping is required. Using the format defined in ETS TS 103 221 [7] include the service scoping as applicable to this LIID based on the service scoping listed below the table.	C

When service scoping is required, the MDF3 shall support the following service scoping from the structure defined in ETSI TS 103 221-1 [7]:

– The enumerated value of "voice" or "messaging" in the service type field.

The ModifyTask and DeactivateTask messages that the LIPF may send to the MDF3shall include the XID of the Task created by the above ActivateTask message.

7.12.4 Generation of xIRIs over LI_X2

7.12.4.1 IRI-POIs in IMS signaling functions

7.12.4.1.1 General

The IRI-POIs present in the NFs provisioned as shown in table 7.12.3.3-1 generate the xIRIs according to the conditions described in TS 33.127 [5] and illustrated in Annex G.

As described in TS 33.127 [5], clause 7.12.3.2.2 and illustrated in Annex G, the present document supports two deployment options:

– Default option.

– Alternate option.

The options used for LI involving a specific IMS service may be different from the option used for LI involving another IMS service. For example, a default option may be used for target non-local ID and an alternate option may be used for a local target ID.

NOTE: One of the obvious conditions not stated in the subsequent clauses is that an NF can provide an IRI-POI functions if and only if the SIP signaling messages pass through that NF.

When a condition (e.g. inbound roaming with LBO) under which an NF provides the IRI-POI functions is dependent on the handling of SIP REGISTER message, the IRI-POIs may have to scan the SIP REGISTER for all IMS users to address the case when that IMS user engages in a communication with a target non-local ID.

7.12.4.1.2 IRI-POI in P-CSCF

7.12.4.1.2.1 Session-based IMS communications

In the default deployment option, the P-CSCF provides the IRI-POI functions when any of the following conditions are met:

– The target is inbound roaming (with LBO) IMS user and is not registered for emergency services. The E-CSCF provides the IRI-POI functions when the target is registered for the emergency services.

– An inbound roaming (with LBO) IMS user is in communication with a target non-local ID.

In the alternate deployment option, the P-CSCF always provides the IRI-POI functions except for the following cases:

– A non-roaming or outbound roaming (with HR) IMS user in communication with a target non-local ID. The S-CSCF provides the IRI-POI functions for such a case.

– An inbound roaming (with LBO) IMS user is in communication with a target non-local ID when the media is home-routed. The IBCF provides the IRI-POI functions for such a case.

With the above conditions met, the IRI-POI present in the P-CSCF identifies that an IMS-based communication is to be intercepted according to clause 7.12.2.8.

7.12.4.1.2.2 Session-independent IMS communications

In the default deployment option, the P-CSCF provides the IRI-POI functions when any of the following conditions are met:

– The target is inbound roaming (with LBO) IMS user and is not registered for emergency services. If applicable, E-CSCF provides the IRI-POI functions when IMS user is registered for emergency services.

– An inbound roaming (with LBO) IMS user is in communication with a target non-local ID.

In the alternate deployment option, the P-CSCF always provides the IRI-POI functions.

With the above conditions met, the IRI-POI present in the P-CSCF identifies that an IMS-based communication is to be intercepted according to clause 7.12.2.8.

7.12.4.1.3 IRI-POI in S-CSCF

7.12.4.1.3.1 Session-based IMS communications

In the default deployment option, the S-CSCF always provides the IRI-POI functions except for the following condition:

– The target is registered for emergency services and E-CSCF provides the IRI-POI for IMS-based emergency services.

– IMS user is in communication with a target non-local ID. The MGCF or IBCF provide the IRI-POI functions for such a case.

– The S-CSCF is not serving the target.

In the alternate deployment option, the S-CSCF provides the IRI-POI functions when any of the following condition is met:

– IMS user is in communication with a target non-local ID.

– The S-CSCF is serving the IMS user in communication with the target non-local ID.

With the above conditions met, the IRI-POI present in the S-CSCF identifies that an IMS-based communication is to be intercepted according to clause 7.12.2.8.

7.12.4.1.3.2 Session-independent IMS communications

In the default deployment option, the S-CSCF always provides the IRI-POI functions except for the following condition:

– The target is registered for emergency services and E-CSCF provides the IRI-POI for IMS-based emergency services.

– The S-CSCF is neither serving the target nor the IMS user in communication with a target non-local ID.

In the alternate deployment option, the S-CSCF does not provide the IRI-POI functions.

When the above conditions are met, the IRI-POI present in the S-CSCF identifies that an IMS-based communication is to be intercepted according to clause 7.12.2.8.

7.12.4.1.4 IRI-POI in E-CSCF

In the default deployment option, the E-CSCF provides the IRI-POI functions except for the following condition (see Annex G):

– S-CSCF provides the IRI-POI for emergency services.

In the alternate deployment option, the E-CSCF does not provide the IRI-POI functions.

When the above conditions are met, the IRI-POI present in the E-CSCF identifies that an IMS-based communication is to be intercepted according to clause 7.12.2.8.

7.12.4.1.5 IRI-POI in IBCF

7.12.4.1.5.1 Session-based IMS communications

In the default deployment option, the IBCF provides the IRI-POI functions when any of the following conditions are met (see Annex G):

– A non-roaming IMS user is in communication with a target non-local ID.

– An outbound roaming IMS user is in communication with a target non-local ID.

In the alternate deployment option, the IBCF shall provide the IRI-POI functions when any of the following conditions are met:

– The target involved is an outbound roaming (with LBO) IMS user.

– The IMS session to a target is redirected to a user in the IP domain.

– IMS session to a target is redirected to an outbound roaming (with LBO) IMS user.

– An inbound roaming (with LBO) IMS user is in communication with a target non-local ID on an IMS session that employs home-routed media.

When the above conditions are met, the IRI-POI present in the IBCF identifies that an IMS-based communication is to be intercepted according to clause 7.12.2.8.

7.12.4.1.5.2 Session-independent IMS communications

In the default deployment option, the IBCF does not provide the IRI-POI functions.

In the alternate deployment option, the IBCF provides the IRI-POI functions except for the following condition:

– The target is an inbound roaming (with LBO) IMS user. The P-CSCF provides the IRI-POI functions for such a case.

– The inbound roaming (with LBO) IMS user is in communication with a non-local target. The P-CSCF provides the IRI-POI functions for such a case.

When the above conditions are met, the IRI-POI present in the IBCF identifies that an IMS-based communication is to be intercepted according to clause 7.12.2.8.

7.12.4.1.6 IRI-POI in MGCF

7.12.4.1.6.1 Session-based IMS communications

In the default deployment option, the MGCF provides the IRI-POI functions when any of the following conditions are met:

– A non-roaming IMS user is in communication with a target non-local ID.

– An outbound roaming IMS user is in communication with a target non-local ID.

For session-based IMS communications, in the alternate deployment option, the MGCF shall provide the IRI-POI functions when the following condition is met:

– The IMS session to a target is redirected to a user in the CS domain.

When the above conditions are met, the IRI-POI present in the MGCF identifies that an IMS-based communication is to be intercepted according to clause 7.12.2.8.

7.12.4.1.6.2 Session-independent IMS communications

For session-independent IMS communications, the MGCF does not provide the IRI-POI functions.

7.12.4.1.7 IRI-POI in AS

7.12.4.1.7.1 Session-based IMS communications

In both default and alternate deployment options, the AS provides the IRI-POI when the interception of IMS sessions involving special services such as conferencing is required.

The IRI-POI present in the AS identifies that an IMS-based communication is to be intercepted according to clause 7.12.2.8.

7.12.4.1.7.2 Session-independent IMS communications

For session-independent IMS communications, the AS does not provide the IRI-POI functions.

7.12.4.2 IMS records

7.12.4.2.1 IMS Message

For an intercepted IMS based communication (see clause 7.12.2.8), the IRI-POI present in the IMS Signaling Function shall generate the xIRI IMSMessage from the SIP message used to handle that IMS based communication. All SIP messages use the same xIRI record as shown in table 7.12.4.2-1.

Table 7.12.4.2-1: Payload for IMSMessage record

Field name	Description	M/C/O
payload	One of the following payload types (other payload types may be added in future versions of the specification): – encapsulatedSIPMessage: See table 7.12.4.2-2.	M
sessionDirection	Indicates the direction of the SIP session: fromTarget, toTarget, combined (if target calls him/herself) or indeterminate if the direction cannot be determined reliable (see NOTE).	M
voIPRoamingIndication	Indicates whether the roaming mode is inbound LBO, S8HR or N9HR when the target is in roaming situation.	C
location	Location (e.g. PANI Header) with timestamp, if available.	C
NOTE: When an incoming call to a target is redirected to another user, the sessionDirection field shall be set to toTarget. When an incoming call from a target non-local ID to an IMS user is redirected to, the sessionDirection field shall be set to fromTarget.

Table 7.12.4.2-2: Structure of the encapsulatedSIPMessage parameter

Field name	Description	M/C/O
iPSourceAddress	Indicates the conditional source IPv4 address or source IPv6 address field in the PDU header to the source IP address of the intercepted SIP message (see ETSI TS 103 221-2 [8] clause 5.3).	M
iPDestinationAddress	Indicates the conditional destination IPv4 address or destination IPv6 address field in the PDU header to the destination IP address of the intercepted SIP message (see ETSI TS 103 221-2 [8] clause 5.3).	M
sIPContent	The relevant SIP message, or SIP message header if the warrant requires IRI-only. In addition, for IRI-only intercepts, specific content (e.g. SIP MESSAGE method) may have to be deleted.	M

The IRI-POI present in the IMS signaling function generating an xIRI containing an IMSMessage record shall set:

– The Payload Direction field in the PDU header to the direction of the signaling message carried in the IRI payload (see ETSI TS 103 221-2 [8] clause 5.2.6). If the signalling message was sent from the target, the Direction Value "3" (sent from the target) shall be used, if the signalling message was sent to the target, the Direction Value "2" (sent to the target) shall be used; if the direction could not be determined reliably, the Direction Value "1" (not known to the POI) shall be used. If the SIP message is sent from and to the target, the Direction Value "4" (more than one direction) shall be used. For the SIP messages generated by the network, the Direction Value "5" (not applicable) shall be used.

– The conditional source IPv4 address or source IPv6 address field in the PDU header to the source IP address of the intercepted SIP message (see ETSI TS 103 221-2 [8] clause 5.3). It shall contain the source address of the packet from the 32-bit "Source Address" field in IPv4, as defined in IETF RFC 791 [34], or from the 128-bit "Source Address" field in IPv6, as defined in IETF RFC 2460 [27].

– The conditional destination IPv4 address or destination IPv6 address field in the PDU header to the destination IP address of the intercepted SIP message (see ETSI TS 103 221-2 [8] clause 5.3). It shall contain the destination address of the packet from the 32-bit "Source Address" field in IPv4, as defined in IETF RFC 791 [34], or from the 128-bit "Source Address" field in IPv6, as defined in IETF RFC 2460 [27].

7.12.4.2.2 Start of interception with Active IMS session

The IRI-POI present in the IMS signaling function shall generate the xIRI StartOfInterceptionForActiveIMSSession when all of the following conditions are met:

– The IRI-POI receives an LI_X1: ActivateTask from the LIPF.

– The IRI-POI detects the IMS user identified by one or more of the target identifier (s) included in the ActivateTask is on an active IMS session.

– The-IRI-POI in the IMS signaling functions meets the criteria mentioned in TS 33.127 [5] for providing the IRI-POI functions.

The generation of the xIRI shall be independent of the IMS media associated with the session. If multiple IMS sessions are active at the start of interception, a StartOfInterceptionForActiveIMSSession record shall be generated for each active session.

The following table contains parameters, with IRITargetIdentifier, generated by the IRI-POI.

Table 7.12.4.2.-3: Payload for StartOfInterceptionForActiveIMSSession record

Field name	Description	M/C/O
originatingId	Identities of the originator of the session.	M
terminatingId	Identities of the termination of the service.	M
sDPState	Latest state of session from IMS signaling function (including LMISF) will provide the agreed SDP answer and related modification (encoded in SDP format as per RFC 4566 [43] clause 5 when known.) for each media stream of the target.	C
diversionIdentity	Provided if available and applicable.	C
voIPRoamingIndication	Indicates whether the roaming mode is LBO, S8HR or N9HR.when the target is in roaming situation.	C
location	Location (e.g. PANI Header) with timestamp, if available.	C

7.12.4.2.3 IMS CC Unavailable

The IRI-POI present in the IMS signaling function that also has the CC-TF (which would have triggered the media interception at the CC-POI) shall generate the xIRI IMSCCUnavailable when the media is not available for interception in the CSP’s network.

Accordingly, the IRI-POI present in the IMS signaling function that has the CC-TF shall generate the xIRI IMSCCUnavailable when the following conditions are met:

– The target of interception is on an IMS session with established SDP offer and answer.

– The media does not enter the IMS network of the CSP that has received the warrant. In other words, the CC-TF does not send the LI_T3 ActivateTask to the CC-POI.

– The CSP is required to send a notification to the LEMF when the media interception is required but not available for the interception.

NOTE: The details of any interactions required between the IRI-POI and CC-TF present in the same IMS Signaling Function (e.g. IBCF) is outside the scope of the present document.

The payload of the IMSCCUnavailable xIRI is as shown in table 7.12.4.2-4.

Table 7.12.4.2.-4: Payload for IMSCCUnavailable record

Field name	Description	M/C/O
cCUnavailableReason	Provides the reason for the unavailability of CC.	M
sDPState	The latest SDP information, if known.	C

7.12.5 Triggering of CC-POI by CC-TF over LI_T3

7.12.5.1 CC-TFs in IMS signaling functions

7.12.5.1.1 General

The CC_TFs present in the NFs provisioned as shown in table 7.12.3.3-1 activate the CC-POIs according to the conditions described in TS 33.127 [5] and illustrated in Annex G.

NOTE 1: One of the obvious conditions not stated in the subsequent clauses is that an NF can provide the CC-TF functions if and only if the SIP signaling messages pass through that NF.

NOTE 2: The CC-TF functions apply only for session-based IMS communications.

When a condition (e.g. inbound roaming with LBO) under which an NF provides the CC-TF functions is dependent on the handling of SIP REGISTER message, the CC-TFs may have to scan the SIP REGISTER for all IMS users to address the case when that IMS user engages in a communication with a target non-local ID.

7.12.5.1.2 CC-TF in P-CSCF

The P-CSCF provides the CC-TF functions when the CC-POI functions are provided at the IMS-AGW.

The P-CSCF always provides the CC-TF functions (based on the call direction, of-course) except for the following cases:

– A non-roaming IMS user in communication with a target non-local ID. IBCF or MGCF provide the CC-TF functions for that case.

– An outbound roaming (with LBO) IMS user is in communication with a target non-local ID. IBCF or MGCF provide the CC-TF functions for that case.

When an inbound roaming (LBO) IMS user is in communication with a target non-local ID, two deployment options are defined (see TS 33.127 [5]) for providing the CC-TFs functions. The P-CSCF provides the CC-TF functions except for the following case:

– An inbound roaming (with LBO) IMS user is in communication with a target non-local ID when the media is home-routed. IBCF provides the CC-TF functions for that case.

With the above conditions met, the CC-TF present in the P-CSCF identifies that an IMS-based communication is to be intercepted according to clause 7.12.2.8.

7.12.5.1.3 CC-TF in IBCF

The IBCF provides the CC-TF functions when the CC-POI functions are provided at the TrGW.

The IBCF provides the CC-TF functions when any of the following conditions are met:

– A non-roaming IMS user is in communication with a target non-local ID in the IP domain.

– An outbound roaming IMS user is in communication with a target non-local ID in the IP domain.

– IMS session is to an outbound roaming (with LBO) target.

– An IMS session to a target is redirected to a user in the IP domain.

– An IMS session to a target is redirected to an outbound roaming (with LBO) IMS user.

– An inbound roaming (with LBO) IMS user is in communication with a target non-local ID on an IMS session that employs home-routed media and alternate deployment option is used for media interception.

When the above conditions are met, the CC-TF present in the IBCF identifies that an IMS-based communication is to be intercepted according to clause 7.12.2.8.

7.12.5.1.4 CC-TF in MGCF

The MGCF provides the CC-TF functions when the CC-POI functions are provided at the IM-MGW.

The MGCF provides the CC-TF functions when any of the following conditions are met (see Annex G):

– A non-roaming IMS user is in communication with a target non-local ID in the CS domain.

– An outbound roaming IMS user is in communication with a target non-local ID in the CS domain.

– An IMS session to a target is redirected to a user in the CS domain.

When the above conditions are met, the CC-TF present in the MGCF identifies that an IMS-based communication is to be intercepted according to clause 7.12.2.8.

7.12.5.1.5 CC-TF in AS/MRFC

The AS/MRFC provides the CC-TF functions when the CC-POI functions are provided at the MRFP.

The AS/MRFC provides the CC-TF functions when the interception of IMS sessions involving special services such as conferencing, music or tones is required.

The CC-TF present in the AS/MRFC identifies that an IMS-based communication is to be intercepted according to clause 7.12.2.8.

7.12.5.2 LI_T3 triggering details

7.12.5.2.1 General

As described in clause 7.12.5.1, the CC-POI may reside in the IMS-AGW, TrGW, IM-MGW or the MRFP. The trigger to perform the media interception is provided by the CC-TF present in the P-CSCF, IBCF, MGCF, AS/MRFC respectively.

NOTE 1: The present document assumes that the above NFs that have the CC-TF and the NFs that have the CC-POI interact with each other using the H.248 messages.

When the IRI-POI and the CC-TF are provided by two different NFs, the interception of media is performed at the core-network side of the NF that has the CC-POI. This is to align the media interception with the SDP information reported in the xIRI.

When the IRI-POI and the CC-TF are provided by the same NF, based on the deployment option, the interception of media can be done at the access side or core network side of an IMS-AGW, at the peer network side or the core network side of an TrGW. For the IM-MGW, the media interception is always done on the core network side since the peer network is in CS domain. For the MRFP, all sides are core network and therefore, the media interception is always on the core network side.

The possibilities of such media interception points are illustrated in figure 7.12.5.2-1.

Figure 7.12.5.2-1: Media interception point options in the CC-POIs

NOTE 2: Even when the option of access side or peer network side is chosen, for certain session scenarios (e.g. hold), media interception may have to be moved to the core network side.

The time at which trigger is sent to the CC-POI has a relationship to the NF (that has the CC-TF) handling of SIP messages that carry the SDP offer and SDP answer as those SIP messages result in the NF (that has the CC-TF) creating/modifying the media contexts at the NF that handles the media.

The procedures used to activate (i.e. trigger) the media interception at the CC-POI present in IMS-AGW, TrGW and IM-MGW are the same. The procedures used to activate (i.e. trigger) the media interception at the MRFP can be different due to the nature of media functions provided by the MRFP can be different (e.g. conferencing, announcements).

7.12.5.2.2 Activation Task

7.12.5.2.2.1 Overview

The ActivateTask message over the LI_T3 interface is sent from CC-TF to CC-POI as a trigger to start the media interception at the CC-POI. The details of the ActivateTask are as shown in table 7.12.5.2.2-1:

Table 7.12.5.2.2-1: ActivateTask message for triggering the CC-POI over LI_T3

ETSI TS 103 221-1 [7] field name	Description	M/C/O
XID	Allocated by the CC-TF as per ETSI TS 103 221-1 [7].	M
TargetIdentifiers	IP address and the UDP port number are to be used at the CC-POI in identifying the IMS media that needs to be intercepted. See table 7.12.5.2.2-2.	M
DeliveryType	Set to "X3Only".	M
ListOfDIDs	Shall give the DID of the MDF3 to which the xCC should be delivered. The delivery endpoint is configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to the task activation.	M
CorrelationID	This value is set by the CC-TF and shall be same as the value to be used in the xCC generated at the CC-POI.	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 to fill the XID field of xCC sent over LI_X3 to the MDF3.	M
TaskDetailsExtensions/SDP	See table 7.12.5.2.2-3.	M

Along with the IP address and UDP port number, a few additional identifiers are needed for the media interception. These are shown as TargetIdentifierExtension in table 7.12.5.2.2-2 and TaskDetailsExtensions in table 7.12.5.2.2-3.

Table 7.12.5.2.2-2: Target identifiers and extensions for LI_T3

Identifier type	Owner	ETSI TS 103 221-1 [7] TargetIdentifier type	Definition
IPv4 Address	ETSI	IPv4Address	ETSI TS 103 221-1 [7]
IPv6 Address	ETSI	IPv6Address	ETSI TS 103 221-1 [7]
UDP Port Number	ETSI	UDPPort	ETSI TS 103 221-1 [7]
H248 Context ID	3GPP	TargetIdentifierExtension/ H248ContextID	H248ContextID (see XSD Schema)
Payload Direction Assignment	3GPP	TargetIdentifierExtension/ PayloadDirectionAssignment	PayloadDirectionAssignment (see XSD Schema)
Trigger Scope	3GPP	TargetIdentifierExtension/ TriggerScope	TriggerScope (see XSD Schema)

Table 7.12.5.2.2-3: SDP task details extensions for LI_T3

Extensions field name	Description	M/C/O
LocalSDP	SDP sent to the remote end of the session (see paragraph below)	C
RemoteSDP	SDP received from the remote end of the session (see paragraph below)	C

The IP address and the UDP port number as target identifiers give the destination address at the UDP layer of the to-be intercepted media. For symmetric media, the same IP address and UDP port number give the source address at the UDP layer of the to-be-intercepted media in the reverse direction.

The H248ContextID identifies the identity of the media context created at the IMS Media Function using the H.248 Add Context message.

The TriggerScope indicates whether IP address and UDP port number included as the target identifiers in the LI_T3 ActivateTask are to be used for bidirectional media or unidirectional media. In the latter case, a separate trigger shall be sent to intercept media in the reverse direction. "Bidirectional" and "Unidirectional" are the values that can be set for the TriggerScope by the CC-TF in the ActivateTask message.

When the TriggerScope is "Unidirectional", the IP address and UDP port number identify the destination IP address and the UDP port number of the intercepted IMS media stream. When the TriggerScope is "Bidirectional", the IP address and UDP port number identify the destination IP address and UDP port number of the incoming intercepted IMS media and the source IP address and UDP port number of the outgoing IMS media.

The PayloadDirectionAssignment field indicates the direction of the media stream destined to the IP address and UDP port number (indicated as target identifiers in the ActivateTask) from the perspective of the target. "FromTarget", "ToTarget" and "NotDetermined" are the values that can be set for this by the CC-TF in the ActivateTask message.

The LocalSDP provides the SDP information to be sent in a SIP message by the NF that has the CC-TF. The RemoteSDP provides the SDP information received in a SIP message at the NF that has the CC-TF. In some cases, both LocalSDP and RemoteSDP may be included in the ActivateTask message. The CC-POI is expected to use the LocalSDP to populate the SDP Session Description field of the X3 PDUs for the incoming media streams and to use the the RemoteSDP to populate the SDP Session Description field of the X3 PDUs for the outgoing media streams.

7.12.5.2.2.2 Activation of CC-POI in IMS-AGW, TrGW, IM-MGW

The CC-TF shall send a trigger to the CC-POI using the ActivateTask message over the LI_T3 interface for an intercepted IMS session (as determined according to the clause 7.12.2.8) that requires the CC interception when the following occur:

– The NF that has the CC-TF receives the acknowledgement (i.e. H.248 Reply) to the H.248: Add Context from the NF that has the CC-POI. The H.248: Add Context is sent when the SIP message that contains the SDP offer is handled.

– The CC-TF receives an ActivateTask from the LIPF over LI_X1 with CC interception required for an IMS session with an already established SDP offer and possibly SDP answer as well. This process is part of a mid-session activation of interception.

When the media streams are asymmetric, the CC-TF shall send a second trigger to the CC-POI using the ActivateTask message over the LI_T3 interface to intercept the media in the reverse direction when the following occur:

– When the SDP offer is received from the side where the media interception is done, the NF that has the CC-TF receives the acknowledgement (i.e. H.248 Reply) to the H.248: Add Context from the NF that has the CC-POI. The H.248: Add Context is sent when the SIP message that contains the SDP offer is handled. This happens at the same time the first trigger (LI_T3 ActivateTask) is sent.

– When the SDP answer is received from the side where the media interception is done, the NF that has the CC-TF receives the acknowledgement (i.e. H.248 Reply) to the H.248 Mod Context from the NF that has the CC-POI. The H.248: Mod Context is sent when the SIP message that contains the SDP answer is handled.

The details of ActivateTask sent from the CC-TF to the CC-POI over LI_T3 are shown in table 7.12.5.2.2-1.

For the trigger (for the asymmetric media case, it is the first trigger):

– The CC-TF shall use the IP address and UDP port number present in the local descriptor part of the acknowledgement (i.e. H.248 Reply) to an H.248 Add context message. The same IP address and the UDP port numbers are also present in the SIP messages that carry the SDP offer or SDP answer (depending on the SIP message direction and the session scenario).

NOTE 1: The SDP offer may be present in a forward SIP message (e.g. SIP INVITE) or in a response SIP message (e.g. SIP 200 OK). In the latter case, the trigger to perform media interception is sent when the response SIP message is handled.

When the CC-TF and IRI-POI are present in different NFs, the IP address and the UDP port number are associated with the core network side of the NF that has the CC-POI.

When the CC-TF and the IRI-POI are in the same NF, as a deployment option, the CC-TF may choose the side for media interception and hence, includes the IP address and the UDP port number that correspond to the side at which the media interception is to be done. The sides thus chosen based on the IP address and UDP port number can be the access side or core network side when the CC-POI is in IMS-AGW, the side can be peer network side or core network side when the CC-POI is in TrGW, and the side is always the core network side when the CC-POI is in the IM-MGW (see figure 7.12.5.2-1). The CC-POI is expected to perform the media interception on the side as determined by that IP address and the UDP port number.

For the second trigger that applies to asymmetric media case:

– The CC-TF shall use the IP address and UDP port number present in the remote descriptor part of the of the H.248 transaction that happens between the NF that has the CC-TF and the NF that has the CC-POI. The same IP address and the UDP port numbers are also present in the SIP messages that carry the SDP offer or SDP answer (depending on the SIP message direction and the session scenario).

The remote IP address and the UDP port number are on the same side where the local IP address and UDP port number were provided in the first trigger.

The values that the CC-TF sets for the PayloadDirectionAssignment and TriggerScope shall be determined as described in tables 7.12.5.2.2-4 and 7.12.5.2.2-5.

Table 7.12.5.2.2-4: PayloadDirectionAssignment and TriggerScope values (target identifier from local descriptor)

Media interception side		PayloadDirectionAssignment		TriggerScope
Media interception side		Not a non-local ID	Non-local ID	Symmetric media	Asymmetric media
IMS-AGW	Access	FromTarget	ToTarget	"Bidirectional"	n/a
IMS-AGW	Core network	ToTarget	FromTarget	"Bidirectional"	"Unidirectional"
TrGW	Peer network	FromTarget	FromTarget	"Bidirectional"	"Unidirectional"
TrGW	Core network	ToTarget	ToTarget	"Bidirectional"	"Unidirectional"
IM-MGW	Core network	ToTarget	ToTarget	"Bidirectional"	"Unidirectional"

Table 7.12.5.2.2-5: PayloadDirectionAssignment and TriggerScope values (target identifier from remote descriptor)

Media interception side		PayloadDirectionAssignment		TriggerScope
Media interception side		Not a non-local ID	Non-local ID	Symmetric media	Asymmetric media
IMS-AGW	Access	n/a	n/a	n/a	n/a
IMS-AGW	Core network	FromTarget	ToTarget	n/a	"Unidirectional"
TrGW	Peer network	ToTarget	ToTarget	n/a	"Unidirectional"
TrGW	Core network	FromTarget	FromTarget	n/a	"Unidirectional"
IM-MGW	Core network	FromTarget	FromTarget	n/a	"Unidirectional"

NOTE 2: The media interception of target non-local ID is done in the IMS-AGW only when the IMS user is in communication with the target non-local ID is an inbound roamer with LBO with the alternate deployment option (see TS 33.127 [5]).

NOTE 3: When media is neither sent to nor received from the target (e.g. call waiting scenario, held session), and when the CC-TF is aware of the scenario, the value of "NotDetermined" is used as the PayloadDirectionAssignment value. The CC-TF changes the PayloadDirectionAssignment value using a LI_T3 ModifyTask (see clause 7.12.5.2.3) when the media is cross connected to the target (e.g. held session is retrieved).

The table 7.12.5.2.2-6 shows how the CC-POI is expected to set the Payload Direction field in the xCC based on the PayloadDirectionAssignment and TriggerScope values received in the LI_T3 ActivateTask message.

Table 7.12.5.2.2-6: Expected payload direction value in the xCC

TriggerScope	PayloadDirectionAssignment	RTP stream (media stream) direction
TriggerScope	PayloadDirectionAssignment	To the target identifier	From the target identifier
Bidirectional	FromTarget	"3" from the target	"2" to the target
	ToTarget	"2" to the target	"3" from the target
	NotDetermined	"5" not applicable to this xCC	"5" not applicable to this xCC
Unidirectional	FromTarget	"3" from the target	n/a
	ToTarget	"2" to the target	n/a
	NotDetermined	"5" not applicable to this xCC	n/a

NOTE 4: When the TriggerScope value is "Unidirectional", two LI_T3 triggers are sent to the CC-POI and in this case, the CC-POI is expected to set the Payload Direction field separately according to the PayloadDirectionAssignment received in the corresponding LI_T3 trigger.

The following paragraphs describe the algorithm the CC-TF shall use for the inclusion of the LocalSDP and Remote SDP in the LI T3 ActivateTask message.

– When the TriggerScope value is "Bidirectional":

– When the SDP offer is received at the NF that has the CC-TF (on the side where the media interception is done) before the sending of a ActivateTask to the CC-POI, the CC-TF shall use the SDP information received in the SDP offer as RemoteSDP and the SDP information that will be sent later in the SDP answer of a SIP message as LocalSDP.

– When the SDP offer is sent by the NF that has the CC-TF (on the side where the media interception is done) after the sending of a ActivateTask to the CC-POI, the CC-TF shall use the SDP information that will be included in the SDP offer of a SIP message as LocalSDP. In this case, the RemoteSDP is sent in the LI_T3 ModifyTask when the SDP answer is received in a SIP message (see clause 7.12.5.2.3).

– When the TriggerScope value is "Unidirectional":

– When the SDP offer is received at the NF that has the CC-TF (on the side where the media interception is done) before the sending of a ActivateTask to the CC-POI, the CC-TF shall use the SDP information that will be sent later in the SDP answer of a SIP message as the LocalSDP in the first LI_T3 trigger. The SDP information received in the SDP offer as the RemoteSDP in the second LI_T3 trigger.

– When the SDP answer is received at the NF that has the CC-TF (on the side where the media interception is done), the CC-TF shall use the SDP information received in the SDP answer of SIP message as RemoteSDP of the second LI_T3 trigger.

For the mid-session interception case, the CC-TF shall include both the LocalSDP and RemoteSDP in the trigger (LI_T3 ActivateTask) when the TriggerScope is "Bidirectional".

For mid-session interception case when the TriggerScopeValue is "Unidirectional", the CC-TF shall include the LocalSDP in the first trigger (LI_T3 ActivateTask) and the RemoteSDP in the second trigger (LI_T3 ActivateTask).

The CC-POI is expected to populate the SDP Session Description field of X3 PDU with the SDP information received in the LocalSDP, for the xCC that represent the incoming media streams destined to the IP address and UDP port number specified as the target identifiers.

The CC-POI is expected to populate the SDP Session Description field of X3 PDU with the SDP information received in the RemoteSDP, for the xCC that represent the outgoing media streams. In the case where TriggerScope value is "Bidirectional", the outgoing media streams will be from the IP address and UDP port number specified as the target identifiers. In the case where TriggerScope value is "Unidirectional", the outgoing media streams will be destined to the IP address and UDP port number specified as the target identifiers.

7.12.5.2.2.3 CC-POI in MRFP

The CC-TF present in the AS/MRFC shall send a trigger to the CC-POI present in the MRFP using the ActivateTask message over the LI_T3 interface for an intercepted IMS session (as determined according to the clause 7.12.2.8) that requires the CC interception when the following occurs:

– The AS/MRFC that has the CC-TF receives the acknowledgement (i.e. H.248 Reply) to the H248: Add Context from the MRFP.

When the media streams are asymmetric, the CC-TF present in the AS/MRFC shall send a second trigger to the CC-POI present in the MRFP using the ActivateTask message over the LI_T3 interface to intercept the media in the reverse direction when the following occur:

– When the SDP offer is received, the AS/MRFC receives the acknowledgement (i.e. H.248 Reply) to the H.248: Add Context from the MRFP. The H.248: Add Context is sent when the SIP message that contains the SDP offer is handled. This happens at the same time the first trigger (LI_T3 ActivateTask) is sent.

– When the SDP answer is received, the AS/MRFC receives the acknowledgement (i.e. H.248 Reply) to the H.248 Mod Context from the MRFP. The H.248: Mod Context is sent when the SIP message that contains the SDP answer is handled.

For a conferencing scenario, the AS/MRFC is expected to send the H.248: Add Context to the MRFP when it handles a SIP message that includes a Conference Factory URI in the Request URI field. Only one LI_T3 ActivateTask is required to intercept the media for a conference.

Additionally, in support of the mid-session interception, the CC-TF present in the AS/MRFC shall send a trigger to the CC-POI present in the MRFP using the ActivateTask message over the LI_T3 interface when the following occur:

– The CC-TF present in the AS/MRFC receives an ActivateTask from the LIPF over LI_X1 with CC interception required, when an incoming IMS session to the target identifier included in the LI_X1 ActivateTask was redirected to voice mail server with an already established SDP offer and possibly SDP answer as well.

– The CC-TF present in the AS/MRFC receives an ActivateTask from the LIPF over LI_X1 with CC interception required, when announcement or tones are being applied to the caller of an incoming IMS session to the target identifier included in the LI_X1 ActivateTask message.

– The CC-TF present in the AS/MRFC receives an ActivateTask from the LIPF over LI_X1 with CC interception required, when the user represented through the target identifier included in the LI_X1 Activate Task is one of the participants in an established conference session.

– The CC-TF present in the AS/MRFC receives an ActivateTask from the LIPF over LI_X1 with CC interception required, when the Conference URI associated with an established conference session is included as a target identifier in the LI_X1 Activate Task message.

The details of LI_T3 ActivateTask are shown in table 7.12.5.2.2-1.

For the trigger (for the asymmetric media case, it is the first trigger):

– The CC-TF shall use the IP address and UDP port number present in the local descriptor part of the acknowledgement (i.e. H.248 Reply) to an H.248 Add context message. The same IP address and the UDP port numbers are also present in the SIP messages that carry the SDP offer or SDP answer (depending on whether the AS/MRFC receives or sends the SDP offer).

For the second trigger that applies to asymmetric media case:

– The CC-TF shall use the IP address and UDP port number present in the remote descriptor part of the of the H.248 transacation that happens between AS/MRFC and the MRFP.The same IP address and the UDP port numbers are also present in the SIP messages that carry the SDP offer or SDP answer (depending on whether the AS/MRFC receives or sends the SDP offer).

The values that the CC-TF sets for the PayloadDirectionAssignment and TriggerScope shall be determined as described in tables 7.12.5.2.2-7 and 7.12.5.2.2-8.

Table 7.12.5.2.2-7: PayloadDirectionAssignment and TriggerScope values (target identifier from local descriptor)

Service type	PayloadDirectionAssignment			TriggerScope
Service type	Not a non-local ID	Non-local ID	Conference URI	Symmetric media	Asymmetric media
Redirected	NotDetermined	FromTarget	n/a	"Bidirectional"	"Unidirectional"
Conference	NotDetermined	n/a	NotDetermined	"Bi-directional"	n/a

Table 7.12.5.2.2-8: PayloadDirectionAssignment and TriggerScope values (target identifier from remote descriptor)

Service type	PayloadDirectionAssignment			TriggerScope
Service type	Not a non-local ID	Non-local ID	Conference URI	Symmetric media	Asymmetric media
Redirected	NotDetermined	ToTarget	n/a	n/a	"Unidirectional"
Conference	NotDetermined	n/a	n/a	n/a	n/a

Tables 7.12.5.2.2-5 and 7.12.5.2.2-6 (clause 7.12.5.2.2) shows how the CC-POI is expected to set the Payload Direction field in the xCC based on the PayloadDirectionAssignment and TriggerScope values received in the LI_T3 ActivateTask message.

For an intercepted conference session, the CC-POI shall perform the media interception in a mixed mode including the media from all conference participants. The concept of Payload Direction, therefore, does not apply to the corresponding xCC.

The CC-TF present in the in the AS/MRFC shall follow the algorithm described in clause 7.12.5.2.2.2 to populate the LocalSDP and RemoteSDP fields of LI_T3 ActivateTask.

7.12.5.2.2.4 Activation of CC-POI when media interceptions are done at both sides IMS media function

This is a special case where the media interception is done at both sides of an IMS Media Function. In this case, the CC-POI would intercept the outgoing media streams on both sides of IMS Media Function as shown in figure 7.12.5.2-2 below.

Figure 7.12.5.2.2-2: Media interception on both sides of the IMS Media Function

The CC-POI would capture the media streams destined to the remote IP address and UDP port number for the generation of xCC both sides. For this case, even if the media streams are symmetric, the TriggerScope shall be set to "Unidirectional". Accordingly, the CC-TF shall send the two triggers to CC-POI using the ActivateTask message over the LI_T3 interface when the following occur:

– When the SDP answer is received from the side where the media interceptions is done, the NF that has the CC-TF receives the acknowledgement (i.e. H.248 Reply) to the H.248: Mod Context from the NF that has the CC-POI.

The details of ActivateTask sent from the CC-TF to the CC-POI over LI_T3 are shown in table 7.12.5.2.2-1.

The CC-TF shall use the IP address and UDP port number present in the remote descriptor part of the of the H.248 transaction that happens between the NF that has the CC-TF and the NF that has the CC-POI. The same IP address and the UDP port numbers are also present in the SIP messages that carry the SDP offer or SDP answer (depending on the SIP message direction and the session scenario).

The CC-TF shall set the PayloadDirectionAssignment value described in table 7.12.5.2.2-9:

Table 7.12.5.2.2-9: PayloadDirectionAssignment values

Target side	First trigger	Second trigger
On the side from which the SDP offer is received	ToTarget	FromTarget
On the side from which the SDP answer is received	FromTarget	ToTarget

NOTE: When the media is neither sent to nor received from the target (e.g. call waiting scenario, held session), and when the CC-TF is aware of the scenario, the value of "NotDetermined" is used as the PayloadDirectionAssignment value. The CC-TF changes the PayloadDirectionAssignment value using a LI_T3 ModifyTask (see clause 7.12.5.2.3) when the media is cross connected to the target (e.g. held session is retrieved).

For this case, the CC-TF shall include the SDP information in the RemoteSDP of TaskDetailsExtensions of LI_T3 ActivateTask for both triggers as described below:

– When the SDP offer is received at the NF that has the CC-TF (on the side where the media interception is done), the CC-TF shall use the SDP information received in the SDP offer of SIP message as RemoteSDP of the first LI_T3 trigger.

7.12.5.2.3 ModifyTask

The ModifyTask message (s) that a CC-TF may send to a CC-POI shall include the XID of the Task (s) created by the ActivateTask message(s) (see table 7.12.5.2.2-1). The details of the ModifyTask are as shown in the table 7.12.5.2.2-10:

Table 7.12.5.2.2-10: ModifyTask message to update the previous trigger the CC-POI over LI_T3

ETSI TS 103 221-1 [7] field name	Description	M/C/O
XID	Shall be same as in the ActivateTask message (see 7.12.5.2.1).	M
TargetIdentifiers	Shall be same as in the ActivateTask message (see 7.12.5.2.1).	M
DeliveryType	Set to "X3Only".	M
ListOfDIDs	Shall give the DID of the MDF3 to which the xCC should be delivered. The delivery endpoint is configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to the task activation.	M
CorrelationID	Shall be same as in the ActivateTask message (see 7.12.5.2.1).	M
ProductID	Shall be same as in the ActivateTask message (see 7.12.5.2.1).	M
TaskDetailsExtensions/SDP	See table 7.12.5.2-2.	M

The LI_T3 ModifyTask shall also use the same correlation ID, the same target identifiers as used in the LI_T3 ActivateTask.

The examples of few scenarios that may necessitate the sending of a ModifyTask over LI_T3 to the CC-POI are the following:

– When the TriggerScope value used in the LI_T3 ActivateTask is "Bidirectional", the SDP answer is received in a SIP message on the side where the media interception is done. The SDP information received in the SDP answer of SIP message shall be included as RemoteSDP in the LI_T3 ModifyTask. The LI_T3 ModifyTask shall also include the LocalSDP which was previously sent to the CC-POI in the LI_T3 ActivateTask message.

NOTE: The same SDP information is sent to the CC-POI when the TriggerScope value is "Unidirectional" as RemoteSDP in a second LI_T3 ActivateTask trigger (see clause 7.12.5.2.2.2).

– The SDP is changed through a new SDP offer and answer during the session establishment phase.

– The cases such as IP address or UDP port numbers are being changed on an established IMS session (using H.248 Modify Context (which may also include a Add Request to an existing context)).

– When a session is placed on hold, if the media interception sides have to be switched (e.g. from access side of IMS-AGW to core network side of IMS-AGW).

– When a session is placed on hold or retrieved from hold, if the PayloadDirectionAssignment value for the Target Identifier (associated with a previously sent LI_T3 Activate Task or LI_T3 Modify Task) are to be changed.

– When the media interception has to begin only when the media is cross-connected within the NF that has the CC-POI (e.g. call waiting).

Usually, the LI_T3 ModifyTask is sent when the NF that has the CC-TF sends a H.248: Modify Context (or a H.248 Add Request to an existing context) message to the NF that has the CC-POI, if certain aspects of media interception require to be changed.

As an alternate implementation, the CC-TF could use a LI_T3 DeactivateTask (clause 7.12.5.2.4) and LI_T3 ActivateTask (clause 7.12.5.2.1) to handle the held/retrieval scenario. Similarly, as an alternate implementation, the CC-TF could delay the LI_T3 ActivateTask till the media is cut-through within the NF that has the CC-POI in the call waiting scenario.

If two LI_T3 ActivateTask messages were used (asymmetric media stream case), then two LI-T3 ModifyTask messages may be required (depending on the scenario).

7.12.5.2.4 DeactivateTask

The DeactivateTask message(s) that the CC-TF sends to the CC-POI shall include the XID of the Task created by the associated ActivateTask message (see table 7.12.5.2.2-1).

The examples of few scenarios that may necessitate the sending of a DeactivateTask over LI_T3 to the CC-POI are the following:

– Media interception of an IMS session ends.

Usually, the LI_T3 DeactivateTask is sent when the NF that has the CC-TF sends a H.248: Subtract Context to the NF that has the CC-POI which in turn normally happens when the SIP BYE is handled. Also, as an alternate implementation, the CC-TF could send a LI_T3 DeactivateTask when a session is placed on hold.

If two LI_T3 ActivateTask messages were used (asymmetric media stream case), then two LI-T3 DeactivateTask messages are required.

7.12.6 Generation of xCC over LI_X3

7.12.6.1 General

The CC-POI shall generate the xCC for the IMS media based on the LI_T3 trigger received from the CC-TF. The CC-POI shall then deliver the xCC to the MDF3 (destination end point indicated in the LI_T3 trigger).

As described in clause 7.12.5.1, the CC-POI may reside in the IMS-AGW, TrGW, IM-MGW, the MRFP or the LMISF.

7.12.6.2 Media capture

The CC-POI shall use the H248ContextID received in the LI_T3 ActivateTask trigger to match the Context ID seen in the H.248 transactions with the NF that has the CC-TF.

In addition, the CC-POI shall use the IP address and UDP port number received as the target identifiers in the LI_T3 trigger along with the TriggerScope also received in the LI_T3 trigger to identify the media packets to be intercepted for the generation of xCC using the following algorithm:

– When the TriggerScope value received in the LI_T3 trigger is "Unidirectional", the IP address and UDP port number received in the LI_T3 ActivateTask as target identifiers shall match the destination IP address and UDP port number of the media packets.

– When the TriggerScope value received in the LI_T3 trigger is "Bidirectional", the IP address and UDP port number received in the LI_T3 ActivateTask as target identifiers shall match the destination IP address and UDP port number of the incoming media packets and shall match the source IP address and UDP port number of outgoing media packets in the reverse direction.

The CC-POI shall expect to receive two LI_T3 ActivateTask triggers when the value of TriggerScope is "Unidirectional". The two triggers provide the information necessary to identify the media in two directions of the media flow. The H248ContextID in the two triggers are the same. The CorrelationID in the two triggers are the same.

The media packets destined to the local IP address and UDP port number are referred to as incoming media packets. The media packets destined to the remote IP address and UDP port number are referred to as outgoing media packets.

7.12.6.3 Payload format

The CC-POI shall set the payload format to indicate the appropriate payload type (5 for IPv4 packet, 6 for IPv6 packet) as described in ETSI TS 103 221-2 [8] (clauses 5.4 and 5.4.13).

7.12.6.4 Payload direction

The CC-POI shall set the payload direction to indicate the direction of the media packets included in the xCC delivered to the MDF3 as described in ETSI TS 103 221-2 [8] clause 5.2.6 and the following paragraph.

The PayloadDirectionAssignment field received in the LI_T3 ActivateTask message instructs the CC-POI how to populate the Payload Direction for each xCC PDU that it generates. If an intercepted media stream (i.e. IP packet) is destined for the IP address and port given in the LI_T3 ActivateTask message, the CC-POI shall set the Payload Direction of the xCC packet to the value that has the same meaning as the value given in the PayloadDirectionAssignment field. For an intercepted IP packet travelling in the other direction, the CC POI should use the opposite direction value. Specific instructions on how to set the xCC Payload Direction field for given combinations of IP packet direction and TriggerScope value are given in table 7.12.6.4-1 below.

7.12.6.4-1: Payload direction value in the xCC

TriggerScope (LI_T3 trigger)	PayloadDirectionAssignment (LI_T3 trigger)	RTP stream (media stream) direction
TriggerScope (LI_T3 trigger)	PayloadDirectionAssignment (LI_T3 trigger)	Media to the LI_T3 target identifier	Media from the LI_T3 target identifier
Bidirectional	FromTarget	"3" from the target	"2" to the target
	ToTarget	"2" to the target	"3" from the target
	NotDetermined	"5" not applicable to this xCC	"5" not applicable to this xCC
Unidirectional	FromTarget	"3" from the target	n/a
	ToTarget	"2" to the target	n/a
	NotDetermined	"5" not applicable to this xCC	n/a

NOTE: When the TriggerScope value is "Unidirectional", two LI_T3 triggers are received from the CC-TF and in this case, the CC-POI sets the Payload Direction field separately according to the PayloadDirectionAssignment received in the corresponding LI_T3 trigger.

In some session scenarios, the media packets destined to the IP address and UDP port number specified as target identifiers in the LI_T3 Activate Task may not be delivered to the intercept target (e.g. call waiting scenario, hold scenario). When the CC-TF is aware of this, it would have used the value "NotDetermined" as the PayloadDirectionAssignment field.

When the xCC is delivered in a combined form (e.g. conference), independent of the PayloadDirectionAssignment value received in the LI_T3 Activate Task, the CC-POI shall use the Payload Direction value 4: sent to and received from the target.

7.12.6.5 SDP session description

The CC-POI shall generate the SDP Session Description field (as specified in ETSI TS 103 221-2 [8] clause 5.3.23) of xCC from the the LocalSDP and RemoteSDP received in the LI_T3 trigger from the CC-TF as described below.

When the TriggerScope value is "Bidirectional", the CC-POI may receive the Local SDP and RemoteSDP in one LI_T3 trigger or in two separate LI_T3 triggers. When the TriggerScope value is "Unidirectional", the Local SDP and RemoteSDP are received in two separate triggers.

NOTE 1: When the TriggerScope value in the LI_T3 trigger is "Unidirectional", the CC-TF includes LocalSDP in the LI_T3 trigger that has the local IP address and UDP port number as target identifiers and RemoteSDP in the LI_T3 trigger that has the remote IP address and the UDP port number as the target identifiers.

NOTE 2: When the media interception is done at two sides of the IMS Media Function, the CC-POI receives RemoteSDP in both LI_T3 triggers with the TriggerScope value set to "Unidirectional".

The CC-POI shall include the LocalSDP in the SDP Session Description field of the xCC generated from the incoming media packets. The CC-POI shall include the RemoteSDP in the Session Description field of xCC from the outgoing media media packets. Clause 7.12.6.2 describes how the CC-POI identifies the incoming and outgoing media packets.

NOTE 3: The LocalSDP provides the SDP information (e.g. codec information) expected by the IMS Media Function that has the CC-POI. The media packets sent by the remote end of the media flow are based on this SDP information. Therefore, the LocalSDP is associated to the incoming media packets.

NOTE 4: The RemoteSDP address provides the SDP information (e.g. codec information) expected by the remote end of the media flow. The media packets sent to that remote end of the media flow are based on this SDP information. Therefore, the RemoteSDP is associated to the outgoing media packets.

The SDP Session Description field shall be included in the xCC each time a new LocalSDP or RemoteSDP is received in the LI_T3 trigger from the CC-TF.

7.12.6.6 Additional XID related information

The CC-POI may use the Additional XID Related Information attribute to facilitate efficient delivery of xCC, as specified in ETSI TS 103 221-2 [8] clause 5.3.22.

7.12.7 Generation of IRI over LI_HI2

7.12.7.1 General

When an xIRI is received over LI_X2 from the IRI-POI, the MDF2 shall send the IRI message over LI_HI2 according to clause 5.5.2 of the present document 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 MDF2 (e.g. additional location information).

The timeStamp field of the ETSI TS 102 232-1 [9] PSHeader structure shall be set to the time present in the timestamp field of the xIRI.

The threeGPP33128DefinedIRI field (see ETSI TS 102 232-7 [10] clause 15) shall be populated with the BER-encoded IRIPayload.

IRI messages associated with the same IMS session shall have the same CIN (see ETSI TS 102 232-1 [9] clause 5.2.4).

The IRI type parameter (see ETSI TS 102 232-1 [9] clause 5.2.10) shall be included and coded according to table 7.12.7.1-1.

Table 7.12.7.1-1: IRI type for IRI messages

Record type	IRI Type
IMSMessage	REPORT
StartOfInterceptionForActiveIMSSession	REPORT
IMSCCUnavailable	REPORT

7.12.7.2 Handling of multiple instances of list of mediation details

The MDF2 may have to deliver IRI messages to more than one LEMFs when more than one instances of ListOfMediationDetails are associated with a task (i.e. XID) provisioned at the MDF2.

The MDF2 shall populate the LIID field in the IRI messages delivered over the LI_HI2 accordingly.

7.12.7.3 Mid-session activation for additional warrants at MDF2

When a new warrant is to be activated on a target identity (i.e. the associated IMS user is already the target of interception due to another warrant), the LIPF may use the same XID for the new warrant (e.g. when there is no need to receive two separate copies of xIRI messages over LI_X2). In this case, the LIPF may activate the new warrant only at the MDFs using an LI_X1 ModifyTask message with a new instance of ListOfMediationDetails.

The MDF2 that receives a LI_X1 ModifyTask with a new instance of ListOfMediationDetails shall be able to generate and deliver the IRI message containing the StartOfInterceptionForActiveIMSSession record to the LEMF as represented in the new instance of ListOfMediationDetails without receiving a corresponding xIRI from the IRI-POI. The MDF2 shall generate and deliver such an IRI message for each of the established IMS session legs to the LEMF represented within the ListOfMediationDetails.

The timeStamp field of the ETSI TS 102 232-1 [9] PSHeader structure shall be set to the present time known to the MDF2.

The payload of the StartOfInterceptionForActiveIMSSession record is specified in table 7.12.4.2-3 (see also clause 7.12.7.1).

7.12.7.4 Location reporting

The MDF2 shall include the location information in the IRI messages sent over the LI_HI2 according to the service scoping received within the ListOfMediationDetails of the LI_X1 ActivateTask. For example, if service scoping does not allow the reporting of location to an LEMF, then the MDF2 shall not copy the location information if received in an xIRI to the IRI message sent to that LEMF.

The MDF2 shall also remove the location information (e.g. PANI header) from the SIP message contents included as a part of the IRI message, when the service scoping does not allow the reporting of location to the LEMF.

7.12.8 Generation of CC over LI_HI3

7.12.8.1 General

When xCC is received over LI_X3 from a CC-POI, the MDF3 shall deliver the CC over LI_HI3 to the LEMF according to the clause 5.5.3 of the present document without undue delay.

The MDF3 shall populate the threeGPP33128DefinedCC field with a CCPayload structure containing IMSCCPDU. The IMSCCPDUPayload shall contain the IPv4 or IPv6 packet received over LI_X3.

The MDF3 shall populate the timeStamp field of the ETSI TS 102 232-1 [9] PSHeader structure of CC with the xCC timeStamp and the Payload Direction of the CCPayload structure to reflect the value received on xCC. The LIID and CID fields shall correctly reflect the target identity and communication session to which the CC belongs.

7.12.8.2 Handling of multiple instances of list of mediation details

The MDF3 may have to deliver the received xCC to more than one LEMFs when more than one instances of ListOfMediationDetails are associated with a task (i.e. XID) provisioned at the MDF3. The MDF3 shall populate the LIID field in the CC delivered over the LI_HI3 accordingly.

7.12.8.3 Handling of additional XID related information

In addition to the XID present in the XID field of xCC, the MDF3 shall deliver a copy of the CC to the LEMFs represented in one or more instances of ListOfMediationDetails associated with the XID values present in the Additional XID Related Information received in the xCC.

7.12.8.4 SDP session description

The MDF3 shall deliver the SDP session description received in the xCC over LI_X3 using the SDPInfo element of the IMSCCPDU to the LEMF over LI_HI3. This shall be done each time the SDP Session Description is present on the xCC.

7.12.8.5 Mid-session activation for additional warrants at MDF3

When a new warrant is to be activated on a target identity (i.e. the associated IMS user is already the target of interception due to another warrant), the LIPF may use the same XID for the new warrant (e.g. when there is no need to receive two separate copies of xCC over LI_X3). In this case, the LIPF may activate the new warrant only at the MDFs using an LI_X1 ModifyTask message with a new instance of ListOfMediationDetails.

The MDF3 that receives a LI_X1 ModifyTask with a new instance of ListOfMediationDetails, shall deliver the CC to the LEMF represented in this new instance of ListOfMediationDetails upon the reception of next xCC from the CC-POI.

7.12.8.6 Media handling at the MDF and LEMF

The MDF and LEMF perform protocol level correlation between intercepted signalling and media. LI_T3 ensures that the SDP in the intercepted SIP signalling or in LI_X3 matches the IP/UDP destination IP-address and port for every intercepted RTP stream.

In a scenario where NAT is used, the protocol level correlation may not be possible. In all other scenarios the implementation shall ensure that it is.

To support the interception scenario where transmission of CC occurs before the IRI, the LEMF may use SDP Session Description field in the CC to process the media.