A.1 MCID invocation

24.5163GPPMalicious Communication Identification (MCID)Protocol specificationPSTN/ISDN simulation servicesTISPANTS

The MCID invokes, in the destination, the storage of data.

Figure A.1 shows an example signalling flow for the scenario.

Figure A.1: MCID Permanent and triggered by the B user

The steps of the flow are as follows:

  1. INVITE request (to S-CSCF).

The INVITE request is sent from the UE to S-CSCF The INVITE includes a P-Asserted-Identity as follows:

P-Asserted-Identity: "John Doe" <tel:+1-212-555-1111> with Privacy: id or Privacy header or Privacy user.

  1. 100 (Trying) Response (from S-CSCF).
  2. Evaluation of initial filter criteria.

The initial Filter criteria identifies that the requested URI is subscribed to the MCID service. Therefore the S-CSCF forwards the INVITE to the MCID AS.

  1. INVITE request (S-CSCF to AS).

INVITE is send to the AS.

  1. 100 Response from S-CSCF.
  2. AS stores Data.

AS stores:

  • Request URI.
  • To header.
  • P-Asserted-Identity header.
  • From header.
  • Contact header.
  • Time and date.

7-12) INVITE request(S-CSCF to AS).

INVITE is send towards the UE:B.

A.2 Identity information not present in the initial request

Hereby, we show a PSTN to NGN scenario, but notice that any call, originated in the PSTN domain and being diverted before reaching the served user AS, must be treated in the same manner. The terminating AS sends a 18x provisional response previous to sending a SIP INFO message, which requests the information from the originating network. It can then route the call while waiting for an answer to the INFO request. Note that the 18x response is sent reliably, should not indicate ringing (should not be a 180 response), and contains no SDP. This 18x response establishes a early dialog, which is needed before the INFO request can be sent.

Figure A.2.1:MCID with Information Request towards the ISDN/PSTN

The Terminating AS will then wait for an INFO request containing the response to the information query in the previous INFO request. This message provides the requested identity. If such a message is not received within a period of time, the service cannot be provided.

Figure A.2.2: MCID with Information Response towards the ISDN/PSTN

A.3 MCID invocation in temporary mode

The MCID invokes, in the destination, the storage of data.

Figure A.3.1 shows an example signalling flow for the scenario.

Figure A.3.1: MCID Permanent and triggered by the B user

The steps of the flow are as follows:

1) INVITE request (to S-CSCF).

The INVITE request is sent from the UE to S-CSCF The INVITE includes a P-Asserted-Identity as follows:

P-Asserted-Identity: "John Doe" <tel:+1-212-555-1111> with Privacy: id or Privacy header or Privacy user.

2) 100 (Trying) Response (from S-CSCF).

3) Evaluation of initial filter criteria.

The initial Filter criteria identifies that the requested URI is subscribed to the MCID service. Therefore the S-CSCF forwards the INVITE to the MCID AS.

4) INVITE request (S-CSCF to AS).

INVITE is send to the AS.

5) 100 Response from S-CSCF.

6) Temporarily AS stores Data.

AS stores:

  • Request URI.
  • To header.
  • P-Asserted-Identity header.
  • From header.
  • Contact header.
  • Time and date.

7-12) INVITE request(S-CSCF to AS).

INVITE is send towards the UE:B.

NOTE: 180 Ringing is not shown.

13-18) UE-B takes the communication. A200 OK is sent towards UE-A.

19-22) UE-B initiates the temporary mode with sending a Re-INVITE.

23) The AS finally stores the regarding MCID data cached at step 6).

Annex B (informative):
Example of filter criteria

This annex provides an example of a filter criterion that triggers SIP requests that are subject to initial filter criteria evaluation.

The coding of the Initial Filter Criteria is described in TS 183 033 [9].