The LMISF-IRI extracts the SIP messages that it receives within the xCC from the BBIFF-U/BBIFF over the LI_X3_LITE_S.
On the originating end of a voice session, the LMISF-IRI examines the SIP message, the stored LI_X2_LITE record and the stored LI_X3_LITE_S record to check for the following:
-
Whether the calling party identity is a target.
-
Whether the called party identity is a target non-local ID.
On the terminating end of a voice session, the LMISF-IRI examines the SIP message, the stored LI_X2_LITE record and the stored LI_X3_LITE_S record to check for the following:
-
Whether the called party identity is a target.
-
Whether the calling party identity is a target non-local ID.
-
Whether the redirecting party identity is a target non-local ID.
The SIP headers used for identifying a calling party identity, called party identity, redirecting party identity can be same identities used by the IMS signaling functions with the following additions:
-
P-Preferred Identity as calling party identity.
When any of the conditions listed above are true, the LMISF-IRI concludes that target is involved in an IMS session that shall be intercepted. Accordingly, the LMISF-IRI generates the xIRIs and delivers the same to the MDF2 over the LI_X2.
For IMS-based voice services, if media interception is required, the LMISF-IRI sends a trigger for the same to the BBIFF-C/BBIFF over the LI_T1 interface.
When an IMS UE performs an IMS registration (using SIP REGISTER) request, the LMISF-IRI examines the following for a target match:
-
From header and To header of the SIP REGISTER when the target identity is IMPU.
-
SUPI or IMSI stored in the LI_X2_LITE record when the target identity is IMPI.
-
+sip.instance-id of Contact header of the SIP REGISTER when the target identity is PEIIMEI or IMEI.
The LMISF-IRI shall store the +sip.instance-id in the LI_X2_LITE_S record for later use.
When an IMS UE originates an IMS session (using SIP INVITE), the LMISF-IRI examines the following to verify for a target match:
-
P-Preferred 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.
-
SUPI or IMSI stored in the LI_X2_LITE record 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.
When an IMS UE receives an incoming IMS session (using SIP INVITE), the LMISF-IRI 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-Id, From header, History Info header and Diversion header present in the SIP header when the target identity is IMPU and target is non-local ID.
-
SUPI or IMSI stored in the LI_X2_LITE record 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.
LMISF-IRI 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. LMISF-IRI stores the SIP Call Id to associate the subsequent SIP messages received on the same session for a target match.
For subsequent SIP messages, the LMISF-IRI may use the stored LI_X3_LITE_S record to determine for a target match.
When the Service Type received in the LI_X1 provisioning is
"messaging", the LMISF-IRI examines the SIP MESSAGE for a target match as shown below:
-
For MO-SMS over IP, P-Preferred Identity header and From header present in the SIP MESSAGE when the target identity is IMPU.
-
For MO-SMS over IP, TP-DA field of SMS-SUBMIT within the Message-body of SIP MESSAGE when the target identity IMPU for target non-local ID.
-
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-SUBMIT within the Message-body SIP MESSAGE when the target identity IMPU for target non-local ID.
-
SUPI or IMSI stored in the LI_X2_LITE record 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.
LMISF-IRI 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.
The xIRIs generated at the LMISF-IRI shall be same as the xIRIs generated in the IRI-POIs present in the IMS signaling functions (see clause 7.12.4.12).
As defined in
TS 33.127 the LMISF-IRI generates the following xIRIs:
-
Encapsulated SIP message.
-
Start of interception with an established IMS session.
The xIRI CC Unavailable defined in
TS 33.127 for IMS-based services is not applicable to N9HR LI and S8HR LI. The encapsulated SIP message is sent using the xIRI IMSMessage record.
Further details of the xIRIs are defined in clause 7.12.4.12.