A.1 Blind transfer

24.6293GPPExplicit Communication Transfer (ECT) using IP Multimedia (IM) Core Network (CN) subsystemProtocol specificationRelease 18TS

Figure A.1 signalling flow shows a blind transfer scenario, whereby the REFER request is forwarded the existing INVITE dialog between A and B.

Figure A.1: Blind transfer

1. A multimedia session exists between A-B. B initiates transfer A to C, by sending a REFER request with a Toheader field set to UE-A, a Referred-To header field set to UE-C, a Referred-By header field set to UE-B. The REFER request is sent in the existing dialog between A and B.

1.1 Upon reception of the REFER request, AS-B must check whether there is no outgoing call barring active from B to C. Because B is charged for the call from B-C when A is referred to C, when outgoing call barring is active from B-C the REFER request is rejected.

AS-B checks whether B is allowed to transfer calls, if B is allowed to transfer the call then AS-B generates an ECT session identifier URI, addressed to itself, with the new destination information and billing information that will be needed for the new session. It replaces the Refer-To header field value with the ECT session identifier URI. This ensures that:

AS-B will remain in the loop.

2. The REFER request is forwarded to AS-A.

2.1 AS-A checks whether it is allowed to transfer A.

3. The REFER request is forwarded to A by AS-A.

4. The REFER request is accepted by A’s UE.

4.1, 13.1, 31.1 AS-A can use result messages and notifications caused by the REFER request to track success of the REFER request and take appropriate actions. The AS-A can ensure that header fields that were replaced with other content are recreated with the original content on the way back.

5.1, 8.1, 32.1 AS-B can use this to track success of the REFER request and take appropriate actions. The AS-B can ensure that header fields that were replaced with other content are recreated with the original content on the way back.

7. Since the REFER request was accepted in 6. UE-B terminates the existing INVITE dialog by sending a BYE request to UE-A.

19. UE-A initiates a new session by sending an INVITE request to AS-B’s ECT session identifier URI (which represents UE-C).

19.1 AS-A routes the INVITE request to AS-B using the AS-B’s ECT session identifier URI using normal SIP routing procedures. Normal charging from A to B applies.

20.1 Upon receiving the INVITE request to the ECT session identifier URI that was inserted by the AS-B, the AS-B replaces it with the Request URI of C and creates an INVITE request targeted towards UE-C.

In this scenario it can be assumed that there is no active outgoing call barring towards UE-C, because the REFER was accepted by AS-B. The ECT Session Identifier URI has a limited validity time to ensure that no future barring is violated.

Also the Referred-By: header field is verified or filled in with the original unmodified values. Then the INVITE request is forwarded to UE-C using normal routing procedures.

21.1, 23.1 Normal terminating services apply for UE-C. The call will be treated as a call from A-C regarding call policies.

25.1 AS-A. Normal response handling applies.

27.1 AS-A. Normal ACK handling applies.

28.1 AS-B replaces all modified values and ECT session identifier URI ‘s with stored values.