SIP Transfer Issues

Transfer features in SIP can be accomplished using the primitives based upon the REFER method and the Replaces header as described in . Further examples of the signaling involved in transfer are demonstrated in . There are a few problems which come up in the field that are not obviously solvable by these constructs. In this draft some of the requirements and problems are described so that they can be categorized as: solved by existing protocol, implementation issues, desirable to solve with new protocol, or not a requirement desirable to solve. Also an attempt was made to propose some directions that can be pursued in fulfilling these requirements.

the user agent initiating the transfer. the user agent to be transferred to the third party. the third party to which the transferee is to be connected. the dialog between the transferor and the transferee which is setup before initiating the transfer. the dialog between the transferor and the transfer target which is setup before completing the transfer. the dialog between the transferee and the transfer target which is the final outcome of the transfer.

Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in RFC 2119.

The following define requirements, problems and issues seen in current transfer implementations. Some of these simply reflect the need for a better understanding of how transfer , REFER and replaces should be used. Others may require new application of existing protocol constructs. Some may require new protocol constructs.

In many cases of general call setup, the routing functions that determine how to route a SIP request to a target user agent are not static. The routing may be influenced by the time of day, dialog state on the target, availability of the call agent, etc. For this reason, SIP requests sent to the same address of record will not necessarily be routed to the same target user agent. This causes a problem for consultative transfer. The consultative INVITE is sent and the dialog is setup with the transfer target prime (TT'). When the consultation is complete the transferor (TC) sends a REFER to the transferee (TE). The transferee in turn sends an INVITE with Replaces to the transfer target (TT). The INVITE with Replaces does not land on the correct transfer target prime (TT') where the dialog in the Replaces header matches. The transfer target (TT) then according to sends a 481 and thus the transfer fails. What is really needed is a globally routable means for the transferor to address the correct target TT' in the Refer-To header of the REFER (which is used as the URI for the INVITE with Replaces). For a more concrete example (See ) assume that the transfer target (TT) is forwarding calls when busy to TT'. When the consultative INVITE gets to the transfer target it is redirected via a 302 to TT'. Note that a proxy (P) is inserted below to illustrate that the transferor (TC) may have no way of knowing that the consultative call was forwarded from TT to TT'.

TC TE P TT TT' <=talking=> ---I(hold)---> <---100,200--- -----ACK-----> (busy) --------I(consult)-------> -I(consult)-> <----302----- -----ACK----> -------I(consult)---------> <-------100,180,200-------- <-------100,180,200------- -----------------------ACK-------------------------> <================(consultation)====================> (not busy) ----REFER---> <----202----- -I(replaces)-> -I(replaces)-> <-----481----- <----481----- -----ACK----> <---N(503)--- -----200----> Consultative Transfer to the Wrong Target

The following set of issues and requirements relate to undesirable user experiences in consultative transfer scenarios.

Currently when a transfer target receives a consultative call it looks like any other independent INVITE. The user agent cannot give the user any sort of hint that this is related to a transfer or that it is a consultation. At best a user answering the consultative call is presented with the caller ID of the transferor. It would be desirable to improve this user experience. For example it might be better to be able to provide the user on the transfer target with information of the form: "Incoming consultation from: <transferor ID> with intent to transfer: <transferee ID>". The transferee Id is not present in the consultative INVITE.

In the consultative turned blind case the transfer controller initiates a consultative INVITE to the transfer target, sends a CANCEL and then a REFER (to the transferee) to perform the blind transfer. This sometimes creates an awkward experience on the transfer target. The consultative INVITE comes in and rings for a short period of time. Then that call is CANCELed. Afterwards the transferee receives the REFERred INVITE and starts ringing again. The transfer target hears the phone ring twice and may see two different caller Ids. It is probably not desirable to change the signaling approach (i.e. INVITE, CANCEL, REFER) at this point. However if the transfer target user agent were given more hints as to what was going on, it could potentially hide the double ring and changing caller Ids.

The following set of requirements relate to SIP signaling gateways (PSTN and others).

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 TDM side of a SIP gateway. The transferor is a SIP phone purely in the IP space. The transfer target is on the TDM 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 TDM 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 TDM side. Then the target call would not involve the gateway. Gateway ports can be expensive or limited resources. It is therefore desirable to keep their utilization to a minimum. For example, in a hybrid situation a SIP to PSTN gateway may be used to extend the life of a TDM switch that is at its maximum for line and trunk cards. The last few valuable trunk cards are used to glue in the gateway with the desire of using SIP (proxy, etc.) to get a higher density of utilization from the trunk lines. A hairpin through the gateway consumes two ports that could be switched in the TDM switch, freeing both gateway ports. This is easier to accomplish if the hairpin is on the same T1. It is certainly very difficult to accomplish if the hairpin is across two different gateways. Even if the hairpin cannot be eliminated by being pushed to the other side of the gateway, there are other scenarios where coercing the two legs of a hairpin onto the same gateway is very desirable for network traffic optimization (e.g. avoiding the traffic in and out over two limited WAN connections if the gateways are at different sites.). 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.

In the consultative transfer case turned blind, there is a glare-like problem. The transferor initiates the consultation INVITE, the user gets impatient and hangs up, transitioning this to a blind transfer. The transfer target on the gateway (connected through a TDM 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 TDM side, but gets either a busy or lands in the users voicemail as the user has the handset in hand and off hook. In this scenario the simplest requirement, might be to disallow consultative transfer. An alternative requirement might be to disallow the transition from consultative to blind transfer. Either way the transferor needs to know ahead of time what the transfer target can and cannot do.

The following are mostly implementation oversights or misunderstandings that are commonly seen in the field and at SIPit events. These are just a few examples. Transfer is very complicated and too few implementations get it right or are robust. The robustness problem is probably largely due to the number of points of failure. In the consultative case there are three dialogs among three user agents and it takes 8 or more transactions to complete it all. Each transaction can fail for various reasons, etc. [Should these be here at all? Is it worth writing these up into a more expanded list in the next revision?]

Some SIP user agents only support blind transfer. This may be because the user agent only supports a single dialog or line or it may simply be a business decision. The problem is that this is not typically discovered until the INVITE with Replaces header is sent. This is probably more a best current practices issue rather than a protocol issue. If in the consultative INVITE, the transferor includes a Requires header with the "replaces" token in the value AND the transfer target correctly observes the Requires header, this would not be a problem. The transferor would get a 420 Bad Extension response. It could then try a blind transfer using REFER.

Two common mistakes are made when a consultative transfer transitions to a blind transfer. Some implementations of the transferor do not send a CANCEL. They try to use Replaces to replace the early dialog. This is documented in Replaces as not supported because it just does not work. You cannot reliably replace a dialog on the user agent server side because (due to forking )it is a moving target. The other common mistake is to not wait for the outcome of the CANCEL. The transferor MUST CANCEL the consultative INVITE, wait for the CANCEL to succeed, then send the REFER without Replaces. If the CANCEL fails (as the dialog was setup with a 200 response), the transferor can then send the REFER with Replaces as the consultative call is no longer an early dialog.

This section contains some initial thoughts on ways to resolve the requirements in . The following are at least preliminary approaches to resolving the requirements identified in this draft. They are mostly independent and can be used separately or all together. These solutions are not intended to be complete. The descriptions are here for discussion on how to proceed.

Applicable to: , , , In the consultative INVITE, the transferor MUST put the replaces token in the Requires header. In common practice this is often not done. Even if it was used in practice, it is probably not sufficient to completely solve the double ring (see ) and gateway glare (see ) problems. It will allow a gateway or user agent acting as the role of transfer target to say "I do not want to perform a consultative transfer". Often the only problem or limitation is the troublesome transition from consultative to blind transfer. To avoid restricting the use of a pure consultative transfer, one could instead restrict the use of the transition from consultative to blind. This can be accomplished by creating a new options token consult2blind. The transferor MUST put this token in the Requires header if it allows the user to back out of the consultation and transition to a blind transfer.

Applicable to: , , Create a new header 'Related' to generally relate a request to another dialog. Create tokens for that header that define the type of relationship between the message containing the Related header and the referenced dialog. The syntax specifies a dialog similar to the Replaces syntax. However the Related header specifies a relationship as opposed to a specific operation as the Replaces header does. In addition the relationship is abstract for the header and specified by the relationship token.

"Related" HCOLON relation SEMI dialog-param *(SEMI generic-param) relation = ("consult" / token) dialog-param = callid SEMI to-param SEMI from-param to-param = to-tag / early-flag tfrom-param = from-tag / early-flag to-tag = "to-tag" EQUAL token from-tag = "from-tag" EQUAL token early-flag = "early-only" Example: Related: consult; 8719100197@10.1.1.123; to-tag=98748; from-tag=99173 In the context of transfer this can be used to relate the consultative INVITE request with the original dialog between the transferor and the transferee. This is useful to the transfer target's user agent. The consultative INVITE should contain the Related header with the consult token and the dialog information of the original call. In the gateway context it is useful to the location server in deciding which gateway to route the request to. The location server can use the dialog package or any maintained call state to find which gateway is currently servicing the original call and attempt to use the same gateway for the consultation and target calls. This also has the side effect of specifying that this INVITE is a consultation.

A proposal exists for conveying trunk group information . This may be useful in helping to get all of the legs in the transfer on to the same gateway and trunk group.

By putting all of the TDM legs of the transfer parties on the same gateway and providing the gateway with the ability to disallow consultative transfer, it should be possible to perform the transfer on the TDM side. The consultative dialog can be disallowed by the gateway as described in . All of the transfer dialogs can be associated by the gateway as described in . This also gives the gateway enough information to selectively decide when to disallow consultative transfer (i.e. if it knows it has one leg of the original call related to the consultation). This also assumes the gateway location service has dialog state awareness of the original transfer dialog and can route the consultation to the same gateway. If the gateway uses more than one trunk group it may be necessary to apply as well to get all of the TDM legs of the transfer out the same trunk group.

Applicable to: , Create a new header to relate address of records outside of a dialog. Create named tokens to label the type of relationship of the AOR to this dialog or transaction. This could be thought of as a general purpose Referred-By header . This is useful in the consultative INVITE request to allow the transferor to say this consultation is with regards to transferring the given AOR who is the transferee.

"Actor" HCOLON acttoken SEMI name-addr *(SEMI generic-param) acttoken = "transferee" / token Example: Actor: transferee; Joe Transferee<sip:joe@example.com> This syntax could be combined with that in . However they seem more broadly applicable to other SIP features if they are useable independently.

Applicable to: Create a transfer target URI analogous to the Conference URI in . This URI needs to be globally routable such that the transferor and the transferee (potentially in different domains) can both reach the transfer target via the URI. The URI must be unique to the consultative dialog residing on the transfer target. It cannot be the same for other dialogs (early or established) created as a result of the consultation.

Applicable to: , A more drastic approach to the problems associated with transitioning from consultative to blind transfer would be to simply disallow it completely. This would require that the transferor hang on to and complete the consultation dialog until it was setup or failed. This might make it impossible for some user agents to do consultative transfer due to limitations of having only one active dialog at a time. This solution does not seem very desirable from a market requirements and end user expectations perspective.

Applicable to: , An implementation approach to solving some problems on the transfer target caused by the transition from consultative to blind transfer is to hold on to the resources on the far end a little longer. That is, on a phone user agent, hold on to the ringer resource a little longer (e.g. 5 seconds) in the hopes that the blind transfer will come in that can be associated with the CANCELed consultation. If it does, then the blind transfer INVITE gets the ringer resource - covering up the audio artifact that the consultation was CANCELed. In the case where a PSTN gateway is the transfer target, it could hold on to the PSTN resource in an analogous way to the ringer on the phone.

TBD