Content for TS 23.228 Word version: 18.5.0

1… 3… 4… 4.2.4… 4.3… 4.4… 4.13… 4.16… 5… 5.2… 5.3… 5.4… 5.4.7… 5.4.8… 5.4a… 5.5… 5.5.3… 5.6… 5.6.3… 5.7… 5.7.3… 5.7.5… 5.7.8… 5.8… 5.10… 5.11… 5.11.3… 5.11.3.3 5.11.3.4 5.11.4… 5.11.5… 5.11.5.3… 5.11.6… 5.12… 5.16… 5.16.2… 5.19… 5.20… A… E… E.2.2… G… G.5… H I… J… K… L… M… M.3… N… P… Q… Q.2.5… R… S… T… U… U.2… V… W… X… Y… Z… AA… AA.3… AB… AC… AC.7… AC.7.2… AC.7.2.2 AC.7.2.3… AC.7.4… AC.9…

5.6.3 (PSTN-O) PSTN origination 5.6.4 (NI-O) Non-IMS Origination procedure from an external SIP client 5.6.5 Application Server Origination Procedure 5.6.5.1 (AS-O) Origination at Application Server 5.6.5.3 S-CSCF selection by I-CSCF for AS Originating call procedures
...

5.6.3 (PSTN-O) PSTN origination p. 123

The MGCF in the IM CN subsystem is a SIP endpoint that initiates requests on behalf of the PSTN and Media Gateway. The subsequent nodes consider the signalling as if it came from a S-CSCF. The MGCF incorporates the network security functionality of the S-CSCF. This MGCF does not invoke Service Control, as this may be carried out in the GSTN or at the terminating S-CSCF.

Due to routing of sessions within the PSTN, this origination procedure will only occur in the home network of the destination subscriber. However, due to cases of session forwarding and electronic surveillance, the destination of the session through the IM CN subsystem may actually be another PSTN termination.

Reproduction of 3GPP TS 23.228, Fig. 5.16: PSTN origination procedure

Figure 5.16: PSTN origination procedure

The PSTN Origination procedure is as follows:

Step 1.

The PSTN establishes a bearer path to the MGW, and signals to the MGCF with a IAM message, giving the trunk identity and destination information.

Step 2.

The MGCF initiates a H.248 command, to seize the trunk and an IP port.

Step 3.

The MGCF initiates a SIP INVITE request addressed to a tel URI or, if directed by operator's local policy, to a SIP URI (using an E.164 address in the user portion and the setting user=phone), includes an initial SDP in the INVITE request, and forwards the request to a configured I-CSCF, as per the proper S-S procedure. If configured through policies, the MGCF adds to the SIP INVITE attestation information based on the trunk identity or other sources of the request.

Step 4.

The media stream capabilities of the destination are returned along the signalling path, per the S-S procedures.

Step 5.

MGCF initiates a H.248 command to modify the connection parameters and instruct the MGW to reserve the resources needed for the session.

Step 6.

MGCF decides the offered set of media streams for this session, confirms receipt of the Offer Response and sends the Response Confirmation per the S-S procedures.

Step 7.

Terminating end point responds to the Response Confirmation. If Optional SDP is contained in the Response Confirmation, the Confirmation Acknowledge will also contain an SDP response.

Step 8.

MGW reserves the resources needed for the session.

Step 9.

When the resource reservation is completed, MGCF sends the successful Resource Reservation message to the terminating endpoint, per the S-S procedures.

Step 10.

Terminating end point responds to the successful media resource reservation.

Step 11.

The destination endpoint may optionally perform alerting. If so, it signals this to the originating party by a provisional response indicating Ringing. This message is sent to MGCF per the S-S procedure.

Step 12.

If alerting is being performed, the MGCF forwards an ACM message to PSTN.

Step 13.

When the destination party answers, the terminating and S-S procedures result in a SIP 200-OK final response being sent to MGCF.

Step 14.

MGCF forwards an ANM message to the PSTN.

Step 15.

MGCF initiates a H.248 command to alter the connection at MGW to make it bi-directional.

Step 16.

MGCF acknowledges the SIP final response with a SIP ACK message.

5.6.4 (NI-O) Non-IMS Origination procedure from an external SIP client |R6| p. 124

This sub clause describes the session setup procedures when originating from an external SIP client that doesn't support the required IMS SIP extensions, towards an IMS UE.

An incoming SIP request may arrive, where the UE detects that the originating party does not support the IMS SIP extensions described in TS 24.229. If the external SIP client does not support the Precondition extension of SIP, the UE continues to setup the session without activating media transfer until the session has been accepted.

Figure 5.16a shows an example of an end-to-end session setup in such a case.

For illustration purposes these session flows show the case of a non-roaming termination. This flow is a variant of MT#2 defined in sub clause 5.7.2. The same principles apply in roaming cases, i.e. analogous variants of MT#1 defined in sub clause 5.7.1 are also supported for interworking with SIP clients that do not support the required IMS procedures.

Reproduction of 3GPP TS 23.228, Fig. 5.16a: Originating session from external SIP client

Figure 5.16a: Originating session from external SIP client

Step 1-2.

A session request arrives at the UE in the IMS network with media information but without requiring precondition capability.

Step 3.

P-CSCF examines the media parameters. If P-CSCF finds media parameters not allowed to be used within an IMS session (based on P-CSCF local policies, or if available bandwidth authorization limitation information coming from the PCRF/PCF), it rejects the session initiation attempt.

Step 4.

P-CSCF forwards the INVITE request to the UE.

Step 5.

Depending on the bearer establishment mode selected for the IP-CAN session, resource reservation shall be initiated either by the UE or by the IP-CAN itself. The UE begins the resource reservation according to the session and media parameters as shown in Figure 5.16a. Otherwise, the IP-CAN initiates the reservation of required resources after step 10.

Step 6-8.

Ringing information is sent end to end towards the originating party. These steps may proceed in parallel with step 5.

Step 9.

The UE accepts the session with a 200 OK response.

Step 10.

Based on operator policy the P-CSCF may instruct the PCRF/PCF to authorize the resources necessary for this session.

Step 11-12.

The 200 OK response is forwarded to the originating party.

Step 13-15.

The originating party acknowledges the session.

5.6.5 Application Server Origination Procedure |R6| p. 126

5.6.5.1 (AS-O) Origination at Application Server |R7| p. 126

This origination procedure applies to an Application Server that initiates a session on behalf of a user or a Public Service Identity. If the AS initiates the session on behalf of a user, the user may be an IMS user (i.e. referred to by a Public User Identity) or a non-IMS user (i.e. with no profile in the HSS, e.g. a PSTN user). It will be referred as a non-IMS user. If the AS initiates the session on behalf of a user, the identity-related fields of the initial request are populated the same way as if the request was originated by the user himself.

In the case of originating unregistered procedures, the handling of the S-CSCF in the HSS will follow the same principle as terminating unregistered user handling.

In the case of originating unregistered procedures, the S-CSCF shall execute any unregistered origination service logic before forwarding requests from an AS on behalf of an IMS user (i.e. referred to by a Public User Identity) or a Public Service Identity, as specified by the S-S procedures. In order to allow an AS to retrieve the S-CSCF name via Sh interface the S-CSCF may keep its name in the HSS for Public User Identities that have services related to the unregistered state.

AS shall contact the S-CSCF only in the case that it has the knowledge of the serving S-CSCF based, e.g. on Sh query or third party registration. Otherwise, AS shall contact an I-CSCF to continue the session initiation.

The procedure described below assumes that the Application Server takes care of the user plane connection.

Reproduction of 3GPP TS 23.228, Fig. 5.16b: Application Server origination procedure

Figure 5.16b: Application Server origination procedure

Procedure for Application Server origination is as follows:

Step 1.

The AS may proceed in either of the following ways:

If the session requires the use of a S-CSCF and:
- If the AS has acquired the address of the S-CSCF (if not available already) for the Public User Identity or the Public Service Identity on whose behalf the AS intends to originate the session, e.g. through Sh interface or based on third party registration, the AS sends the session initiation request to the S-CSCF (see step 2a)
- If the AS could not acquire a S-CSCF address for the Public User Identity or the Public Service Identity, the AS sends the session initiation request to an I-CSCF (see step 2d).
If the Public Service Identity on whose behalf the AS intends to generate the session does not require the use of a S-CSCF or if the user on whose behalf the AS intends to generate the session is a non-IMS user:
- If the AS supports routing capabilities (e.g. ENUM support, etc.), the AS sends the session initiation request directly towards the terminating network. In this case the AS may use the principles defined in RFC 3263 (see step 2b) to route the session initiation request.
- If the AS doesn't support routing capabilities, the AS shall send the session initiation request to the IMS Transit Functions (see step 2c). The IMS Transit Functions routes the session initiation request to the destination as described in clause 5.19.

Step 2a.

The AS sends the SIP INVITE request, containing an initial SDP, to the S-CSCF.

The initial SDP may represent one or more media for a multi-media session.

Step 2b.

The AS sends the SIP INVITE request, containing an initial SDP, to the terminating network.

The subsequent steps assume that the session initiation procedure involves the S-CSCF, i.e. they show the continuation of step 2a.

Step 2c.

The AS sends the SIP INVITE request, containing an initial SDP, to the IMS Transit Functions.

Step 2d.

The AS sends the SIP INVITE request, containing an initial SDP, to an I-CSCF indicating that it is an originating request. The I-CSCF selects the S-CSCF and forwards the SIP INVITE to that S-CSCF for further process. If the request is sent on behalf of the unregistered user, the procedure is described in clause 5.6.5.3.

Step 3.

S-CSCF identifies the incoming request as an originating request, and invokes any origination service logic required for this Public User Identity / Public Service Identity. The S-CSCF handles the incoming request as an authenticated and authorized request, as it was originated by a trusted entity within the network. If the Request-URI contains the SIP representation of a telephone number then the procedure specified in clause 4.3.5.3 applies.

Step 4.

S-CSCF forwards the request, as specified by the S-S procedures.

Step 5-6.

The media stream capabilities of the destination are returned along the signalling path.

Step 7-8.

The AS decides the offered set of media streams for this session, confirms receipt of the Offer Response and sends the Response Confirmation along the signalling path towards the destination network. The Response Confirmation may also contain SDP. This may be the same SDP as in the Offer Response or a subset. The AS is free to continue to offer new media on this operation or on subsequent exchanges using the Update method.

Step 9-10.

The terminating end point responds to the originating end with an acknowledgement, which is forwarded along the session signalling path. If Optional SDP is contained in the Response Confirmation, the Confirmation Acknowledge will also contain an SDP response.

Step 11-12.

The terminating endpoint responds to the originating end when successful resource reservation has occurred.

Step 13-14.

The destination UE may optionally perform alerting. If so, it signals this to the originating party by a provisional response indicating Ringing. This message is sent to the AS along the signalling path.

Step 15-16.

When the destination party answers, the terminating endpoint sends a SIP 200-OK final response along the signalling path to the originating end.

Step 17-18.

The AS responds to the 200 OK with an ACK message which is passed along the signalling path to the terminating end.

5.6.5.2 Void

5.6.5.3 S-CSCF selection by I-CSCF for AS Originating call procedures |R7| p. 128

In Figure 5.16c below the AS has no information of the serving S-CSCF, and therefore the AS sends the request to an I-CSCF as the entry point of the home network of the Public User Identity or the Public Service Identity. The AS finds an I-CSCF by using the same mechanism as the S-CSCF uses to find an I-CSCF of the terminating network (see clause 5.5.1 and clause 5.5.2). The request shall indicate that it is an originating request sent on behalf of the Public User Identity or the Public Service Identity.

The procedure described below assumes that the Application Server takes care of the user plane connection.

This is shown by the information flow in Figure 5.16c:

Reproduction of 3GPP TS 23.228, Fig. 5.16c: S-CSCF selection by I-CSCF for AS Originating call procedure

Figure 5.16c: S-CSCF selection by I-CSCF for AS Originating call procedure

Step 1.

The I-CSCF receives an INVITE message indicating that it is an AS originating procedure.

Step 2.

The I-CSCF queries the HSS for current location information of the Public User Identity/Public Service Identity on whose behalf the request is sent.

Step 3.

The HSS either responds with the required S-CSCF capabilities which the I-CSCF should use as an input to select a S-CSCF or provides the I-CSCF with the previously allocated S-CSCF name for that user or service.

Step 4.

If the I-CSCF has not been provided with the location of the S-CSCF, the I-CSCF selects a S-CSCF.

Step 5.

The I-CSCF forwards the INVITE request to the S-CSCF. The I-CSCF must indicate that it is an originating request sent on behalf of the Public User Identity/Public Service Identity.

Step 6.

The S-CSCF sends Cx-Put/Cx-Pull (Public User Identity/Public Service Identity, S-CSCF name) to the HSS. When multiple and separately addressable HSSs have been deployed by the network operator, then the S-CSCF needs to query the SLF to resolve the HSS. The HSS stores the S-CSCF name for Public Service Identity or Public User Identities of that user. This will result in all traffic related to the Public Service Identity or the Public User Identities of that user being routed to this particular S-CSCF until the registration period expires or the user attaches the Public User Identity to the network.

Step 7.

The HSS shall store the S-CSCF name for that user or service and return the information flow Cx-Put Resp/Cx-Pull Resp (user information) to the S-CSCF. The S-CSCF shall store it.

Step 8.

The S-CSCF invokes whatever service logic is appropriate for this call attempt, if required.

Step 9.

The session setup continues as for normal origination procedures.