In order to perform the interception of incoming calls from a particular origination point (identified as target with Non-Local ID for incoming calls), calling party information and redirecting party information of the incoming message are checked. The redirecting information is checked because the call may have encountered a call forwarding before arriving at the CSP where the interception for Non-Local ID is performed.
In the CS domain, this could be the Calling Party Information and Redirecting Party Information present in the IAM message (as an example) that is received at the switch where the interception is performed.
In the case of IMS-based VoIP calls, this can be any of the SIP headers used to identify the calling party information and redirecting party information present in the incoming SIP message. The examples are: P-Asserted Id, From headers and History-Info, Diversion headers. The interception functions may be provided by the S-CSCF or P-CSCF (optional in a non-roaming case and mandatory in the roaming case when LBO approach is used as the roaming architecture). Alternatively, in another implementation, the interception functions may also be provided by the Ingress IBCF or Ingress MGCF for non-roaming case. Of the two approaches S-CSCF/P-CSCF Vs IBCF/MGCF used for non-roaming case, only one approach is required to be supported within a CSP's network.
The Figure I.4 shows an example where the interception is done at the S-CSCF. The Figure I.5 shows an example where the interception is done at the P-CSCF in a roaming case with LBO as the roaming architecture. In both illustrations, Party-A is the target with Non-Local ID and the nature of the interception to be performed is for incoming calls. In the call, the P-Asserted-Id, From headers point to Party-A. There are no History-Info or Diversion headers in the examples.
Figure I.4: IRI ICE at S-CSCF - interception of a target with Non-Local ID for incoming calls
Figure I.4 shows the case where S-CSCF is the IRI ICE and hence, the S-CSCF checks the P-Asserted-Id and From headers of SIP message that it receives from the I-CSCF. Since a match is found, S-CSCF would perform the interception. In the event, multiple S-CSCF are involved in the signalling path (due to call forwarding case), all S-CSCFs may to do the same check and all S-CSCFs may end up finding a match to the target's Non-Local ID. Special care will have to be taken to suppress the duplicate interception of one LI request. When a call forwarding is involved, the subsequent S-CSCF may see History-Info or Diversion headers present, however, none of those are expected to match the Non-Local ID of the target. As in the case of interception of target with Local ID, a P-CSCF may optionally provide the IRI ICE functions in a non-roaming case. However, in a roaming case with LBO as the roaming architecture, P-CSCF provides the IRI ICE functions.
Figure I.5: IRI ICE at P-CSCF (roaming) - interception of a target with Non-Local ID for incoming calls
In Figure I.5, the P-CSCF in the VPLMN checks the P-Asserted-Id, From headers and History-Info and Diversion headers of the SIP message that it receives. Since a match is found for P-Asserted-Id and From header values, P-CSCF would perform the interception.
I.3.3 Interception at the IBCF/MGCF Word‑p. 366
The Figure I.6 shows an example where the interception is done at the IBCF or MGCF in a non-roaming case. In the illustration, Party-A is the target with Non-Local ID and the nature of the interception to be performed is for incoming calls. In the call, the P-Asserted-Id and From headers point to Party-A. There are no History-Info or Diversion headers in the example.
Figure I.6: IRI ICE at BCF - interception of a target with Non-Local ID for incoming calls
Figure I.6 shows the case where the Ingress IBCF or MGCF is the IRI ICE for intercepting when the target is identified with a Non-Local ID. Accordingly, the IBCF or MGCF checks the P-Asserted-Id, From headers, and History-Info, Diversion headers of SIP message. Since MGCF is providing signalling conversion (e.g., ISUP to SIP and Vice-Versa), the MGCF checks the headers of the SIP message it sends out. IBCF could check the headers from either of the SIP messages (they have to be the same anyway). Alternatively, the MGCF could also check the Calling Party Information and Redirecting Information present in the IAM message that it receives.