Content for  TS 33.128  Word version:  18.6.0

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.

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).

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.

In addition, the IRI-POI in the alternate deployment option (TS 33.127) 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.

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 TS 24.341. 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 TS 24.341. 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 TS 24.341.
• 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 TS 24.341.
• 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.

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.

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.

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.

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.

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.

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

• 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.

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.

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.

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

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.

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

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:

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.

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.

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 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.

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).
  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 Table 7.12.5.2.2-4 and Table 7.12.5.2.2-5.

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.

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 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 the first 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.

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.

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 to any of the events except the last two in the above list occurs. 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 Table 7.12.5.2.2-7 and Table 7.12.5.2.2-8.

Table 7.12.5.2.2-5 and Table 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.

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.

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 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.
• 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 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.

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:

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.
• 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.

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 on both sides. The outgoing media streams will be destined to the IP address and UDP port number specified as the target identifiers.