[-M. Bhatia Internet-Draft NexTone Communications draft-bhatia-3pcc-refer-01.txt Oct 16, 2001 Expires: Feb 15, 2002 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-] {+has been deleted. Unrevised+} documents [-of-] {+placed in+} 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-] {+directories have+} a maximum {+life+} 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.-] {+months. After that time, they are deleted.+} This Internet-Draft [-will expire on [Feb 15, 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-] {+was not published as+} an [-alternate mechanism to do the same applications using the REFER method, which is a SIP extension defined in [2]. There-] {+RFC. Internet-Drafts+} 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-] {+not an archival document series,+} 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-] {+expired drafts, such+} 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-] {+one, are not available; please do not ask+} 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.-] {+copies... they are not available.+} 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-] {+Secretariat+} 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-] {+have+} information [-flow-] {+as+} to [-the first two steps-] {+future plans+} of [-a regular transaction (INVITE and OK). Also, in this case A need not know-] the [-ultimate destination of-] {+authors or working groups WRT+} the [-call, which may be useful in some applications, where A might get connected to an intermediate entity like-] {+deleted Internet-Draft. For more information or+} a [-media server. However there is one drawback-] {+copy+} of [-using-] the [-INVITE without SDP. The controller has to immediately respond with an ACK to-] {+document, contact+} 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] A Controller B | | | | create callid1 | | REFER callid1 | | |<------------------| | | | | | 202 Accepted | | |------------------>| | | | | |INVITE callid1 SDPA| | |------------------>| | | | | | | INVITE SDP A | | |----------------->| | | | | | 200 SDP B | | |<-----------------| | | | | 200 SDP B | | |<------------------| | | | | | ACK | | |------------------>| | | | | | | ACK | | |----------------->| | | | | | RTP | |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| In this scenario, the controller has no ongoing calls with A and B in the beginning. It creates a local context for callid1. This context MUST contain a SIP call id, and MAY contain from and to tags locally generated at the controller. At this point the controller sends a REFER with the Replaces callid1 header to A. If A is interested in the call, it sends a 202 Accepted back to the controller. At this point the controller starts a timer, "timer-callid1", on callid1 for TC seconds. (TC is an application specific timer, which should at least take into account the retransmissions from A. ~10*T2 seconds is probably a good value). When the INVITE arrives from A with the Replaces callid1 header, the timer is cancelled, the INVITE is forwarded to B. At this point the controller may act as a Back to Back user agent or a proxy for the call duration, depending on the kind of application running on the controller. The 200 OK from B arrives and is forwared to A. This way the controller does not need to assume anything about what SDP will be used for the call. 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 INVIT