5.6 Origination procedures

23.2283GPPIP Multimedia Subsystem (IMS)Release 18Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.6.0 General

This clause presents the detailed application level flows to define the Procedures for session originations.

The flows presented in the clause assume the use of Policy and Charging Control for the establishment of QoS-Assured Sessions.

The session origination procedures specify the signalling path between the UE initiating a session setup attempt and the Serving‑CSCF that is assigned to perform the session origination service. This signalling path is determined at the time of UE registration, and remains fixed for the life of the registration.

A UE always has a proxy (P‑CSCF) associated with it. This P‑CSCF performs resource authorization, and may have additional functions in handling of emergency and priority sessions. The P‑CSCF is determined by the CSCF discovery process, described in clause 5.1.1 (Local CSCF Discovery).

As a result of the registration procedure, the P‑CSCF determines the next hop toward the Serving‑CSCF. This next hop is to the S‑CSCF in the home network (MO#1). These next-hop addresses could be IP addresses, or could be names that are translated via DNS to an IP address.

Sessions originated in the PSTN to a destination in an IMS network are a special case of the Origination procedures. The MGCF uses H.248 [18] to control a Media Gateway, and communicates with the SS7 network. The MGCF initiates the SIP request, and subsequent nodes consider the signalling as if it came from a S‑CSCF.

5.6.1 (MO#1) Mobile origination, roaming

This origination procedure applies to roaming users.

The UE is located in a visited network, and determines the P‑CSCF via the CSCF discovery procedure described in clause 5.1.1. The home network advertises the S‑CSCF as the entry point from the visited network.

When registration is complete, P‑CSCF knows the name/address of the next hop in the signalling path toward the serving‑CSCF.

Figure 5.14: Mobile origination procedure – roaming

Procedure MO#1 is as follows:

1. UE sends the SIP INVITE request, containing an initial SDP, to the P‑CSCF determined via the CSCF discovery mechanism. The initial SDP may represent one or more media for a multi-media session.

2. P‑CSCF remembers (from the registration procedure) the next hop CSCF for this UE.

This next hop is either the S‑CSCF that is serving the visiting UE.

P-CSCF determines whether the INVITE message requires priority handling based on user profile stored during the registration procedure and/or the priority requested by the user and/or MPS code/identifier included in the INVITE message. If the session is determined to require priority handling, then P-CSCF inserts/replaces the priority indication and forwards the INVITE to the S-CSCF.

3. S‑CSCF validates the service profile, if a GRUU is received as the contact, ensures that the Public User Identity of the served user in the request and the Public User Identity associated with the GRUU belongs to the same service profile, and invokes any origination service logic required for this user. This includes authorization of the requested SDP based on the user’s subscription for multi-media services. If the Request URI contains the SIP URI representation of an E.164 address then the procedure specified in clause 4.3.5.3 applies.

4. S‑CSCF forwards the request, as specified by the S-S procedures. When the INVITE message includes priority indication, the S-CSCF forwards the INVITE, including the Service User’s priority level if available.

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

6. S‑CSCF forwards the Offer Response message to P‑CSCF.

7. P‑CSCF instructs the PCRF/PCF to authorize the resources necessary for this session.

8. P‑CSCF forwards the Offer Response message to the originating endpoint.

9. UE decides the offered set of media streams for this session, confirms receipt of the Offer Response and sends the Response Confirmation to the P‑CSCF. The Response Confirmation may also contain SDP. This may be the same SDP as in the Offer Response received in Step 8 or a subset. If new media are defined by this SDP, a new authorization (as in Step 7) will be done following Step 14. The originating UE is free to continue to offer new media on this operation or on subsequent exchanges using the Update method. Each offer/answer exchange will cause the P‑CSCF to instruct the PCRF/PCF to repeat the Authorization step (Step 7) again.

10. 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 initiates the reservation procedures for the resources needed for this session after determining the needed resources in step 8 as shown in Figure 5.14. Otherwise, the IP‑CAN initiates the reservation of required resources after step 7.

11. P‑CSCF forwards the Response Confirmation to S‑CSCF.

12. S‑CSCF forwards this message to the terminating endpoint, as per the S-S procedure.

13-15. The terminating end point responds to the originating end with an acknowledgement. If Optional SDP is contained in the Response Confirmation, the Confirmation Acknowledge will also contain an SDP response. If the SDP has changed, the P‑CSCF validates that the resources are allowed to be used.

16-18. When the resource reservation is completed, UE sends the successful Resource Reservation message to the terminating endpoint, via the signalling path established by the INVITE message. The message is sent first to P‑CSCF.

19-21. The terminating end point responds to the originating end when successful resource reservation has occurred. If the SDP has changed, the P‑CSCF authorizes that the resources are allowed to be used.

22-24. Terminating end point may generate ringing and it is then forwarded via the session path to the UE.

25. UE indicates to the originating user that the destination is ringing.

26. When the destination party answers, the terminating endpoint sends a SIP 200-OK final response, as specified by the termination procedures and the S-S procedures, to S‑CSCF.

27. S‑CSCF sends a SIP 200-OK final response along the signalling path back to P‑CSCF.

28. P‑CSCF indicates that the media flows authorized for this session should now be enabled.

29. P‑CSCF sends a SIP 200-OK final response to the session originator.

30. UE starts the media flow(s) for this session.

31-33. UE responds to the 200 OK with a SIP ACK message sent along the signalling path.

5.6.2 (MO#2) Mobile origination, home

This origination procedure applies to users located in their home service area.

The UE is located in the home network, and determines the P‑CSCF via the CSCF discovery procedure described in clause 5.1.1. During registration, the home network allocates an S‑CSCF in the home network.

When registration is complete, P‑CSCF knows the name/address of S‑CSCF.

Figure 5.15: Mobile origination procedure – home

Procedure MO#2 is as follows:

1. UE#1 sends the SIP INVITE request, containing an initial SDP, to the P‑CSCF determined via the CSCF discovery mechanism. The initial SDP may represent one or more media for a multi-media session.

2. P‑CSCF remembers (from the registration procedure) the next hop CSCF for this UE. In this case it forwards the INVITE to the S‑CSCF in the home network.

3. S‑CSCF validates the service profile, if a GRUU is received as the contact, ensures that the Public User Identity of the served user in the request and the Public User Identity associated with the GRUU belong to the same service profile, and invokes any origination service logic required for this user. This includes authorization of the requested SDP based on the user’s subscription for multi-media services. If the Request URI contains the SIP representation of an E.164 address then the procedure specified in clause 4.3.5.3 applies.

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

6. S‑CSCF forwards the Offer Response message to P‑CSCF.

7. P‑CSCF instructs the PCRF/PCF to authorize the resources necessary for this session.

8. P‑CSCF forwards the Offer Response message to the originating endpoint.

9. UE decides the offered set of media streams for this session, confirms receipt of the Offer Response and sends the Response Confirmation to P‑CSCF. The Response Confirmation may also contain SDP. This may be the same SDP as in the Offer Response received in Step 8 or a subset. If new media are defined by this SDP, a new authorization (as in Step 7) will be done following Step 14. The originating UE is free to continue to offer new media on this operation or on subsequent exchanges using the Update method. Each offer/answer exchange will cause the P‑CSCF to repeat the Step 7 again.

10. 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 initiates resource reservation procedures for the offered media as shown in Figure 5.15. Otherwise, the IP‑CAN initiates the reservation of required resources after step 7.

11. P‑CSCF forwards this message to S‑CSCF.

12. S‑CSCF forwards this message to the terminating endpoint, as per the S-S procedure.

13-14. The terminating end point responds to the originating end with an acknowledgement. If Optional SDP is contained in the Response Confirmation, the Confirmation Acknowledge will also contain an SDP response. If the SDP has changed, the PCSCF authorizes the media.

15. PCSCF forwards the answered media towards the UE.

19-21. The terminating end point responds to the originating end when successful resource reservation has occurred. If the SDP has changed, the P‑CSCF again authorizes that the resources are allowed to be used.

22-24. 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 S‑CSCF per the S-S procedure. It is sent from there toward the originating end along the signalling path.

25. UE indicates to the originating user that the destination is ringing.

26-27. When the destination party answers, the terminating endpoint sends a SIP 200-OK final response along the signalling path to the originating end, as specified by the termination procedures and the S-S procedures, to S‑CSCF.

28. P‑CSCF indicates that the media flows authorized for this session should now be enabled.

29. P‑CSCF passes the 200-OK response back to UE.

30. UE starts the media flow(s) for this session.

31-33. UE responds to the 200 OK with an ACK message which is sent to P‑CSCF and passed along the signalling path to the terminating end.

5.6.3 (PSTN-O) PSTN origination

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.

Figure 5.16: PSTN origination procedure

The PSTN Origination procedure is as follows:

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.

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

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.

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

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

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.

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.

8. MGW reserves the resources needed for the session.

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

10. Terminating end point responds to the successful media resource reservation.

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.

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

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

14. MGCF forwards an ANM message to the PSTN.

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

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

This 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 [10a]. 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 clause 5.7.2. The same principles apply in roaming cases, i.e. analogous variants of MT#1 defined in clause 5.7.1 are also supported for interworking with SIP clients that do not support the required IMS procedures.

Figure 5.16a: Originating session from external SIP client

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

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.

NOTE 1: Whether the P‑CSCF should interact with PCRF/PCF in this step is based on operator policy.

4. P‑CSCF forwards the INVITE request to the UE.

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.

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

9. The UE accepts the session with a 200 OK response.

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

11-12. The 200 OK response is forwarded to the originating party.

13-15. The originating party acknowledges the session.

5.6.5 Application Server Origination Procedure

5.6.5.1 (AS-O) Origination at Application Server

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.

Figure 5.16b: Application Server origination procedure

Procedure for Application Server origination is as follows:

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 IETF RFC 3263 [44] (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.

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.

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.

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

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.

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.

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

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

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.

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.

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

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.

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.

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

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 clauses 5.5.1 and 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.

NOTE 1: If border control concepts are applied, the contact point within an operator’s network may be different, see clause 4.14 and Annex I for details.

NOTE 2: The procedure described below can be used by an external AS that cannot access HSS data using the Sh interface.

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:

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

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

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.

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.

NOTE 3: The HSS sends back the capabilities even if the Public User Identity/Public Service Identity is not registered and has no initial filter criteria related to the unregistered state.

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

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.

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.

NOTE 4: Optionally the S‑CSCF can omit the Cx-Put/Cx-Pull request if it has the relevant information from the user profile.

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.

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

NOTE 5: If the Public User Identity/Public Service Identity is not registered and has no initial filter criteria related to the unregistered state, the S‑CSCF just routes the request further without invoking any service logic for this request.

9. The session setup continues as for normal origination procedures.