Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.228  Word version:  18.4.0

Top   Top   Up   Prev   Next
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.11.5  Session Redirection Proceduresp. 175

5.11.5.0  General |R6|p. 175

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.
Up

5.11.5.1  Session Redirection initiated by S-CSCF to IMSp. 175

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:
Reproduction of 3GPP TS 23.228, Fig. 5.36: Session redirection initiated by S-CSCF to IMS
Up
Step-by-step processing is as follows:
Step 1.
The SIP INVITE request is sent from the UE to S-CSCF#1 by the procedures of the originating flow.
Step 2.
S-CSCF#1 invokes whatever service logic is appropriate for this session setup attempt.
Step 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.
Step 4.
I-CSCF queries the HSS for current location information of the destination user.
Step 5.
HSS responds with the address of the current Serving-CSCF (S-CSCF#2) for the terminating user.
Step 6.
I-CSCF forwards the INVITE request to S-CSCF#2, who will handle the session termination.
Step 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.
Step 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.
Step 9.
I-CSCF#F queries the HSS (HSS#F) for current location information of the destination user.
Step 10.
HSS#F responds with the address of the current Serving-CSCF (S-CSCF#F) for the terminating user.
Step 11.
I-CSCF forwards the INVITE request to S-CSCF#F, who will handle the session termination.
Step 12.
S-CSCF#F invokes whatever service logic is appropriate for this session setup attempt
Step 13.
S-CSCF#F forwards the INVITE toward the destination UE, according to the procedures of the terminating flow.
Step 14-19.
The destination UE responds with the SDP message, and the session establishment proceeds normally.
Up

5.11.5.2  Session Redirection to PSTN Termination (S-CSCF #2 forwards INVITE)p. 176

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 remain in the path of SIP signalling, the S-CSCF forwards the INVITE to a BGCF. Then the BGCF (in the local network or in another network) will forward the INVITE to a MGCF, which will forward towards the destination according to the termination flow.
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.
Handling of redirection to a PSTN Termination where the S-CSCF#2 forwards the INVITE is shown in the Figure 5.37:
Reproduction of 3GPP TS 23.228, Fig. 5.37: Session redirection to PSTN Termination (S-CSCF #2 forwards INVITE)
Up
Step-by-step processing is as follows:
Step 1.
The SIP INVITE request is sent from the UE #1 to S-CSCF#1 by the procedures of the originating flow.
Step 2.
S-CSCF#1 performs whatever service control logic is appropriate for this session setup attempt.
Step 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.
Step 4.
I-CSCF queries the HSS for current location information of the destination user.
Step 5.
HSS responds with the address of the current Serving-CSCF (S-CSCF#2) for the terminating user.
Step 6.
I-CSCF forwards the INVITE request to S-CSCF#2, who will handle the session termination.
Step 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.
Step 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.
Step 9-12.
The destination responds with the SDP message, and the session establishment proceeds normally.
Up

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

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:
Reproduction of 3GPP TS 23.228, Fig. 5.37a: Session redirection to PSTN Termination (REDIRECT to originating UE#1)
Up
Step-by-step processing is as follows:
Step 1.
The SIP INVITE request is sent from the UE#1 to S-CSCF#1 by the procedures of the originating flow.
Step 2.
S-CSCF#1 invokes whatever service logic is appropriate for this session setup attempt.
Step 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.
Step 4.
I-CSCF queries the HSS for current location information of the destination user.
Step 5.
HSS responds with the address of the current Serving-CSCF (S-CSCF#2) for the terminating user.
Step 6.
I-CSCF forwards the INVITE request to S-CSCF#2, who will handle the session termination.
Step 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 use the SIP REDIRECT method to pass the redirection destination information (the 'redirected-to PSTN Termination' information) to the originator (UE#1).
Step 8.
S-CSCF#2 sends a SIP Redirect response to I-CSCF with the redirection destination.
Step 9.
I-CSCF sends a Redirect response to S-CSCF#1, containing the redirection destination.
Step 10.
S-CSCF#2 forwards the Redirect response to UE#1, containing the redirection destination
Step 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).
Up

Up   Top   ToC