Internet DRAFT - draft-bhatia-3pcc-refer
draft-bhatia-3pcc-refer
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 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 [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 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]
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: <sip:A@agentland>
From: <sip:B@controller.nextone.net>;tag=193402342
Call-ID: 898234234@controller.nextone.net
CSeq: 93809823 REFER
Refer-To: <sip:B@controller@nextone.net?Replaces:12345%40192.168.118.3;
to-tag=12345;from-tag=5FFE-3994>
Referred-By: <sip:B@controller.nextone.net>
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:B@controller@nextone.net?Replaces:12345%40192.168.118.3;
to-tag=12345;from-tag=5FFE-3994> SIP/2.0
Via: SIP/2.0/UDP sip:A@agentland
From: A <sip:A@agentland>;tag=3pcc
To: B <B@controller@nextone.net>
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
The same mechanism can be used in the middle of a call. This is the
scenario when the controller already has a call up with A. The only
change in this case is that the REFER is sent on the existing call
leg. The call flows in this case are similar to the call transfer
call flows given the sip-call-transfer draft. In this case A sends
a NOTIFY back to the controller, containing the status of the
REFER, and the controller disconnects the old call with A by
sending a BYE to it.
A Controller B
| | |
| | |
| REFER callid1 | |
|<------------------| |
| | |
| 202 Accepted | |
|------------------>| |
| | |
|INVITE callid1 SDPA| |
|------------------>| |
| | |
| | INVITE SDP A |
| |----------------->|
| | |
| | 200 SDP B |
| |<-----------------|
| | |
| 200 SDP B | |
|<------------------| |
| | |
| ACK | |
|------------------>| |
| | |
| | ACK |
| |----------------->|
| NOTIFY (200 OK) | |
|------------------>| |
| | |
| 200 OK | |
|<------------------| |
| | |
| BYE | |
|<------------------| |
| | |
| | RTP |
|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|
|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|
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.
8. Changes since -00
o Added call flow diagrams
Author's Address
Medhavi Bhatia
NexTone Communications
9700 Great Seneca Highway
Rockville, MD 20874
EMail: mbhatia@nextone.com
Expires: Feb 15, 2002 3pcc using the REFER method
