Content for TS 23.228 Word version: 19.0.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… AC.10…

5.11.6 Session Transfer Procedures 5.11.6.0 General 5.11.6.1 Refer operation 5.11.6.2 Application to Session Transfer Services 5.11.6.2.0 General 5.11.6.2.1 Blind Transfer and Assured Transfer 5.11.6.2.2 Consultative Transfer 5.11.6.2.3 Three-way Session
...

5.11.6 Session Transfer Procedures p. 183

5.11.6.0 General |R6| p. 183

This clause gives information flows for the procedures for performing session transfers. This is presented in two steps: first a basic primitive that can be used by endpoints to cause a multi-media session to be transferred, and second the procedures by which this primitive can be used to implement some well-known session-transfer services.

5.11.6.1 Refer operation p. 183

The refer primitive is an information flow indicating a "Refer" operation, which includes a component element "Refer-To" and a component element "Referred-By". The end point receiving a referral may be UE#1 as shown in the example flow in Figure 5.42 or it may be any other type of originating entity as defined in clause 5.4a. The referring endpoint may be either UE#2 as shown, an Application Server or a non-IMS network SIP client. The referred-to destination may be UE#F as shown in Figure 5.42 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 referred by a second UE to a third UE is shown.

An information flow illustrating this is as follows:

Reproduction of 3GPP TS 23.228, Fig. 5.42: Refer operation

Figure 5.42: Refer operation

Step-by-step description of the information flow:

Step 1.

A multi-media session is assumed to already exist between UE#1 and UE#2, established either as a basic session or by one of the supplemental services described in this clause.

Step 2.

UE#2 sends the Refer command to P-CSCF#2, containing "Refer-To" UE#F and "Referred-By" UE#2. If UE#2 knows the GRUU of UE#F and desires to reach a particular instance of UE#F, the "Refer-To" contains the GRUU of UE#F otherwise the "Refer-To" contains the Public User Identity of UE#F.

Step 3.

P-CSCF#2 forwards the message to S-CSCF#2.

Step 4.

S-CSCF#2 invokes whatever service logic is appropriate for this request. If UE#2 does not subscribe to a transfer service, service logic may reject the request. If S-CSCF#2 service logic requires that it remain on the path for the subsequent request, the service logic generates a private URI, addressed to itself, the "Refer-To" value in the request with the private URI.

Step 5.

S-CSCF#2 forwards the message to S-CSCF#1.

Step 6.

S-CSCF#1 invokes whatever service logic is appropriate for this request. To hide the identities of UE#2 and UE#F, S-CSCF#1 service logic stores the "Refer-To" and "Referred-By" information and replaces them with private URIs.

Step 7.

S-CSCF#1 forwards the message to P-CSCF#1.

Step 8.

P-CSCF#1 forwards the message to UE#1.

Step 9.

UE#1 initiates a new multi-media session to the destination given by the "Refer-To", which may either be a URI for UE#F, a private URI pointing to S-CSCF#2, or a private URI pointing to S-CSCF#1.

Step 10.

P-CSCF#1 forwards the INVITE request to S-CSCF#1.

Step 11.

S-CSCF#1 retrieves the destination information for the new session, and invokes whatever service logic is appropriate for this new session.

Step 12.

S-CSCF#1 determines the network operator addressed by the destination URI, and forwards the INVITE to either S-CSCF#F or S-CSCF#2 (actually I-CSCF#F or I-CSCF#2, the public entry points for S-CSCF#F and S-CSCF#2, respectively). If S-CSCF#1 forwards the INVITE to S-CSCF#F, the procedure continues with step #14, bypassing step #13.

Step 13.

S-CSCF#2 decodes the private URI destination, and determines the final destination of the new session. It determines the network operator addressed by the destination URI. The request is then forwarded onward to S-CSCF#F as in a normal session establishment.

Step 14.

S-CSCF#F invokes whatever service logic is appropriate for this new session, and forwards the request to P-CSCF#F.

Step 15.

P-CSCF#F forwards the request to UE#F.

Step 16-21.

The normal session establishment continues through bearer establishment, optional alerting, and reaches the point when the new session is accepted by UE#F. UE#F then sends the 200-OK final response to P-CSCF#F, which is forwarded through S-CSCF#F, S-CSCF#2 (optionally), S-CSCF#1, P-CSCF#1, to UE#1. At this point a new session is successfully established between UE#1 and UE#F.

Step 22-26.

The Refer request was successful, and UE#1 sends a 200-OK final response to UE#2. This response is sent through P-CSCF#1, S-CSCF#1, S-CSCF#2, P-CSCF#2, and to UE#2.

Step 27-31.

UE#2 clears the original session with UE#1 by sending the BYE message. This message is routed through P-CSCF#2, S-CSCF#2, S-CSCF#1, P-CSCF#1, to UE#1.

Step 32-36.

UE#1 acknowledges the BYE and terminates the original session. It responds with the 200-OK response, routed through P-CSCF#1, S-CSCF#1, S-CSCF#2, P-CSCF#2, to UE#2.

5.11.6.2 Application to Session Transfer Services p. 185

5.11.6.2.0 General |R6| p. 185

This clause shows how the Refer primitive given above can be used to provide common session-transfer services.

5.11.6.2.1 Blind Transfer and Assured Transfer p. 185

A Blind Transfer starts with an existing session, established between the Initiator (I) and the Recipient (R). In a typical case, this session was actually initiated by R. In the end it is desired that the Recipient has a session with the Target (T).

From the starting configuration, shown in the leftmost diagram, I sends a Refer message to R, who then initiates a session with the Target (T), as shown in the middle diagram. Immediately after sending the Refer message to R, I issues the BYE message to terminate its connection with R. The end configuration is shown in the rightmost diagram.

Reproduction of 3GPP TS 23.228, Fig. 5.11.6.2.1-1:

Figure 5.11.6.2.1-1

An Assured Transfer is identical to the above, except that I waits until the Refer successfully completes before issuing the BYE message to terminate its connection with R. If the new session from R to T were to fail, R would still have a session with I.

5.11.6.2.2 Consultative Transfer p. 186

A Consultative Transfer again starts with an existing session, established from the Initiator (I) to the Recipient (R). The Initiator first consults with the Target (T), then decides to transfer the original session to T.

From the starting configuration, as shown in the leftmost diagram in the previous clause, I places the session with R on hold and establishes a new session with T. This is shown in the leftmost diagram below. I then sends a Refer message to T, causing T to establish a session with R. This is shown in the second diagram. When the Refer operation completes, I clears its two active sessions, first with R (leaving the configuration as shown in the third diagram) then with T. The end configuration is shown in the rightmost diagram.

Reproduction of 3GPP TS 23.228, Fig. 5.11.6.2.2-1:

Figure 5.11.6.2.2-1

5.11.6.2.3 Three-way Session p. 186

A three-way session starts with an existing session, between the Initiator (I) and party (A). The initiator places this session on hold, and establishes a second session with party (B). The initiator then decides to create an ad-hoc conference of all three parties.

From the point where the initiator decides to create the ad-hoc conference, shown in the leftmost diagram below, the initiator establishes another session with a third-party conference bridge service. This is shown in the centre diagram. The initiator then transfers both of the existing sessions, I→A and I→B, to the bridge, ending in the configuration shown in the rightmost diagram.

Reproduction of 3GPP TS 23.228, Fig. 5.11.6.2.3-1:

Figure 5.11.6.2.3-1

The conference bridge service is in control of the termination sequence. On termination of one of the three sessions, it may either terminate the other two sessions by use of the session clearing procedures of clause 5.11, or may utilize the procedures of clause 5.11.6.2.1 above to transfer one of the remaining endpoints to the other, resulting in a simple two-party session.