Ariadne Internet Services, Inc.

738 Main St. Waltham MA 02451 US +1 781 647 9199 worley@ariadne.com

Transport SIP REFER The REFER method is defined in RFC 3515. That RFC defines the syntax of the REFER request and some of the machinery involved in its execution, but it defines the semantics of the method only so far as to specify that the recipient will initiate a request to the target specified in the Refer-To header. But since almost all requests that can be sent by the recipient are inherently part of an encompassing UA action that affects the state of the recipient in ways that are not directly reflected in SIP protocol actions, the standardized action of initiating a request implicitly has further consequences which are often not clearly specified. As a result, various SIP call-control proposals assume that a UA receiving a REFER will perform the UA operation that is needed at that moment without specifying clearly how the UA recognizes which UA operation is needed. As a result there are now five semantically distinct defined uses of REFER. All five uses bear a family resemblance, and each involves sending a SIP request, but the exact meaning of each use is logically independent of the others, and the rules by which a UA distinguishes the five cases are at best implicit.

The REFER method is defined in . That RFC defines the syntax of the REFER request, that its recipient is expected to "contact" the resource designated by the Refer-To URI, and some of the machinery involved in its execution. But the RFC does not specify what the request causes the recipient to do in relationship to other SIP dialogs, its users, etc. This allows a SIP call-control process to assume that a REFER will cause the UA to perform the operation that would be convenient for that particular call-control process - an operation which would naturally be implemented by sending the SIP request specified, but unfortunately, the implementing SIP request does not uniquely determine the UA operation. As a result, there are now five defined uses of REFER. All five uses bear a family resemblance, but the exact meaning of each use is logically independent of the others. The purpose of this document is to enumerate all semantically distinct uses of REFER, expose the logic that is used to determine which use is implied by any particular REFER request, and to make people aware of the need to clearly specify any additional uses they desire to create. The reader is expected to be familiar with the machinery of the REFER request as described in .

The simplest application of REFER can be called "remote dial" . In this usage, a REFER is sent out-of-dialog to a recipient UA. The recipient UA sends a dialog-initiating INVITE to the Refer-To URI, to establish a dialog for its user. At first sight, this use may appear unlikely in practice, but sending such a REFER to a UA can be used to induce it to join a conference . (That is feasible because each conference has a unique "conference URI".) Similarly, a remote dial REFER can be sent to a conference focus to induce it to send an INVITE to a UA that one wishes to have join the conference. This is a natural way to implement "click-to-dial" functionality.

The most popular use of REFER is for transferring calls . From a user perspective, there are several different kinds of call transfer, but in all cases, the crucial step is performed by a REFER request. Using the terminology of , there is an existing dialog between Transferor and Transferee. Transferor wants to terminate that dialog, changing Transferee's focus from the existing dialog to a new dialog with Transfer Target. This action is done by Transferor sending a REFER in the existing dialog to Transferee. Transferee sends a dialog-initiating INVITE to Transfer Target. If and when the INVITE receives a successful response, Transferee terminates the original dialog and changes its focus to the new dialog.

Another envisioned use of REFER is to delete a third party from a conference . In this use, the executor sends a REFER with a Refer-To containing the header parameter "method=BYE" to a conference focus, causing it to send a BYE to the participant. In this use of REFER, the recipient UA is requested to insert a BYE request into an existing dialog, rather than sending an out-of-dialog request. The dialog in question is implicitly identified by the Refer-To URI, which is expected to be the URI of a participant in the conference. Of course, this requires that there be only one participant in the conference that entered using that URI.

REFER can also be used more generally to terminate a dialog by causing one UA in the dialog to send a BYE request. The dialog to be terminated is specified by using Call-ID, To, and From header parameters in the Refer-To URI to specify that the BYE should be sent within the specified dialog. The example given in is (after correcting the escaping):

sip:bob@babylon.biloxi.example.com;method=BYE ?Call-ID=13413098 &To=%3Csip:bob%40biloxi.com%3E%3Btag%3D879738 &From=%3Csip:alice%40atlanta.example.com%3E%3Btag%3D023214

Beware that using header parameters to specify Call-ID and From headers contravenes section 19.1.5 of RFC 3261 . We interpret this contradiction to mean that the values specified must be validated by the UA to match one of its dialogs (and that the REFER requester is allowed to manipulate that dialog).

The Internet-Draft proposes a URI parameter "response" to be used in the Refer-To URI. Its presence indicates that the recipient of the REFER should send a response to one of its existing early dialogs, using the value of the "response" URI parameter as the response code. The early dialog in question is identified by the Target-Dialog header in the REFER request. However, it is not clear (to this author) whether this use of Target-Dialog is semantically compatible with the definition given in , which specifies that Target-Dialog is to be used to authorize a request because "it indicates to the recipient that the sender is aware of an existing dialog with the recipient".

Meaning Distinguishing features Action Remote Dial Out-of-dialog, method=INVITE UA sends a dialog-initiating INVITE to Refer-To URI. Transfer #1 In-dialog, method=INVITE UA sends a dialog-initiating INVITE to Refer-To URI. When new dialog is confirmed, UA terminates the original dialog and transfers its focus to the new dialog. Transfer #2 In-dialog, method=INVITE, Replaces header parameter (Same implementation as Transfer #1.) UA sends a dialog-initiating INVITE with a Replaces header to Refer-To URI. When new dialog is confirmed (thus replacing the specified dialog at the Refer-To UA), UA terminates the original dialog and transfers its focus to the new dialog. Transfer #3 Out-of-dialog, method=INVITE, Replaces header parameter (Same implementation as Remote Dial.) UA sends a dialog-initiating INVITE with a Replaces header to Refer-To URI. New dialog replaces the specified dialog at the Refer-To UA. Third-Party Conference Departure recipient is conference URI, method=BYE Conference focus uses Refer-To URI to look up a dialog currently in the conference, then terminates it by sending BYE on it. Remote Hangup method=BYE, Call-ID, To, and From header parameters UA terminates the specified dialog by sending BYE on it. Remotely Induced Response response URI parameter, Target-Dialog header UA sends the specified response to the early dialog identified by the Target-Dialog header.

None.