Session Initiation Protocol Call Control - TransferEstacado SystemsRjS@estacado.netAvayaSt. LouisMOalan@sipstation.comSIPez LLC34 Robbins Rd.ArlingtonMA02476US+1 617 273 4000dan.ietf AT SIPez DOT comhttp://www.SIPez.com/SIPPING WG
This document describes providing Call Transfer capabilities in the Session Initiation Protocol (SIP). SIP extensions such as REFER and Replaces are used to provide a number of transfer services including blind transfer, consultative transfer, and attended transfer. This work is part of the SIP multiparty call
control framework.
This document describes providing Call Transfer capabilities and requirements
in SIP . This work is part of the Multiparty Call
Control Framework .
The mechanisms discussed here are most closely related to traditional
basic and consultation hold transfers.
This document details the use of REFER method and
Replaces header field to achieve call transfer.
A user agent that fully supports the transfer mechanisms described in this document supports REFER and Replaces in addition to RFC 3261 . A user agent should use a Contact URI which meets the requirements in Section 8.1.1.8 of RFC 3261. A compliant user agent supports the Target-Dialog header field .
There are three actors in a given transfer event, each playing one of
the following roles:
The following roles are used to describe transfer requirements and
scenarios:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 .
Any party in a SIP session must be able to transfer any other party in
that session at any point in that session.The Transferor and the Transferee must not be removed from a session
as part of a transfer transaction.
The Transferor must know whether or not the transfer was successful.The Transferee must be able to replace an existing dialog with a new
dialog.The Transferor and Transferee should indicate their support for the
primitives required to achieve transfer.The Transferor should provide the Transfer Target and Transferee with information about the nature and progress of the transfer operation being attempted.
A REFER can be issued by the Transferor to cause the Transferee to
issue an INVITE to the Transfer-Target. Note that a successful REFER
transaction does not terminate the session between the Transferor and
the Transferee. If those parties wish to terminate their session, they
must do so with a subsequent BYE request. The media negotiated between
the transferee and the transfer target is not affected by the media
that had been negotiated between the transferor and the transferee. In
particular, the INVITE issued by the Transferee will have the same SDP
body it would have if he Transferee had initiated that INVITE on its
own. Further, the disposition of the media streams between the
Transferor and the Transferee is not altered by the REFER method.
Agents may alter a session's media through additional signaling. For
example, they may make use of the SIP hold re-INVITE
or
conferencing extensions described in the conferencing framework .
To perform the transfer, the transferor and transferee could reuse an existing dialog established by an INVITE to send the REFER. This would result in a single dialog shared by two uses - an invite usage and a subscription usage. The call flows for this are shown in detail in Section 6.2. However, the approach described in this document is to avoid dialog reuse. The issues and difficulties associated with dialog reuse are described in
Motivations for reusing the existing dialog include:
There was no way to ensure that a REFER on a new dialog would
reach the particular endpoint involved in a transfer. Many
factors, including details of implementations and changes in
proxy routing between an INVITE and a REFER could cause the REFER
to be sent to the wrong place. Sending the REFER down the
existing dialog ensured it got to the endpoint we were already
talking to.
It was unclear how to associate an existing invite usage with a
REFER arriving on a new dialog, where it was completely obvious
what the association was when the REFER came on the invite
usage's dialog.
There were concerns with authorizing out-of-dialog REFERs. The
authorization policy for REFER in most implementations piggybacks
on the authorization policy for INVITE (which is, in most cases,
based simply on "I placed or answered this call").
GRUUs can be used to address problem 1. Problem 2 can be addressed using the Target-Dialog header field defined in . In the
immediate term, this solution to problem 2 allows the existing REFER
authorization policy to be reused.
As a result, if the Transferee supports the target-dialog extension and the Transferor knows the Contact URI is routable outside the dialog, the REFER SHOULD be sent in a new dialog. If the nature of the Contact URI is not known or if support for the target-dialog extension is not known, the REFER SHOULD be sent inside the existing dialog. A Transferee MUST be prepared to receive a REFER either inside or outside a dialog. One way that a Transferor could know that a Contact URI is routable outside a dialog is by validation (e.g. sending an OPTIONS and receiving a response) or if it satisfies the properties described in the GRUU specification .
This document does not prescribe the flows and examples precisely as they are
shown, but rather the flows illustrate the principles for best
practice for the transfer feature. The call flows represent well-reviewed
examples of SIP usage to implement transfer with REFER,
which are best common practice according to IETF consensus.
In most of the following examples, the Transferor is in the atlanta.example.com domain, the Transferee is in the biloxi.example.com, and the Transfer Target is in the chicago.example.com domain.
Basic Transfer consists of the Transferor providing the Transfer
Target's contact to the Transferee. The Transferee attempts to
establish a session using that contact and reports the results of that
attempt to the Transferor. The signaling relationship between the
Transferor and Transferee is not terminated, so the call is
recoverable if the Transfer Target cannot be reached. Note that the
Transfer Target's contact information has been exposed to the
Transferee. The provided contact can be used to make new calls in the
future.
The participants in a basic transfer SHOULD indicate support for the REFER
and NOTIFY methods in Allow header fields in INVITE, 200 OK to
INVITE, and OPTIONS messages. Participants SHOULD also indicate support for Target-Dialog in the Supported header field.
The diagrams below show the first line of each message. The first column of the figure shows the dialog used in that particular message. In these
diagrams, media is managed through re-INVITE holds, but other
mechanisms (mixing multiple media streams at the UA or using the
conferencing extensions for example) are valid. Selected message details are shown labeled as message F1, F2, etc.
Each of the flows below shows the dialog between the Transferor
and the Transferee remaining connected (on hold) during the REFER
process. While this provides the greatest flexibility for recovery
from failure, it is not necessary. If the Transferor's agent does
not wish to participate in the remainder of the REFER process and
has no intention of assisting with recovery from transfer failure,
it could emit a BYE to the Transferee as soon as the REFER
transaction completes. This flow is sometimes known as "unattended
transfer" or "blind transfer".
Figure 1 shows transfer when the Transferee utilizes a GRUU and supports the target-dialog extension and indicates this to the Transferor. As a result, the Transferor sends the REFER outside the INVITE dialog. The Transferee is able to match this REFER to the existing dialog using the Target-Dialog header field in the refer which references the existing dialog.
Figure 1. Basic Transfer Call Flow.
In this scenario, the Transferor does not know the properties of the Transferee's Contact URI or does not know that the Transferee supports the Target-Dialog header field. As a result, the REFER is sent inside the INVITE dialog.
Figure 2. Transfer with Dialog Reuse.
This section shows examples of failed transfer attempts. After the transfer
failure occurs, the Transferor takes the Transferee off hold and resumes the
session.
Figure 3. Failed Transfer - Target Busy
Figure 4. Failed Transfer - Target Does Not Answer.
Transfer with Consultation Hold involves a session between the
transferor and the transfer target before the transfer actually takes
place. This is implemented with SIP Hold and Transfer as
described above.
A nice feature is for the transferor to let the target know that the session relates to an intended transfer. Since many UAs render the display name in the From header field to the user, a consultation INVITE could contain a string such as "Incoming consultation from Transferor with intent to transfer Transferee", where the display names of the transferor and transferee are included in the string.
The transferor places the transferee on hold, establishes a call with
the transfer target to alert them to the impending transfer,
terminates the connection with the transfer target, then proceeds with
transfer as above. This variation can be used to provide an
experience similar to that expected by current PBX and Centrex users.
To (hopefully) improve clarity, non-REFER transactions have been
collapsed into one indicator with the arrow showing the direction of
the request.
Figure 5. Transfer with Consultation Hold - Exposing Transfer Target.
The transferor places the transferee on hold, establishes a call with
the transfer target and then reverses their roles, transferring the
original transfer target to the original transferee. This has the
advantage of hiding information about the original transfer target
from the original transferee. On the other hand, the Transferee's
experience is different that in current systems. The Transferee is
effectively "called back" by the Transfer Target.
One of the problems with this simplest implementation of
a target protecting transfer is that the transferee is
receiving a new call from the transfer-target.
Unless the transferee's agent has a reliable way to associate
this new call with the call it already has with the transferor,
it will have to alert the new call on another appearance. If
this, or some other call-waiting-like UI were not available, the
transferee might be stuck returning a Busy-Here to the transfer
target, effectively preventing the transfer.
There are many ways that that correlation could be provided. The
dialog parameters could be provided directly as header parameters
in the Refer-To: URI for example. The Replaces mechanism
uses this approach and solves this problem
nicely.
For the flow below, dialog1 means dialog identifier 1, and consists
of the parameters of the Replaces header for dialog 1. In
this is the Call-ID, To-tag and From-tag.
Note that the transferee's agent emits a BYE to the transferor's agent
as an immediate consequence of processing the Replaces header.
The Transferor knows that both the Transferee and the Transfer Target
support the Replaces header from the Supported: replaces header contained
in the 200 OK responses from both.
In this scenario, the Transferee utilizes a GRUU as a Contact URI for reasons discussed in Section 6.3.
Note that the conventions used in the SIP Torture Test Messages document are reused, specifically the <allOneLine> tag.
Figure 6. Transfer Protecting Transfer Target.
The transferor places the transferee on hold, establishes a call with
the transfer target to alert them to the impending transfer,
places the target on hold, then proceeds with
transfer using an escaped Replaces header field in the Refer-To header.
This is another common service expected by current PBX and Centrex users.
The Contact URI of the Transfer Target SHOULD be used by the Transferor as the Refer-To URI, unless the URI is suspected or known to not be routable outside the dialog. Otherwise, the Address of Record (AOR) of the Transfer Target SHOULD be used. That is, the same URI that the Transferor used to establish the session with the Transfer Target should be used. In case the triggered INVITE is routed to a different User Agent than the Transfer Target, the Require: replaces header field SHOULD be used in the triggered INVITE. (This is to prevent an incorrect User Agent which does not support Replaces from ignoring the Replaces and answering the INVITE without a dialog match.)
It is possible that proxy/service routing may prevent the triggered INVITE from reaching the same User Agent. If this occurs, the triggered invite will fail with a timout, 403, 404, etc error. The Transferee MAY then retry the transfer with the Refer-To URI set to the Contact URI.
Figure 7. Attended Transfer Call Flow.
If protecting or exposing the transfer target is not a concern,
it is possible to complete a transfer with consultation hold when
only the transferor and one other party support REFER. Note that a 405
Method Not Allowed might be returned instead of the 501 Not Implemented
response.
Figure 8. Recovery when one party does not support REFER.
It is a requirement of RFC3261 that a Contact URI be globally routable even outside the dialog. However, due to RFC2543 User Agents and some architectures (NAT/Firewall traversal, screening proxies, ALGs, etc.) this will not always be the case. As a result, the method of Attended Transfer shown in Figures 6, 7, and 8 SHOULD only be used if the Contact URI is known to be routable outside the dialog.
Figure 9 shows such a scenario where the Transfer Target Contact URI is not routable outside the dialog, so the triggered INVITE is sent to the AOR of the Transfer Target.
Figure 9. Attended Transfer Call Flow with a Contact URI not known to be Globally Routable
Figure 10 shows a failure case in which the AOR URI fails to reach the transfer Target. As a result, the transfer is retried with the Contact URI which succeeds.
Note that there is still no guarantee that the correct endpoint will be reached, and the result of this second REFER may also be a failure. In that case, the Transferor could fall back to unattended transfer or give up on the transfer entirely. Since two REFERs are sent within the dialog creating two distinct subscriptions, the Transferee uses the 'id' parameter in the Event header field to distinguish notifications for the two subscriptions.
Figure 10. Attended Transfer Call Flow with non-routable Contact URI and AOR Failure
To prevent this scenario from happening, the Transfer Target SHOULD use a Contact URI which is routable outside the dialog, which will result in the call flow of Figure 7.
In any of the consultation hold flows above, the Transferor may decide
to terminate its attempt to contact the Transfer target before that
session is established. Most frequently, that will be the end of the
scenario, but in some circumstances, the transferor may wish to proceed
with the transfer action. For example, the Transferor may wish to complete the transfer
knowing that the transferee will end up eventually talking to the
transfer-target's voice-mail service. Some PBX systems support this feature, sometimes called "semi-attended transfer", that is effectively a hybrid between a fully attended transfer and an unattended transfer. A call flow is shown in Figure 11. In this flow, the Transferor's User Agent continues the transfer as an attended transfer even after the Transferor hangs up. Note that media must be played to the Transfer Target upon answer - otherwise, the Target may hang up and the resulting transfer operation will fail.
Figure 11. Recommended Semi-Attended Transfer Call Flow.
Two other possible semi-attended transfer call flows are shown in Figures 12 and 13. However, these call flows are NOT RECOMMENDED due to a race conditions. In both of these flows, when the Transferor hangs up, the Transferor attempts to revert to unattended transfer by sending a CANCEL to the Target. This can result in two race conditions. One is that the Target answers despite the CANCEL and the resulting unattended transfer fails. This race condition can be eliminated by the Transferor waiting to send the REFER until the 487 response from the Target is returned. Instead of a 487, a 200 OK may return indicating that the Target has answered the consultation call. In this, case the call flow in Figure 13 must be followed. In this flow, the Transferor must play some kind of media to the Target to prevent the Target from hanging up, or the Transfer will fail. That is, the human at the Transfer Target will hear silence from when they answer (message F1) until the transfer completes (F3 and they are talking to the Transferee unless some media is played (F2).
The second race condition occurs in Figure 12 if the Transfer Target goes "off hook" after the CANCEL is received and the 487 returned. This may result in a 486 Busy Here response to the unattended transfer.
The recommended call flow of Figure 11 does not utilize a CANCEL and does not suffer from these race conditions.
Figure 12. Semi-Attended Transfer as Blind Transfer Call Flow. (Not Recommended)Figure 13. Semi-Attended Transfer as Attended Transfer Call Flow. (Not Recommended)
In this flow, an attempted attended transfer fails so the transferor falls back to basic transfer.
The call flow in Figure 14 shows the use of Require: replaces in the INVITE sent by the Transferor to the Transfer Target in which the Transferor's intention at the time of sending the INVITE to the Transfer Target was known to be to complete an attended transfer. Since the Target does not support Replaces, the INVITE is rejected with a 420 Bad Extension response, and the Transferor switches from attended transfer to basic transfer immediately.
Figure 14. Attended Transfer Fallback to Basic Transfer using Require:replaces. Figure 15 shows the use of OPTIONS when the Transferee and Transfer Target do not explicitly indicate support for the REFER method and Replaces header fields in Allow and Supported header fields and the Transferor did not have the intention of performing an attended transfer when the INVITE to the Target was sent. In dialog1, the Transferor determines using OPTIONS that the Transferee does support REFER and Replaces. As a result, the Transferor begins the attended transfer by placing the Transferee on hold and calling the Transfer Target. Using an OPTIONS in dialog2, the Transferor determines that the Target does not support either REFER or Replaces, making attended transfer impossible. The Transferor then ends dialog2 by sending a BYE then sends a REFER to the Transferee using the AOR URI of the Transfer Target.
Figure 15. Attended Transfer Fallback to Basic Transfer.
In the previous examples, the Transfer Target does not have definitive information about what party initiated the transfer, or, in some cases, even that transfer is taking place. The Referred-By mechanism provides a way for the Transferor to provide the Transferee with a way to let the Transfer Target know what party initiated the transfer.
The simplest and least secure approach just involves the inclusion of the Referred-By header field in the REFER which is then copied into the triggered INVITE. However, a more secure mechanism involving the Referred-By security token which is generated and signed by the Transferor and passed in a message body to the Transferee then to the Transfer Target.
The call flow is shown in Figure 16 showing the Referred-By header field and body in the REFER F5 and triggered INVITE F6. Note that the S/MIME signature is not shown in the example below. The conventions used in the SIP Torture Test Messages document are reused, specifically the <hex> and <allOneLine> tags.
Figure 16. Attended Transfer Call Flow with Referred-By.
In this flow, shown in Figure 17, Bob does an attended transfer of Alice to Carol. In order to keep both Alice and Carol fully informed of the nature and state of the transfer operation, Bob acts as a focus and hosts an ad-hoc conference involving Alice, Bob, and Carol. Alice and Carol subscribe to the conference package of Bob's focus, which allows them to know the exact status of the operation. After the transfer operation is complete, Bob deletes the conference.
This call flow meets requirement 6 of Section 3. NOTIFY messages related to the refer package are indicated as NOTIFY (refer), while NOTIFYs related to the Conference Info package are indicated as NOTIFY (Conf-Info).
Note that any type of semi-attended transfer in which media mixing or relaying could be implemented using this model. In addition to simply mixing, the focus could introduce additional media signals such as simulated ring tone or on hold announcements to improve the user experience.
In this example shown in Figure 18, the Originator places call to the Facilitator who
reaches the Recipient through the Screener. The Recipient's contact
information is exposed to the Facilitator and the Originator. This
example is provided for clarification of the semantics of the REFER
method only and should not be used as the design of an
implementation.
Figure 18. Transfer with Multiple Parties Example.
A gateway in SIP acts as a User Agent. As a result, the entire preceding
discussion and call flows apply equally well to gateways as native SIP
endpoints. However, there are some gateway specific issues that are
documented in this section. While this discussion focuses on the common cases
involving PSTN gateways, similar situations exist for other gateways, such as
H.323/SIP gateways.
To illustrate how a hairpin situation can occur in transfer, consider
this example. The original call dialog is setup with the transferee
residing on the PSTN side of a SIP gateway. The transferor is a SIP
phone purely in the IP space. The transfer target is on the PSTN side
of a SIP gateway as well. After completing the transfer, (regardless
of consultative or blind) the transferee is in a call with the
transfer target (both on the PSTN side of a gateway). It is often
desirable to remove the gateway(s) out of the loop. This is likely
to only be possible if both legs of the target call are on the same
gateway. With both legs on the same gateway, it may be able to
invoke the analogous transfer on the PSTN side. Then the target call
would not involve the gateway.
So the problem is how to give the proxy enough information so that it
knows to route the call to the same gateway. With a simple single
call that hairpins, the incoming and outgoing leg have the same
dialog. The proxy should have enough information to optimize the
routing.
In the consultative transfer scenario, it is desirable to coerce the
consultative INVITE out the same gateway as the original call to be
transferred. However there is no way to relate the consultation with
the original call. In the consultative case the target call INVITE
includes the Replaces header which contains dialog information that
can be used to relate it to the consultation. However there is no
information that relates the target call to the original.
In the blind transfer scenario, it is desirable to coerce the target
call onto the same gateway as the original call. However the same
problem exists in that the target dialog cannot be related to the
original dialog.
In either transfer scenario, it may be desirable to push the transfer
operation onto the non-SIP side of the gateway. Presumably this is
not possible unless all of the legs go out the same gateway. If the
gateway supports more than one truck group, it might also be
necessary to get all of the legs on the same trunk group in order to
perform the transfer on the non-SIP side of the gateway.
Solutions to these gateway specific issues may involve new extensions
to SIP in the future.
In the consultative transfer case turned blind, there is a glare-like
problem. The transferor initiates the consultation INVITE, the transferor
gets impatient and hangs up, transitioning this to a blind transfer.
The transfer target on the gateway (connected through a PSTN switch to
a single line or dumb analog phone) rings. The user answers the
phone just after the CANCEL is received by the transfer target. The
REFER and INVITE for the target call are sent. The transferee
attempts to setup the call on the PSTN side, but gets either a busy or
lands in the users voicemail as the user has the handset in hand and
off hook.
This is another example of a race condition that this call flow can cause.
The recommended behavior is to use the approach described in Section 6.6.
None.
The call transfer flows shown in this document are implemented using the REFER and Replaces call control primitives in SIP. As such, the security considerations detailed in the REFER and Replaces documents MUST be followed, which are briefly summarized in the following paragraphs. This document addresses the issue of protecting the Address of Record URI of a transfer target in Sections 7.1 and 7.2.
Any REFER request MUST be appropriately authenticated and authorized using standard SIP mechanisms or calls may be hijacked. A user agent may use local policy or human intervention in deciding whether or not to accept a REFER. In generating NOTIFY responses based on the outcome of the triggered request, care should be taken in constructing the message/sipfrag body to ensure that no private information is leaked.
An INVITE containing a Replaces header field SHOULD only be accepted
if it has been properly authenticated and authorized using standard
SIP mechanisms, and the requestor is authorized to perform dialog
replacement. Special care is needed if the replaced dialog utilizes additional
media streams compared to the original dialog. In this case, the user MUST authorize the addition
of new media streams in a dialog replacement. For example, the same mechanism
used to authorize the addition of a media stream in a re-INVITE could be used.
This draft is a collaborative product of the SIP working group. Thanks
to Rohan Mahy for his input on the use of Replaces in transfer.