5.11.6 Session Transfer Procedures

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

5.11.6.0 General

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

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:

Figure 5.42: Refer operation

Step-by-step description of the information flow:

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.

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.

3. P‑CSCF#2 forwards the message to S‑CSCF#2.

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.

5. S‑CSCF#2 forwards the message to S‑CSCF#1.

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.

7. S‑CSCF#1 forwards the message to P‑CSCF#1.

8. P‑CSCF#1 forwards the message to UE#1.

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.

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

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

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.

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.

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

15. P‑CSCF#F forwards the request to UE#F.

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.

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.

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.

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.

NOTE: The last BYE message to clear the original session can be issued either by UE#1 or by UE#2.

5.11.6.2 Application to Session Transfer Services

5.11.6.2.0 General

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

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.

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

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.

5.11.6.2.3 Three-way Session

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.

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.