Network Working Group J. Ronberg Request for Comments: 3725 dynamicsoft BCP: 85 J. Peterson Category: Best Current Practice Neustar H. Schulzrinne Columbia University G. Camarillo Ericsson April 2004 Best Current Practices for Third Party Call Control (3pcc)
in the Session Initiation Protocol (SIP)
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Rerved. Abstract
Third party call control refers to the ability of one entity to
create a call in which communication is actually between other
parties. Third party call control is possible using the mechanisms
specified within the Session Initiation Protocol (SIP). However,
there are veral possible approaches, each with different benefits
and drawbacks. This document discuss best current practices for
the usage of SIP for third party call control.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
4. 3pcc Call Establishment . . . . . . . . . . . . . . . . . . 3 4.1. Flow I . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Flow II. . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Flow III . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Flow IV. . . . . . . . . . . . . . . . . . . . . . . . 8
5. Recommendations . . . . . . . . . . . . . . . . . . . . . . 9
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 10
7. Continued Processing . . . . . . . . . . . . . . . . . . . . 11
8. 3pcc and Early Media . . . . . . . . . . . . . . . . . . . . 13 Ronberg, et al. Best Current Practice [Page 1]
9. Third Party Call Control and SDP Preconditions . . . . . . . 16 9.1. Controller Initiates . . . . . . . . . . . . . . . . . 16
9.2. Party A Initiates. . . . . . . . . . . . . . . . . . . 18
10. Example Call Flows . . . . . . . . . . . . . . . . . . . . . 21 10.1. Click-to-Dial. . . . . . . . . . . . . . . . . . . . . 21
10.2. Mid-Call Announcement Capability . . . . . . . . . . . 23
11. Implementation Recommendations . . . . . . . . . . . . . . . 25
12. Security Considerations. . . . . . . . . . . . . . . . . . . 26 12.1. Authorization and Authentication . . . . . . . . . . . 26
12.2. End-to-End Encryption and Integrity. . . . . . . . . . 27
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 14.1. Normative References . . . . . . . . . . . . . . . . . 28
14.2. Informative References . . . . . . . . . . . . . . . . 29
15. Authors’ Address . . . . . . . . . . . . . . . . . . . . . 30
16. Full Copyright Statement . . . . . . . . . . . . . . . . . . 31 1. Introduction
In the traditional telephony context, third party call control allows one entity (which we call the contr
oller) to t up and manage a
communications relationship between two or more other parties. Third party call control (referred to as 3pcc) is often ud for operator
rvices (where an operator creates a call that connects two
participants together) and conferencing.
Similarly, many SIP rvices are possible through third party call
control. The include the traditional ones on the PSTN, but also
new ones such as click-to-dial. Click-to-dial allows a ur to click on a web page when they wish to speak to a customer rvice
reprentative. The web rver then creates a call between the ur and a customer rvice reprentative. The call can be between two
phones, a phone and an IP host, or two IP hosts.
Third party call control is possible using only the mechanisms
十大玄幻小说排行榜
specified within RFC 3261 [1]. Indeed, many different call flows are possible, each of which will work with SIP compliant ur agents.连招
However, there are benefits and drawbacks to each of the flows.
The usage of third party call control also becomes more complex when aspects of the call utilize SIP extensions or optional features of
SIP. In particular, the usage of RFC 3312 [2] (ud for coupling of signaling to resource rervation) with third party call control is
non-trivial, and is discusd in Section 9. Similarly, the usage of early media (where ssion data is exchanged before the call is
accepted) with third party call control is not trivial; both of them specify the way in which ur agents generate and respond to SDP, and it is not clear how to do both at the same time. This is discusd
further in Section 8.
Ronberg, et al. Best Current Practice [Page 2]
非诚勿扰停播This document rves as a best current practice for implementing
third party call control without usage of any extensions specifically designed for that purpo. Section 4 prents the known call flows
that can be ud to achieve third party call control, and provides
guidelines on their usage. Section 9 discuss the interactions of
RFC 3312 [2] with third party call control. Section 8 discuss the interactions of early media with third party call control. Section
10 provides example applications that make usage of the flows
recommended here.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and indicate requirement levels for compliant implementations.
3. Definitions
The following terms are ud throughout this document:
3pcc: Third Party Call Control, which refers to the general ability
to manipulate calls between other parties.
Controller: A controller is a SIP Ur Agent that wishes to create a ssion between two other ur agents.
4. 3pcc Call Establishment
The primary primitive operation of third party call control is the
establishment of a ssion between participants A and B.
Establishment of this ssion is orchestrated by a third party,
referred to as the controller.
This ction documents three call flows that the controller can
utilize in order to provide this primitive operation.
Ronberg, et al. Best Current Practice [Page 3]
A Controller B
|(1) INVITE no SDP | |
|<------------------| |
|(2) 200 offer1 | |
|------------------>| |
| |(3) INVITE offer1 |
政治审查报告
| |------------------>|
| |(4) 200 OK answer1 |
| |<------------------|
| |(5) ACK |pos系统
| |------------------>|
|(6) ACK answer1 | |
|<------------------| |
|(7) RTP | |
|.......................................|
Figure 1
The call flow for Flow I is shown in Figure 1. The controller first nds an INVITE A (1). This INVIT
留恋是什么意思E has no ssion description. A’s phone rings, and A answers. This results in a 200 OK (2) that
contains an offer [4]. The controller needs to nd its answer in
the ACK, as mandated by [1]. To obtain the answer, it nds the
offer it got from A (offer1) in an INVITE to B (3). B’s phone rings. When B answers, the 200 OK (4) contains the answer to this offer,
answer1. The controller nds an ACK to B (5), and then pass
answer1 to A in an ACK nt to it (6). Becau the offer was
generated by A, and the answer generated by B, the actual media
ssion is between A and B. Therefore, media flows between them (7). This flow is simple, requires no manipulation of the SDP by the
controller, and works for any media types supported by both
endpoints. However, it has a rious timeout problem. Ur B may
not answer the call immediately. The result is that the controller
cannot nd the ACK to A right away. This caus A to retransmit the 200 OK respon periodically. As specified in RFC 3261 Section
13.3.1.4, the 200 OK will be retransmitted for 64*T1 conds. If an ACK does not arrive by then, the call is considered to have failed.
This limits the applicability of this flow to scenarios where the
小儿风湿热controller knows that B will answer the INVITE immediately. Ronberg, et al. Best Current Practice [Page 4]
A Controller B
|(1) INVITE bh sdp1 | |
|<------------------| |
|(2) 200 sdp2 | |
|------------------>| |
| |(3) INVITE sdp2 |
| |------------------>|
|(4) ACK | |
|<------------------| |
| |(5) 200 OK sdp3 |
| |<------------------|
| |(6) ACK |
| |------------------>|低碳生活的意义
|(7) INVITE sdp3 | |
|<------------------| |
|(8) 200 OK sdp2 | |
|------------------>| |
|(9) ACK | |
|<------------------| |
|(10) RTP | |
|.......................................|
Figure 2
An alternative flow, Flow II, is shown in Figure 2. The controller
first nds an INVITE to ur A (1). This is a standard INVITE,
containing an offer (sdp1) with a single audio media line, one codec,
a random port number (but not zero), and a connection address of
0.0.0.0. This creates an initial media stream that is "black holed", since no media (or RTCP packets [8]) will flow from A. The INVITE
caus A’s phone to ring.
Note that the usage of 0.0.0.0, though recommended by RFC 3264,
has numerous drawbacks. It is anticipated that a future
specification will recommend usage of a domain within the .invalid DNS top level domain instead of the 0.0.0.0 IP address. As a
result, implementors are encouraged to track such developments
once they ari.
When A answers (2), the 200 OK contains an answer, sdp2, with a valid address in the connection line. The controller nds an ACK (4). It then generates a cond INVITE (3). This INVITE is addresd to ur B, and it contains sdp2 as the offer to B. Note that the role of sdp2 has changed. In the 200 OK (message 2), it was an answer, but in the INVITE, it is an offer. Fortunate
ly, all valid answers are valid Ronberg, et al. Best Current Practice [Page 5]
