M. Bhatia Internet-Draft NexTone Communications draft-bhatia-3pcc-refer-00.txt Sept 26, 2001 Expires: Feb 27, 2001 3pcc using the REFER method Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on [March 5, 2002]. Abstract This document defines a method for third party call control using the REFER method. The usage of Session Initiation Protocol SIP [3] for third party call control is discused in [1], and the REFER method is defined in [2]. 1. Introduction The application and description of third party call control, and how the Session Initiation Protocol (SIP) [3] can be used to provide such an application is discussed in [1]. Using the call flows defined in [1] we can use SIP without any new extensions. In this document, we present an alternate mechanism to do the same applications using the REFER method, which is a SIP extension defined in [2]. There are advantages of using this approach over the approach described in [1], in terms of reduced complexity. 2. Definitions controller: the entity which sets up a call relationship between two parties. This has the same meaning as in [1]. A, B: Peers of the controller in a call setup using third party call call control. A will be understood to be on leg 1 of the call, which is set up first and B to be on the leg 2 of the call which is bridged with leg 1 subsequently. 2. Overview of approach specified in [1] [1] specifies two call flows to solve the 3pcc problem. They are referred as "First Attempt" and "Third Flow". In this document we will refer to them as [1].f1, and [1].f2. [1].f1 is the simpler of the two and is advisable to use only if the controller knows that B will accept the call immediately. [1].f2 is the more general call flow guaranteed to work in most of the cases. However, in certain situations, an alternate solution may be desired: 1. [1].f2 requires the controller to go back and forth between two call legs, in order to set up the call. In terms of information transfer, the application is really simple, but is complicated because of the following requirements of RFC 2543: (a) An ACK must immediately be sent following a 200 OK to an INVITE, otherwise we have problems of retransmission and timeouts. (b) After a re-INVITE, a UA may change the SDP it has been using for the call, in its response . This can result in an infinite loop of re-INVITES. (c) A UA may respond to a media "on-hold" with a media "on-hold", which results in a "deadlock". [1].f2 does no consider the fact that after receiving an ACK with held media, the UA may also decide to send a re-INVITE with held media. This can be handled by the controller, but does cause an extra complication in the call flows. The controller also has to perform SDP manipulations, where it has to replace SDP with held SDP. 2. Both [1].f1 and [1].f2 depend on using INVITE with no SDP. Even though support for this will increase with time, some SIP devices, like the IWF (SIP/H.323 Interworking) gateways exhibit an interoperability problem when INVITE without SDP is used in the beginning of a call. 3. Problem definition In order to find another approach lets look at what is the problem that [1] attempts to solve. 3.1 How does INVITE without SDP help ? An INVITE without SDP solves several problems for the controller. First, the controller need not assume anything about the media or the ports the call is going to use. In essence the controller is asking A (recepient) to make the call to it. The last two steps (OK and ACK) of this kind of a transaction are similar in terms of information flow to the first two steps of a regular transaction (INVITE and OK). Also, in this case A need not know the ultimate destination of the call, which may be useful in some applications, where A might get connected to an intermediate entity like a media server. However there is one drawback of using the INVITE without SDP. The controller has to immediately respond with an ACK to the 200 OK from A, and the ACK must have SDP in it. In some situations, the controller inserts the held SDP in the response. This creates an artificial situation, where A thinks its being put on hold. This problem never arises when INVITE no SDP is used in the middle of the call, as it is basically [1].f1 (without any of its retransmission problems). 3.3 Problem goal: What do we need ? (a) Need a mechanism by which we can trigger A to initiate the call to the controller. (b) In response to the A's triggering of the call, the controller should not have to send the final response immediately. (c) This call which A initiates must pass through the controller. (d) Controller must be able to identify the incoming call from A in the right context. ie., it should be able to distinguish the call from a regular call made by A to the controller. (e) The mechanism the controller employs to trigger A into making the call should be usable in an independent call leg as well as in an already established call leg. 4.0 Using the REFER method to solve the problem. The usage of REFER, as explained in [2] satisfies (a) and (e). Condition (c) is achieved by putting the right SIP request URI in the Refer-To header. (d) is achieved by putting a "Replaces" header in the Refer-To header. When A sends the INVITE to the controller, the controller has an option of generating a "100 Trying" response (meanwhile it is proxying the INVITE to the desired destination, B). This satisfies (c). 4.1 Support required for using the REFER method: Clearly, the controller and the UA must support the REFER method, and the "Replaces" header. If the REFER is sent on an independent call leg, the controller must create a call state before sending the "Replaces" header to A. This allows the controller to put the call from A in the right context. 4.2 Using the body of SIP REFER message [2] indicates on the inclusion of a message body in a REFER method. No meaning to that body is however assigned. In this document we will assign the following meaning to the body, if its present in the REFER method: Body of the REFER method, if present, will indicate what B intends to use as SDP for the resulting call. It however gives no assurance that B will actually respond with that SDP when A initiates the call to it. It is meant solely as an advisory function, and may be used by A or any intermediate proxy sitting between A and the controller. 5. Call Flows 5.1 Basic 3pcc call flow from [1] 1. Controller creates SIP call leg 1 (Call id=12345%40192.168.118.3; to-tag=12345;from-tag=5FFE-3994), and sends a REFER to A: REFER sip:A@agentland SIP/2.0 Via: SIP/2.0/UDP controller.nextone.net To: From: ;tag=193402342 Call-ID: 898234234@controller.nextone.net CSeq: 93809823 REFER Refer-To: Referred-By: Contact: sip:B@controller.nextone.net Content-Length: 0 Note the presence of the To tag, even though the INVITE is being sent by A. The Controller may or may not put the To tag. 2. B sends a 202 Accepted to the Controller. 3. B sends an INVITE to the Controller INVITE SIP/2.0 Via: SIP/2.0/UDP sip:A@agentland From: A ;tag=3pcc To: B Call-ID: 31415@agentland CSeq: 1 INVITE Contact: A@agentland This INVITE specifies the context in the Replaces header, and now the controller forwards it to B. It also sends a Trying message to A. The responses from B are now sent back to A. In other words, after Step 3, the controller acts as a proxy. 5.2 Mid call 3pcc In cases where A is already in the middle of a call, and the Controller wants to run a new application in the middle of the call, the same technique can be used. 6. Security Considerations The security considerations of the REFER method specified in [2] dictate these scenarios. However as the REFER is sent by the controller to A, which results in a call coming in back to the controller, a lot of considerations mentioned in [2] will not apply here. For example, there is no need ever to reveal the identity of B. Also the controller is a trusted entity, which additionally simplifies security logic running on A. 7. References [1] Rosenberg/Peterson/Schulzrinne/Camarillo, Internet Draft, Internet Engineering Task Force, Mar 2002. Work in progress. [2] Sparks, R. "The Refer Method", Internet Draft, Internet Engineering Task Force, Sep 2001. Work in progress. [3] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. Author's Address Medhavi Bhatia NexTone Communications 9700 Great Seneca Highway Rockville, MD 20874 EMail: mbhatia@nextone.com Expires: Feb 27, 2001 3pcc using the REFER method