A.1 Blind transfer

24.5293GPPProtocol specificationPSTN/ISDN simulation services: Explicit Communication Transfer (ECT)Release 8TISPANTS

Figure A.1 signalling flow shows a blind transfer scenario, whereby the REFER request is sent on 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 REFER request To: UE-A with Referred-To: UE-C, Referred-By: UE-B. The REFER request is send in the existing dialog that 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 it 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 value with the ECT Session Identifier URI. This ensures that:

AS-B will remain in the loop.

2. The REFER request is sent on to AS-A.

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

3. The REFER request is sent on 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 refer and take appropriate actions. The AS-A can ensure that header fields that where 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 where 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 to UE-A.

19. The 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 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. For now it is assumed that this is enough.

Also the Referred-By: header field is verified or filled in with the original uncodified 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 codified values and ECT Session Identifier URI ‘s with stored values.