5.11.5 Session Redirection Procedures

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

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

5.11.5.0 General

This clause gives information flows for the procedures for performing session redirection. The decision to redirect a session to a different destination may be made for different reasons by a number of different functional elements, and at different points in the establishment of the session.

Three cases of session redirection prior to bearer establishment are presented, and one case of session redirection after bearer establishment.

These cases enable the typical services of "Session Forward Unconditional", "Session Forward Busy", "Session Forward Variable", "Selective Session Forwarding", and "Session Forward No Answer", though it is important to recognise that the implementation is significantly different from the counterparts in the CS domain.

5.11.5.1 Session Redirection initiated by S‑CSCF to IMS

One of the functional elements in a basic session flow that may initiate a redirection is the S‑CSCF of the destination user. The user profile information obtained from the HSS by the ‘Cx-pull’ during registration may contain complex logic and triggers causing session redirection. S‑CSCF#2 sends the SIP INVITE request to the I‑CSCF for the new destination (I‑CSCF#F in the diagram), who forwards it to S‑CSCF#F, who forwards it to the new destination.

In cases when the destination user is not currently registered in the IM CN subsystem, the I‑CSCF may assign a temporary S‑CSCF to invoke the service logic on behalf of the intended destination. This temporary S‑CSCF takes the role of S‑CSCF#2 in the following information flow.

The service implemented by this information flow is typically "Session Forward Unconditional", "Session Forward Variable" or "Selective Session Forwarding". S‑CSCF#2 may also make use of knowledge of current sessions in progress at the UE, and implement "Session Forwarding Busy" in this way.

This is shown in the following information flow:

Figure 5.36: Session redirection initiated by S‑CSCF to IMS

Step-by-step processing is as follows:

1. The SIP INVITE request is sent from the UE to S‑CSCF#1 by the procedures of the originating flow.

2. S‑CSCF#1 invokes whatever service logic is appropriate for this session setup attempt.

3. S‑CSCF#1 performs an analysis of the destination address, and determines the network operator to whom the destination subscriber belongs. The INVITE message is sent to an I‑CSCF for that operator.

4. I‑CSCF queries the HSS for current location information of the destination user.

5. HSS responds with the address of the current Serving CSCF (S‑CSCF#2) for the terminating user.

6. I‑CSCF forwards the INVITE request to S‑CSCF#2, who will handle the session termination.

7. S‑CSCF#2 invokes whatever service logic is appropriate for this session setup attempt. As a result of this service control logic, S‑CSCF#2 determines that the session should be redirected to a new destination URI within the IP Multimedia Subsystem. Based on operator policy and the user profile, S‑CSCF#2 may restrict the media streams allowed in the redirected session.

8. S‑CSCF#2 sends a SIP INVITE request to an I‑CSCF (I‑CSCF#F) for the network operator to whom the forwarded destination subscribes.

9. I‑CSCF#F queries the HSS (HSS#F) for current location information of the destination user.

10. HSS#F responds with the address of the current Serving CSCF (S‑CSCF#F) for the terminating user.

11. I‑CSCF forwards the INVITE request to S‑CSCF#F, who will handle the session termination.

12. S‑CSCF#F invokes whatever service logic is appropriate for this session setup attempt

13. S‑CSCF#F forwards the INVITE toward the destination UE, according to the procedures of the terminating flow.

14-19. The destination UE responds with the SDP message, and the session establishment proceeds normally.

5.11.5.2 Session Redirection to PSTN Termination (S‑CSCF #2 forwards INVITE)

Handling of redirection to a PSTN Termination where the S‑CSCF#2 forwards the INVITE is shown in the figure 5.37:

Figure 5.37: Session redirection to PSTN Termination (S‑CSCF #2 forwards INVITE)

Step-by-step processing is as follows:

1. The SIP INVITE request is sent from the UE #1 to S‑CSCF#1 by the procedures of the originating flow.

2. S‑CSCF#1 performs whatever service control logic is appropriate for this session setup attempt.

3. S‑CSCF#1 performs an analysis of the destination address, and determines the network operator to whom the subscriber belongs. The INVITE message is sent to an I‑CSCF for that operator.

4. I‑CSCF queries the HSS for current location information of the destination user.

5. HSS responds with the address of the current Serving CSCF (S‑CSCF#2) for the terminating user.

6. I‑CSCF forwards the INVITE request to S‑CSCF#2, who will handle the session termination.

7. S‑CSCF#2 invokes whatever service logic is appropriate for this session setup attempt. As a result of this service control logic, S‑CSCF#2 determines that the session should be redirected to a PSTN termination. S‑CSCF#2 determines that it wishes to remain in the path of the SIP signalling.

8. S‑CSCF#2 forwards the INVITE using the Serving to Serving procedures S-S#3 or S-S#4. The PSTN terminating flows are then followed.

9-12. The destination responds with the SDP message, and the session establishment proceeds normally.

5.11.5.2a Session Redirection to PSTN Termination (REDIRECT to originating UE#1)

The S‑CSCF of the destination user (S‑CSCF#2) may determine that the session is to be redirected to a PSTN Termination; e.g. CS-domain endpoint, or to the PSTN. For session redirection to PSTN termination where the S‑CSCF of the called party (S‑CSCF#2) wishes to use the SIP REDIRECT method, the S‑CSCF#2 will pass the new destination information (the PSTN Termination information) to the originator. The originator can then initiate a new session to the redirected to destination denoted by S‑CSCF#2. The originator may be a UE as shown in the example flow in figure 5.37a, or it may be any other type of originating entity as defined in clause 5.4a. The endpoint to which the session is redirected may be the PSTN as shown in figure 5.37a, or it may be any other type of terminating entity as defined in clause 5.4a. The originator may alternately receive a redirect from a non-IMS network SIP client. Only the scenario in which a call from a UE is redirected by S‑CSCF service logic to a PSTN endpoint is shown.

Handling of redirection to a PSTN Termination where the S‑CSCF#2 REDIRECTS to the originating UE#1 is shown in the figure 5.37a:

Figure 5.37a: Session redirection to PSTN Termination (REDIRECT to originating UE#1)

Step-by-step processing is as follows:

1. The SIP INVITE request is sent from the UE#1 to S‑CSCF#1 by the procedures of the originating flow.

2. S‑CSCF#1 invokes whatever service logic is appropriate for this session setup attempt.

3. S‑CSCF#1 performs an analysis of the destination address, and determines the network operator to whom the subscriber belongs. The INVITE message is sent to an I‑CSCF for that operator.

4. I‑CSCF queries the HSS for current location information of the destination user.

5. HSS responds with the address of the current Serving CSCF (S‑CSCF#2) for the terminating user.

6. I‑CSCF forwards the INVITE request to S‑CSCF#2, who will handle the session termination.

S‑CSCF#2 determines that it wishes to use the SIP REDIRECT method to pass the redirection destination information (the ‘redirected-to PSTN Termination’ information) to the originator (UE#1).

8. S‑CSCF#2 sends a SIP Redirect response to I‑CSCF with the redirection destination.

9. I‑CSCF sends a Redirect response to S‑CSCF#1, containing the redirection destination.

10. S‑CSCF#2 forwards the Redirect response to UE#1, containing the redirection destination

11. UE#1 initiates a session to the ‘redirected-to PSTN Termination’ according to the mobile origination procedures supported in the UE (e.g. CS, IMS).

5.11.5.3 Session Redirection initiated by S‑CSCF to general endpoint (REDIRECT to originating UE#1)

The S‑CSCF in the scenario above may determine that the session is to be redirected to an endpoint outside the IP MultiMedia System and outside the CS-domain. Examples of these destinations include web pages, email addresses, etc. It recognizes this situation by the redirected URI being other than a sip: URI or tel: URL.

In cases when the destination subscriber is not currently registered in the IM CN subsystem, the I‑CSCF may assign a temporary S‑CSCF to invoke the service logic on behalf of the intended destination. This temporary S‑CSCF takes the role of S‑CSCF#2 in the following information flow. For session redirection to a general endpoint where the S‑CSCF of the called party (S‑CSCF#2) wishes to use the SIP REDIRECT method, the S‑CSCF#2 will pass the new destination information to the originator. As a result the originator should initiate a new session to the redirected-to destination provided by S‑CSCF#2. The originator may be a UE as shown in the example flow in figure 5.38, an Application Server or a non-IMS network SIP client. The originator may also receive a redirect from a non-IMS network SIP client. Only the scenario in which the originating UE receives a redirect based on S‑CSCF service logic is shown.

Handling of redirection to a general URI is shown in the following information flow:

Figure 5.38: Session redirection initiated by S‑CSCF to general endpoint

Step-by-step processing is as follows:

1. The SIP INVITE request is sent from the UE to S‑CSCF#1 by the procedures of the originating flow.

2. S‑CSCF#1 invokes whatever service logic is appropriate for this session setup attempt.

3. S‑CSCF#1 performs an analysis of the destination address, and determines the network operator to whom the subscriber belongs. The INVITE message is sent to an I‑CSCF for that operator.

4. I‑CSCF queries the HSS for current location information of the destination user.

5. HSS responds with the address of the current Serving CSCF (S‑CSCF#2) for the terminating user.

6. I‑CSCF forwards the INVITE request to S‑CSCF#2, who will handle the session termination.

7. S‑CSCF#2 invokes whatever service logic is appropriate for this session setup attempt. As a result of this service control logic, S‑CSCF#2 determines that the session should be redirected to a new destination URI outside the IMS and outside the CS domain, i.e. other than a sip: URI or tel: URL.

8. S‑CSCF#2 sends a SIP Redirect response back to I‑CSCF, with redirection destination being the general URI.

9. I‑CSCF sends a Redirect response back to S‑CSCF#1, containing the redirection destination.

10. S‑CSCF#1 forwards the Redirect response back to UE#1.

11. UE#1 initiates the session to the indicated destination.

5.11.5.4 Session Redirection initiated by P‑CSCF

One of the functional elements in a basic session flow that may initiate a redirection is the P‑CSCF of the destination user. In handling of an incoming session setup attempt, the P‑CSCF normally sends the INVITE request to the destination UE, and retransmits it as necessary until obtaining an acknowledgement indicating reception by the UE.

In cases when the destination user is not currently reachable in the IM CN subsystem (due to such factors as roaming outside the service area or loss of battery, but the registration has not yet expired), the P‑CSCF may initiate a redirection of the session. The P‑CSCF informs the S‑CSCF of this redirection, without specifying the new location; S‑CSCF determines the new destination and performs according to clauses 5.11.5.1, 5.11.5.2, or 5.11.5.3 above, based on the type of destination.

This is shown in the following information flow:

Figure 5.39: Session redirection initiated by P‑CSCF

Step-by-step processing is as follows:

1. The SIP INVITE request is sent from the UE to S‑CSCF#1 by the procedures of the originating flow.

2. S‑CSCF#1 invokes whatever service logic is appropriate for this session setup attempt.

3. S‑CSCF#1 performs an analysis of the destination address, and determines the network operator to whom the subscriber belongs. The INVITE message is sent to an I‑CSCF for that operator.

4. I‑CSCF queries the HSS for current location information of the destination user.

5. HSS responds with the address of the current Serving CSCF (S‑CSCF#2) for the terminating user.

6. I‑CSCF forwards the INVITE request to S‑CSCF#2, who will handle the session termination.

7. S‑CSCF#2 invokes whatever service logic is appropriate for this session setup attempt.

8. S‑CSCF#2 forwards the INVITE request to P‑CSCF#2.

9. P‑CSCF#2 forwards the INVITE request to UE#2.

10. Timeout expires in P‑CSCF waiting for a response from UE#2. P‑CSCF therefore assumes UE#2 is unreachable.

11. P‑CSCF#2 generates an Unavailable response, without including a new destination, and sends the message to S‑CSCF#2.

12. S‑CSCF#2 invokes whatever service logic is appropriate for this session redirection. If the user does not subscribe to session redirection service, or did not supply a forwarding destination, S‑CSCF#2 may terminate the session setup attempt with a failure response. Otherwise, S‑CSCF#2 supplies a new destination URI, which may be a phone number, an email address, a web page, or anything else that can be expressed as a URI. Processing continues according to clauses 5.11.5.1, 5.11.5.2, or 5.11.5.3 above, based on the type of destination URI.

5.11.5.5 Session Redirection initiated by UE

The next functional element in a basic session flow that may initiate a redirection is the UE of the destination user. The UE may implement customer-specific feature processing, and base its decision to redirect this session on such things as identity of caller, current sessions in progress, other applications currently being accessed, etc. UE sends the SIP Redirect response to its P‑CSCF, who forwards back along the signalling path to S‑CSCF#1, who initiates a session to the new destination.

The service implemented by this information flow is typically "Session Forward Busy", "Session Forward Variable" or "Selective Session Forwarding".

This is shown in the following information flow:

Figure 5.40: Session redirection initiated by UE

Step-by-step processing is as follows:

1. The SIP INVITE request is sent from the UE to S‑CSCF#1 by the procedures of the originating flow.

2. S‑CSCF#1 invokes whatever service logic is appropriate for this session setup attempt.

3. S‑CSCF#1 performs an analysis of the destination address, and determines the network operator to whom the subscriber belongs. The INVITE message is sent to an I‑CSCF for that operator.

4. I‑CSCF queries the HSS for current location information of the destination user.

5. HSS responds with the address of the current Serving CSCF (S‑CSCF#2) for the terminating user.

6. I‑CSCF forwards the INVITE request to S‑CSCF#2, who will handle the session termination.

7. S‑CSCF#2 invokes whatever service logic is appropriate for this session setup attempt.

8. S‑CSCF#2 forwards the INVITE request to P‑CSCF#2.

9. P‑CSCF#2 forwards the INVITE request to UE#2.

10. UE#2 determines that this session should be redirected, and optionally supplies the new destination URI. This new destination URI may be a phone number, an email address, a web page, or anything else that can be expressed as a URI. The Redirect response is sent to P‑CSCF#2.

11. P‑CSCF#2 forwards the Redirect response to S‑CSCF#2.

12. S‑CSCF#2 invokes whatever service logic is appropriate for this session redirection. If UE#2 does not subscribe to session redirection service, or did not supply a new destination URI, S‑CSCF#2 may supply one or may terminate the session setup attempt with a failure response. The new destination URI may be a phone number, an email address, a web page, or anything else that can be expressed as a URI. The procedures of clause 5.11.5.1, 5.11.5.2, or 5.11.5.3 given above are followed, based on the type of URI.

5.11.5.6 Session Redirection initiated by originating UE#1 after Bearer Establishment (REDIRECT to originating UE#1)

The UE of the destination user may request the session be redirected after a customer-specified ringing interval. The UE may also implement customer-specific feature processing, and base its decision to redirect this session on such things as identity of caller, current sessions in progress, other applications currently being accessed, etc. UE sends the SIP Redirect response to its P‑CSCF, who forwards back along the signalling path to the originating endpoint, who initiates a session to the new destination.

The service implemented by this information flow is typically "Session Forward No Answer".

The originating end point may be a UE as shown in the example flow in figure 5.41 or it may be any other type of originating entity as defined in clause 5.4a. Redirect to another IMS endpoint (e.g. a sip: URI) is shown in the figure. The redirecting endpoint may be a UE as shown or an Application Server or a non-IMS network SIP client. Further, the endpoint to which the session is redirected may be a UE as shown in figure 5.41, or it may be any other type of terminating entity as defined in clause 5.4a. Only the scenario in which a call from the first UE is redirected by a second UE to a third UE is shown.

The flow presented here assumes that Policy and Charging Control is in use.

Figure 5.41: Session redirection after bearer establishment

Step-by-step processing is as follows:

1-10. Normal handling of a basic session establishment, up through establishment of the bearer channel and alerting of the destination user or by a previous session redirection after bearer establishment procedure.

11. Based on a timeout or other indications, UE#2 decides the current session should be redirected to a new destination URI. This new destination URI may be a phone number, an email address, a web page, or anything else that can be expressed as a URI. The Redirect response is sent to P‑CSCF#2.

12. P‑CSCF#2 shall revoke any authorization for QoS for the current session.

13. P‑CSCF#2 forwards the Redirect response to S‑CSCF#2.

14. S‑CSCF#2 invokes whatever service logic is appropriate for this session redirection. If UE#2 does not subscribe to session redirection service, or did not supply a new destination URI, S‑CSCF#2 service logic may supply one or may terminate the session setup attempt with a failure response. The new destination URI may be a phone number, an email address, a web page, or anything else that can be expressed as a URI. If S‑CSCF#2 service logic requires that it remain on the path for the redirected request, the service logic generates a private URI, addressed to itself, as the new destination.

15. S‑CSCF#2 sends a SIP Redirect response back to I‑CSCF, containing the new destination URI.

16. I‑CSCF sends a Redirect response back to S‑CSCF#1, containing the new destination.

17. S‑CSCF#1 service logic may check the number of redirections that have occurred for this session setup attempt, and if excessive, abort the session. If S‑CSCF#1 service logic requires that UE#1 not know the new destination URI, the service logic stores the new destination information, generates a private URI addressed to itself pointing to the stored information, and generates a modified Redirect response with the private URI.

18. S‑CSCF#1 sends the Redirect response to P‑CSCF#1.

19. P‑CSCF#1 revokes any authorization for QoS for the current session and sends the Redirect response to UE#1.

20. UE#1 initiates a new INVITE request to the address provided in the Redirect response. The new INVITE request is sent to P‑CSCF#1.

21. P‑CSCF#1 forwards the INVITE request to S‑CSCF#1.

22. S‑CSCF#1 invokes whatever service logic is appropriate for this new session setup attempt. The service logic may retrieve destination information if saved in step #17.

23. S‑CSCF#1 determines the network operator of the new destination address. If the service logic in step #14 did not provide its private URI as a new destination, the procedure continues with step #26, bypassing steps #24 and #25. If the service logic in step #14 did provide a private URI as a new destination, the INVITE message is sent to I‑CSCF#2, the I‑CSCF for S‑CSCF#2.

24. I‑CSCF forwards the INVITE to S‑CSCF#2.

25. S‑CSCF#2 decodes the private URI, determines the network operator of the new destination, and sends the INVITE request to the I‑CSCF for that network operator.

26-30. The remainder of this session completes as normal.