SIMULACIONES EN PSPICE

An attended transfer requires that besides the (answered) call to be transferred (between transferee and transferor, in the following called dialog1) another answered call between transferor and transfer target exists (in the following called dialog2).

Note that dialog1 and dialog2 actually designate a chain of dialogs whenever one or more B2BUAs are present in the respective call signalling path.

E.3.1 Actions at the Transferor Endpoint

E.3.1.1 Normal Procedures

To initiate transfer the transferor endpoint should send a REFER request on dialog1 towards the transferee. Depending on local policy, the transferor endpoint may put the transferee on hold prior to sending the REFER request. The transferor endpoint may also put the transfer target on hold prior to sending the REFER request.

Content of REFER:

Request URI:Contact URI associated with the transferee (remote target URI of dialog1)

To: as for dialog1 From: as for dialog1

Refer-to: <Contact URI of transfer target [;method=INVITE]

?Replaces=dialog2 [&Require=replaces]> (remote target URI of dialog2) Contact: Contact URI of transferor (as in dialog1)

Referred-by: URI (AoR) of transferor (optional)

Note: The replaces URI-parameter included in Refer-to contains the call-ID,

From-tag and To-tag of dialog2. Example (all on one line): Refer-To:<sip:[email protected]?

Replaces=090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom- tag%3D763231&Require=replaces>

On receipt of a BYE request on dialog2 after REFER has been sent on dialog1 the transferor endpoint should proceed with clearing dialog2 and the associated session.

On receipt of a BYE request on dialog1 after receipt of a "202 Accepted" response to the sent REFER request the transferor endpoint should proceed with clearing dialog1 and the associated session.

E.3.1.2 Exceptional Procedures

If the REFER request fails (i.e. a final 4xx, 5xx or 6xx (REFER) response is received) dialog1 should remain in place. Depending on the failure reason and local policy the transferor endpoint may attempt another attended transfer, e.g. with reversed roles of transferee and transfer target or with user C's AoR instead of the contact URI in the Refer-to header. If no further transfer attempt is started and dialog1 is on hold, the transferor endpoint should retrieve it from hold.

If the remote side (transferor server or transferee) terminates dialog1 - by sending a BYE request for the original call- before a final (INVITE) response for the transferred call has been reported the transferor endpoint should consider the transfer attempt finished.

Note: If either side released the call associated with dialog1 after acceptance of

REFER and prior to completion of call transfer the transferor endpoint may receive a recall from the remote side (OpenScape Voice or transferee) if the transfer attempt failed.

E.3.2 Actions at OpenScape Voice

Upon receipt of a REFER request the OpenScape Voice serving user A will behave as follows:

• Act upon the REFER request and perform call transfer as described below.

E.3.2.1 Normal Procedures

On receipt of a REFER request from the transferor endpoint on dialog1 the OpenScape Voice serving user A will check whether the request is acceptable (e.g. check that it "owns" the URI in the Refer-to header field and that it recognizes the dialog identified in the embedded Replaces header field), and if so respond with "202 Accepted".

Then the OpenScape Voice will send on dialog1 a re-INVITE request without SDP towards the transferee. On receipt of an SDP offer from the transferee - in the 200 OK (INVITE) response - the OpenScape Voice will send on dialog2 (with the matching dialog2 being selected by means of the content of the Refer-to header of the received REFER request)

• a BYE request to the transferor endpoint, and

• a re-INVITE (or optionally an UPDATE) request with the transferee's SDP offer towards the transfer target,

and then pass on the transfer target's SDP answer to the transferee (in the ACK request).

The OpenScape Voice will also send a BYE request to the transferor endpoint on dialog1.

E.3.2.2 Exceptional procedures

If a REFER request cannot be accepted the transferor server (OpenScape Voice serving user A) will return a failure (REFER) response (4xx, 5xx, 6xx) describing the reason, chosen according to RFC 3515.

The OpenScape Voice will send a BYE request to the transferor endpoint on dialog1. This will cause the transferor endpoint to release the call. In this case the OpenScape Voice may initiate a recall later on if the transfer attempt fails. If the transferee releases the call (by sending a BYE request on dialog1) before or while transfer is taking place the OpenScape Voice will

• send to the transferor endpoint a BYE request on dialog1 if the original call still exists;

• send to the transfer target a BYE request on dialog2; These actions terminate dialog1, and no recall will be initiated.

If the transfer target releases the call (by sending a BYE request on dialog2) before or while transfer is taking place and the transferee is still available the OpenScape Voice will:

• retain the original call (dialog1) if still available, or

• initiate a recall to the transferor endpoint according to Sect. E.5.2, if supported and if the original call leg towards the transferor endpoint was already released (by the transferor endpoint or the transferor server).

E.3.2.3 Actions at the Transferee Endpoint

The transferee endpoint will be involved in attended call transfer as follows:

• The transferee endpoint may receive re-INVITE or UPDATE requests according to 3pcc procedures.

E.3.2.4 Transfer Using 3pcc Procedures

E.3.3 Actions at the Transferee OpenScape Voice

E.3.3.1 Transparent Server

In our current implementations no call transfer specific actions are required from the OpenScape Voice serving user B - the OpenScape Voice will pass all requests and responses to and from the transferee without acting on them (other than the usual SIP message handling of a B2BUA).

E.3.4 Actions at the Transfer Target Endpoint

The transfer target endpoint will be involved in attended call transfer as follows:

• The transfer target endpoint may receive re-INVITE or UPDATE requests according to 3pcc procedures.

E.3.4.1 Transfer Using 3pcc Procedures

No special actions are required.

E.3.5 Actions at the Transfer Target OpenScape Voice

E.3.5.1 Transparent Server

In our current implementations no call transfer specific actions are required from the OpenScape Voice serving user C - the OpenScape Voice will pass all requests and responses to and from the transfer target endpoint without acting on them (other than the usual SIP message handling of a B2BUA).