7 Roles for call origination
24.2923GPPIP Multimedia (IM) Core Network (CN) subsystem Centralized Services (ICS)Release 17Stage 3TS
7.1 Introduction
This clause specifies the procedures for call origination for when an ICS UE originates a session, establishing the service control signalling path either over the Gm interface or the I1 interface, and when a non-ICS UE originates a session achieving IMS service control via an MSC server enhanced for ICS. The associated procedures for the SCC AS and MSC server enhanced for ICS are also specified in this clause.
Subclause A.4 provides examples of signalling flows for call origination.
7.2 ICS UE
7.2.1 General
This clause specifies the procedures for call origination by an ICS UE.
Annex A.4 gives examples of signalling flows for call origination.
7.2.2 ICS UE using Gm
There are no ICS specific requirements for the origination of calls that may be subject to ICS.
If ICS is enabled for the UE then when the ICS UE originates a call using Gm reference point, the ICS UE shall:
a) send a SIP INVITE request towards the IM CN subsystems as specified in 3GPP TS 24.229 [11]. The ICS UE shall populate the SIP INVITE request as follows:
i) include in the Contact header field:
– a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [11] if a GRUU was received at registration;
– g.3gpp.ics media feature tag set to" principal";
ii) the SDP payload, as follows:- SDP proposing an audio stream over a circuit-switched bearer in accordance with subclause 7.2.5;
– an indication that the related local preconditions for QoS are not met as specified in 3GPP TS 24.229 [11]; and
– if a video stream is also to be transferred, then SDP payload proposing a video stream over a circuit-switched bearer in accordance with subclause 7.2.7;
b) when the ICS UE receives a reliable SIP 1xx provisional response from the network including a PSI DN number, the ICS UE shall setup a CS call in accordance with subclause 7.2.6; and
c) when the CS resources are available to the UE, the ICS UE shall send an SDP offer including an indication that the related local preconditions for QoS for audio as met as specified in 3GPP TS 24.229 [11].
When the ICS UE originates a non-CS bearer call using Gm reference point, the ICS UE shall act in accordance with 3GPP TS 24.229 [11].
7.2.3 ICS UE using CS
The ICS UE shall implement the call origination towards SCC AS suitable for ICS via CS domain as specified in 3GPP TS 24.008 [7] for 3GPP systems.
7.2.4 ICS UE using I1
In the present document, "I1 is enabled for the ICS UE" refers to all of the following conditions:
– the ICS MO ICS_Capabilities_Enabled leaf node (see 3GPP TS 24.286 [43]) is set to enabled;
– the UE is an ICS UE compliant with 3GPP TS 24.294 [11B];
– the ICS MO I1_Capabilities_Enabled leaf node (see 3GPP TS 24.286 [43]) indicates that IMS Centralised Services capabilities over I1 are enabled if simultaneous use of CS RAT and PS RAT is not supported; and
– the inability of simultaneous use of a CS bearer and use of PS for the service control signalling path.
If the ICS MO I1_Capabilities_Enabled leaf node (see 3GPP TS 24.286 [43]) indicates that IMS Centralised Services capabilities over I1 are disabled for this ICS UE or if the ICS MO I1_Capabilities_Enabled leaf node is absent, the ICS UE shall not follow procedures as defined in 3GPP TS 24.294 [11B].
If I1 is enabled for the ICS UE and the ICS UE originates an I1 session using the I1 reference point, the ICS UE shall:
1) generate an I1 Invite message toward the SCC AS in accordance with subclause 6.2.1.2.1.2 in 3GPP TS 24.294 [11B]; and
2) select the transport layer protocol depending on the access network type, and forward the I1 Invite message toward the SCC AS.
When the ICE UE receives an I1 Progress with progress reason set to Call progressing act in accordance with subclause 6.2.1.2.1.3 in 3GPP TS 24.294 [11B].
When the ICS UE receives an I1 Progress with progress reason set to ringing act in accordance with subclause 6.2.1.2.1.4 in 3GPP TS 24.294 [11B].
When the ICS UE receives an I1 Success message, the ICS UE shall act in accordance with subclause 6.2.1.2.1.5 in 3GPP TS 24.294 [11B]..
7.2.5 SDP for ICS UE proposing using a CS audio stream
When the ICS UE proposes an audio stream over a circuit-switched bearer the ICS UE shall include an SDP payload as described by IETF RFC 7195 [36], as follows:
– a "c=" line with the nettype portion set to "PSTN" and the addrtype portion and connection-address portions both set to "-";
– a CS media "m=" line with the media portion set to "audio", port portion set to "9", proto portion set to "PSTN" and fmt portion set to "-";
– an a=setup attribute set to "active";
– an a=cs-correlation attribute set to "callerid" along with the MSISDN, of ICS UE in the CS domain, in international E.164 number format; and
– an a=connection attribute set to "new".
7.2.6 ICS UE setting up a CS call
When the ICS UE needs to establish a CS call, the ICS UE shall send a SETUP message in accordance with 3GPP TS 24.008 [7] for 3GPP systems. The ICS UE shall populate the SETUP message for 3GPP systems as follows:
i) the called party BCD number information element set to the SCC AS PSI DN received in the SDP body of the SIP 1xx provisional response, in the connection-address portion of the "c=" line, appended to the "PSTN" nettype portion as described in IETF RFC 7195 [36]; and
ii) Type Of Number is set to "International" and Numbering Plan Indicator set to "E.164" in the Called Party BCD Number information element.
7.2.7 SDP for ICS UE proposing using a CS video stream
When the ICS UE proposes a video stream over a circuit-switched bearer the ICS UE shall include an SDP payload as described by IETF RFC 7195 [36], as follows:
– a "c=" line with the nettype portion set to "PSTN" and the addrtype portion and connection-address portions both set to "-";
– a CS media "m=" line with the media portion set to "video", port portion set to "9", proto portion set to "PSTN" and fmt portion set to "-";
– an a=setup attribute set to "active";
– an a=cs-correlation attribute set to "callerid" along with the MSISDN, of ICS UE in the CS domain, in international E.164 number format; and
– an a=connection attribute set to "new".
7.3 MSC Server enhanced for ICS
The MSC server enhanced for ICS shall implement call origination towards the SCC AS as specified in 3GPP TS 29.292 [24] with the following addition:
– the Contact header of the SIP INVITE request shall include the g.3gpp.ics media feature tag set to "server";
– include the P-Access-Network-Info header field in the SIP INVITE request as specified in 3GPP TS 24.229 [11]. The P-Access-Network-Info header field shall contain:
a) an access-type field set to "3GPP-GERAN", "3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD", or an access-class field set to"3GPP-GERAN", "3GPP-UTRAN;
b) if available, a "cgi-3gpp" or "utran-sai-3gpp" parameter;
c) if available, a "local-time-zone" parameter;
d) a "network-provided" parameter; and
e) if available, a "daylight-saving-time" parameter;
– if:
a) the UE is roaming;
b) the MSC server is not in the home network; and
c) an agreement exists with the home network operator (as identified by the bottom most URI in the list of URIs received in the Service-Route header field during the last successful registration or re-registration) to support Roaming Architecture for Voice over IMS with Local Breakout;
the MSC server may:
i) insert in the Feature-Caps header field, specified in IETF RFC 6809 [48], of the SIP INVITE request the "+g.3gpp.trf" header field parameter with the parameter value set to the URI of the desired TRF; and
ii) if the MSC server supports indicating the traffic leg as specified in IETF RFC 7549 [50] and if required by local policy, the MSC server may append an "iotl" SIP URI parameter in the "+g.3gpp.trf" header field parameter with a value set to "homeA-visitedA" to the TRF URI;
– if:
a) the UE is roaming;
b) the MSC server is not in the home network; and
c) an agreement exists with the home network operator (as identified by the bottom most URI in the list of URIs received in the Service-Route header field during the last successful registration or re-registration) to provide access to MRF resources from the visited network;
the MSC server may insert in the Feature-Caps header field, specified in IETF RFC 6809 [48], of the SIP INVITE request the "+g.3gpp.mrb" header field parameter with the parameter value set to the URI of the desired MRB; and
– if:
a) the UE is roaming;
b) the MSC server support indicating the traffic leg as specified in IETF RFC 7549 [50]; and
c) required by local policy;
then the MSC server may:
a) if the bottommost URI does not contain the "tokenized-by" header field parameter and an "iotl" SIP URI parameter is not already included, append the "iotl" SIP URI parameter with a value set to "visitedA-homeA" to the URI of the bottommost Route header field; and
b) if the bottommost URI contains the "tokenized-by" header field parameter and an "iotl" SIP URI parameter is not already included, append the "iotl" SIP URI parameter with a value set to "visitedA-homeA" to the URI of the second Route header field from the bottom.
NOTE: The bottommost Route header field contains the "iotl" SIP URI parameter if the S‑CSCF added the "iotl" SIP URI parameter in the Service-Route header field during registration and if the home network does not apply topology hiding. The second Route header field from the bottom contains the "iotl" SIP URI parameter if the S‑CSCF added the "iotl" SIP URI parameter in the Service-Route header field during registration and if the home network applied topology hiding.
7.4 SCC AS
7.4.1 General
The following subclauses describe the procedures at the SCC AS for call origination. In such scenarios, the SCC AS serves the originating ICS UE. The SCC AS shall follow procedures specified in 3GPP TS 24.229 [11] with the additional procedures described in this specification in subclauses 7.4.2 and 7.4.3. These subclauses describe the procedures for the SCC AS when using service control over Gm and CS, respectively.
7.4.2 SCC AS for service control over Gm
7.4.2.1 CS bearer is requested by the ICS UE
When the SCC AS receives an initial SIP INVITE request from the ICS UE due to initial filter criteria, the SCC AS shall:
1) store the information received in the SIP INVITE request, including the Request-URI, P-Asserted-Identity header field, Accept header field, Call-ID header field, To and From header fields including tags, Contact header field including associated media feature tags, Accept-Contact header field, the Record-Route header field(s), and the received non-audio SDP information;
1A) construct a Route header field(s) from the Record-Route header field(s) that was received in the initial SIP INVITE request, and save the constructed Route header field(s) for inclusion in the subsequent in dialog requests sent towards the ICS UE;
2) if the SDP contains:
i) a "c=" line with nettype portion set to "PSTN" as described in IETF RFC 7195 [36];
ii) a CS media "m=" line with media portion set to audio, port portion set to "9" and nettype portion set to "PSTN" as described in IETF RFC 7195 [36]; and
NOTE: If both i) and ii) are true, the ICS UE is requesting that the media bearer is to be set up over the CS domain.
iii) an a=setup attribute set to "active" and an a=connection attribute set to "new"; and
iv) an a=cs-correlation attribute set to "callerid" along with the MSISDN, of the ICS UE in the CS domain, in international E.164 number format
then the SCC AS shall send a SIP 183 (Session Progress) response towards the originating ICS UE in accordance with 3GPP TS 24.229 [11] with the following additions:
i) an SDP answer, in accordance with IETF RFC 7195 [36], containing a "c=" line with the nettype portion set to "PSTN" and with the addrtype portion set to "E164" and the fmt portion set to a SCC AS PSI DN, in international E.164 number format. The SCC AS PSI DN that identifies the stored information in step 1) and associated with the SCC AS;
ii) an a=setup attribute set to "passive";
iii) an a=connection attribute set to "new";
iv) an a=cs-correlation attribute set to "callerid"; and
v) indicate local preconditions not met.
3) When the SCC AS receives an initial SIP INVITE request with the Request-URI containing a valid SCC AS PSI DN encoded as a tel URI (see IETF RFC 3966 [42]) or SIP URI with the "user" SIP URI parameter set to "phone", in accordance with 3GPP TS 23.003 [4], subclause 13.5 as allocated in the above step 2 and with the P-Asserted-Identity header field containing the E.164 number received in the a=cs-correlation attribute contained in the SDP offer in the SIP INVITE request received from the ICS UE then the SCC AS shall:
i) use the SCC AS PSI DN that was allocated in step 2 and E.164 number received in the a=cs-correlation attribute contained in the SDP offer from the SIP INVITE request received from the ICS UE to correlate the previously stored information against this session with the incoming SIP INVITE request.
ii) act as a routing B2BUA, and generate an initial SIP INVITE request toward the terminating UE and include the information received in the SIP INVITE received in step 1 with the following exceptions:
a) if a Privacy type of "id" is received in the SIP INVITE request received initial SIP INVITE request with the Request-URI containing the SCC AS PSI DN then the Privacy type shall be set to type of "id";
b) an SDP offer with the media that combines the stored SDP offer from the ICS UE received in the SIP INVITE request from the ICS UE and the SDP offer received in SIP INVITE request with the Request-URI containing the SCC AS PSI DN in accordance with the rules of IETF RFC 3264 [31];
c) replace the Record-Route header field(s) received in the initial SIP INVITE request with a new Record-Route header field that only contains a SIP URI pointing to the SCC AS; and
d) set the Contact header field to include the contents of the Contact header received in the received initial SIP INVITE request, except the g.3gpp.ics media feature tag.
Upon receiving a SIP 18x response from the remote UE the SCC AS shall:
1) send a SIP 18x response on the leg with the ICS UE. If the receiving response includes an SDP answer, the SIP 18x response shall include an SDP answer, and use a different dialog from that of the first SIP 183(Session Progress) response sent by the SCC AS;
1A) include in the SIP 18x response on the leg withsent the ICS UE the Contact header field that contains the contents of the Contact header received in the SIP 18x response from the terminating UE;
1B) include in the SIP 18x response sent on the leg with the ICS UE the Record-Route header field(s) that was constructed by the SCC AS adding its SIP URI to the saved Record-Route header field(s) that was received in the initial SIP INVITE request; and
2) send a SIP 18x response on the leg with the CS domain.
The SDP answers shall be in accordance with rules for SDP answer as specified in IETF RFC 3264 [31].
When the SCC AS is aware of that preconditions are met on all legs the SCC AS shall send a SIP UPDATE request towards the remote UE indicating that local preconditions are met.
Upon receiving a SIP 200 (OK) response from the remote UE, the SCC AS shall send a SIP 200 (OK) response on both the leg with the ICS UE and on the leg with the CS domain. The SCC AS may, based on operator policy, include a Feature-Caps header field defined in IETF RFC 6809 [48] with a "+g.3gpp.ics" header field parameter as described in clause B.4. If the response includes an SDP answer, the SCC AS shall send an SDP answer on the leg with the ICS UE and on the leg with the CS domain. The SDP answers shall be in accordance with rules for SDP answer as specified in IETF RFC 3264 [31].
When the SCC AS has received a SIP ACK request on both the leg with the CS domain and on the leg with the ICS UE, the SCC AS shall respond to the initial SIP INVITE request with a final 200 (OK) response on the same dialog on which the second 18x was sent to the ICS UE.
7.4.2.2 Non CS bearer is requested by the ICS UE
When the SCC AS receives an initial SIP INVITE request due to initial filter criteria, which does not include a request for CS media, the SCC AS shall act as a routing B2BUA as described in 3GPP TS 24.229 [11].
7.4.3 SCC AS for service control over CS
When the SCC AS receives SIP INVITE request due to originating IMRN, the SCC AS shall:
NOTE 1: Allocation of the IMRN is outside the scope of this specification.
1) operate as an application server providing 3rd party call control, and specifically as an initiating B2BUA, as specified in subclause 5.7.5 of 3GPP TS 24.229 [11] for this request and all future requests and responses in the same dialog;
2) set the Request-URI of the outgoing initial SIP INVITE request to a tel-URI which represents the original called party number of the call as initiated in the CS domain. The tel-URI may be available from information associated with the received IMRN or from the History-Info header field;
3) set the To header field of the outgoing initial SIP INVITE request to a tel-URI which represents the original called party number of the call as initiated in the CS domain. The tel-URI may be available from information associated with the received IMRN or from the History-Info header field;
4) if the SCC AS has received a History-Info header field indicating only one diversion, not include the History-Info header field;
5) append the "orig" SIP URI parameter to the S-CSCF URI included in the Route header field of the outgoing initial SIP INVITE request;
6) set the P-Asserted-Identity header field of the outgoing SIP INVITE request and to a tel-URI which represents the calling party number of the call initiated in the CS domain. This is either available from information associated against the received IMRN or is the value as received in P-Asserted-Identity header field of the incoming SIP INVITE request; and
NOTE 2: It can happen that the P-Asserted-Identity header field is not included in the incoming SIP INVITE request.
7) if required and the SCC AS has the network provided location information available and a P-Access-Network-Info header field is not received, insert the P-Access-Network-Info header field as specified in 3GPP TS 24.229 [11] in the incoming SIP INVITE request. The P-Access-Network-Info header field shall contain:
a) an access-type field set to "3GPP-GERAN", "3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD", or an access-class field set to"3GPP-GERAN", "3GPP-UTRAN";
b) a "cgi-3gpp" or "utran-sai-3gpp" parameter;
c) if available a "local-time-zone" parameter;
d) if available a "daylight-saving-time" parameter; and
e) a "network-provided" parameter.
NOTE 2a: The method for determining User Location Information (e.g. CGI or SAI) and/or local Time Zone Information at the SCC AS is implementation dependant.
The SCC AS should in the outgoing SIP requests and SIP responses include the same values as received in the incoming SIP requests and SIP responses in all other header fields with the exception given in this subclause and in subclause 5.7.5 of 3GPP TS 24.229 [8].
The SCC AS will handle the Privacy header field in the outgoing SIP INVITE request in the following way. The SCC AS shall either:
– if a Privacy header field is received in the incoming INVITE request, include the Privacy header field as received in the incoming INVITE request; or
– if a value is associated to IMRN and indicates that the presentation of the calling party number is restricted in the CS domain, include a Privacy header field with the value set to "id".
On completion of the above procedure, the call is anchored in the SCC AS.
NOTE 3: After completion of anchoring the call in SCC AS, the allocated IMRN is available for reuse.
7.4.4 SCC AS for service control over I1
7.4.4.1 General
When the SCC AS receives an initial I1 Invite message from the ICS UE via the I1interface, the SCC AS shall:
1) perform the procedures in accordance with subclause 6.2.1.3.1.2 in 3GPP TS 24.294 [11B];
2) allocate the SCC AS PSI DN which is specified as an E.164 number, and shall identify the stored information in step 1) and associate with the SCC AS PSI DN;
3) generate and send an I1 Progress message with Reason set to 183 "Call Progress", in accordance with subclause 6.2.1.3.1.3 in 3GPP TS 24.294 [11B] towards the originating UE over the transport layer connection over which the I1 Invite message was received.
Subsequently, the SCC AS will wait for an initial SIP INVITE request from the CS domain (via MGCF) with the Request-URI set to the allocated SCC AS PSI DN, upon receiving the initial SIP INVITE request from the CS domain the SCC AS shall:
0) check that the Request URI is
i) set to a valid SCC AS PSI DN as allocated in the above step 2, and
ii) the SCC AS PSI DN is encoded as a tel URI (see IETF RFC 3966 [42]) or SIP URI with the "user" SIP URI parameter set to "phone", in accordance with 3GPP TS 23.003 [4], subclause 13.5;
If the SCC AS PSI DN is valid, the SCC AS shall:
1) and if Timer(s) as specified in 3GPP TS 24.294 [11B] subclause 7.5.3.2.1.2.2 has not expired use the received SCC AS PSI DN and correlate it with the information saved in step 1 above and the SCC AS PSI DN that was allocated in step 2 above;
2) act as a routing B2BUA, and generate an initial SIP INVITE request toward the remote UE. The SIP INVITE request shall include:
i) the information received in the initial I1 Invite message including the following additional information if the SCC AS received an I1 Invite containing:
a) an Accept Contact information element as specified in subclause 7.3.2.9 in 3GPP TS 24.294 [11B] insert the media feature tags as received into the Accept Contact header field of the outgoing SIP INVITE request;
b) a ER Accept Contact information element as specified in subclause 7.3.2.10 in 3GPP TS 24.294 [11B] insert the media feature tags as received into the Accept Contact header field of the outgoing SIP INVITE request with the addition that:
– if the E bit was set to "1" the SCC AS shall qualify the media feature tag with the preference "explicit"; and
– if the R bit was set to "1" the SCC AS shall qualify the media feature tag with the preference "require"; and
c) a Reject Accept information element as specified in subclause 7.3.2.11 in 3GPP TS 24.294 [11B] insert the feature tags as received into the Reject Contact header field of the outgoing SIP INVITE request;
d) if a Privacy type of "id" is received in the SIP INVITE request from the CS domain then the Privacy type shall be set to type of "id"; and
ii) an SDP offer with the media received in the SDP offer conveyed to the SCC AS in the SIP INVITE request received from the CS domain; and
3) send the generated initial SIP INVITE request toward the remote UE as specified in 3GPP TS 24.229 [11].
Upon receiving a SIP 18x response from the remote UE, the SCC AS shall send the SIP 18x response toward the CS domain. The response includes an SDP answer received from the remote UE.
If the SCC AS receives a SIP 180 (Ringing) response from the remote UE, the SCC AS shall send the SIP 180 (Ringing) response towards the CS domain. In addition, the SCC AS may send an I1 Progress message with Reason set to 180 "Ringing" toward the ICS UE over the I1 interface, in accordance with subclause 6.2.1.3.1.4 in 3GPP TS 24.294 [11B].
Upon receiving a SIP 200 (OK) response from the remote UE, the SCC AS shall send the SIP 200 (OK) response towards the CS domain. The SCC AS may, based on operator policy, include a Feature-Caps header field defined in IETF RFC 6809 [48] with a "+g.3gpp.ics" header field parameter as described in clause B.4. If the SIP 200 (OK) response includes an SDP answer, the SCC AS shall include the SDP answer in the SIP 200 (OK) response sent towards the CS domain.
Upon receving a SIP ACK request (indicating receipt of CONNECT ACKNOWLEDGEMENT in the CS domain) from the CS domain, the SCC AS shall send:
1) an I1 Success message in accordance with subclause 6.2.1.3.1.5 in 3GPP TS 24.294 [11B] toward the UE; and
2) a SIP ACK request towards the remote UE.
7.4.4.2 Failure handling
If the SCC AS receives a status line as specified in subclause 7.2 of IETF RFC 3261[45] with status code value 3xx to 6xx as specified in subclause 21.3-21.6 of IETF RFC 3261 [45], the SCC AS shall:
a) send an I1 Failure message in accordance with subclause 6.2.1.4 in 3GPP TS 24.294 [11B] toward the UE.