summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3725.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3725.txt')
-rw-r--r--doc/rfc/rfc3725.txt1739
1 files changed, 1739 insertions, 0 deletions
diff --git a/doc/rfc/rfc3725.txt b/doc/rfc/rfc3725.txt
new file mode 100644
index 0000000..8ee02db
--- /dev/null
+++ b/doc/rfc/rfc3725.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Network Working Group J. Rosenberg
+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 Reserved.
+
+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 several possible approaches, each with different benefits
+ and drawbacks. This document discusses 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
+
+
+
+Rosenberg, et al. Best Current Practice [Page 1]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ 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' Addresses . . . . . . . . . . . . . . . . . . . . . 30
+ 16. Full Copyright Statement . . . . . . . . . . . . . . . . . . 31
+
+1. Introduction
+
+ In the traditional telephony context, third party call control allows
+ one entity (which we call the controller) to set up and manage a
+ communications relationship between two or more other parties. Third
+ party call control (referred to as 3pcc) is often used for operator
+ services (where an operator creates a call that connects two
+ participants together) and conferencing.
+
+ Similarly, many SIP services are possible through third party call
+ control. These include the traditional ones on the PSTN, but also
+ new ones such as click-to-dial. Click-to-dial allows a user to click
+ on a web page when they wish to speak to a customer service
+ representative. The web server then creates a call between the user
+ and a customer service representative. 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 user agents.
+ However, there are benefits and drawbacks to each of these 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] (used for coupling of
+ signaling to resource reservation) with third party call control is
+ non-trivial, and is discussed in Section 9. Similarly, the usage of
+ early media (where session data is exchanged before the call is
+ accepted) with third party call control is not trivial; both of them
+ specify the way in which user agents generate and respond to SDP, and
+ it is not clear how to do both at the same time. This is discussed
+ further in Section 8.
+
+
+
+Rosenberg, et al. Best Current Practice [Page 2]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ This document serves as a best current practice for implementing
+ third party call control without usage of any extensions specifically
+ designed for that purpose. Section 4 presents the known call flows
+ that can be used to achieve third party call control, and provides
+ guidelines on their usage. Section 9 discusses the interactions of
+ RFC 3312 [2] with third party call control. Section 8 discusses 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 used 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 User Agent that wishes to create a
+ session between two other user agents.
+
+4. 3pcc Call Establishment
+
+ The primary primitive operation of third party call control is the
+ establishment of a session between participants A and B.
+ Establishment of this session is orchestrated by a third party,
+ referred to as the controller.
+
+ This section documents three call flows that the controller can
+ utilize in order to provide this primitive operation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et al. Best Current Practice [Page 3]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+4.1. Flow I
+
+
+ A Controller B
+ |(1) INVITE no SDP | |
+ |<------------------| |
+ |(2) 200 offer1 | |
+ |------------------>| |
+ | |(3) INVITE offer1 |
+ | |------------------>|
+ | |(4) 200 OK answer1 |
+ | |<------------------|
+ | |(5) ACK |
+ | |------------------>|
+ |(6) ACK answer1 | |
+ |<------------------| |
+ |(7) RTP | |
+ |.......................................|
+
+ Figure 1
+
+ The call flow for Flow I is shown in Figure 1. The controller first
+ sends an INVITE A (1). This INVITE has no session description. A's
+ phone rings, and A answers. This results in a 200 OK (2) that
+ contains an offer [4]. The controller needs to send its answer in
+ the ACK, as mandated by [1]. To obtain the answer, it sends 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 sends an ACK to B (5), and then passes
+ answer1 to A in an ACK sent to it (6). Because the offer was
+ generated by A, and the answer generated by B, the actual media
+ session 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 serious timeout problem. User B may
+ not answer the call immediately. The result is that the controller
+ cannot send the ACK to A right away. This causes A to retransmit the
+ 200 OK response periodically. As specified in RFC 3261 Section
+ 13.3.1.4, the 200 OK will be retransmitted for 64*T1 seconds. 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.
+
+
+
+
+
+
+
+
+Rosenberg, et al. Best Current Practice [Page 4]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+4.2. Flow II
+
+ 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 sends an INVITE to user 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
+ causes 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 arise.
+
+ When A answers (2), the 200 OK contains an answer, sdp2, with a valid
+ address in the connection line. The controller sends an ACK (4). It
+ then generates a second INVITE (3). This INVITE is addressed to user
+ 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. Fortunately, all valid answers are valid
+
+
+
+Rosenberg, et al. Best Current Practice [Page 5]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ initial offers. This INVITE causes B's phone to ring. When it
+ answers, it generates a 200 OK (5) with an answer, sdp3. The
+ controller then generates an ACK (6). Next, it sends a re-INVITE to
+ A (7) containing sdp3 as the offer. Once again, there has been a
+ reversal of roles. sdp3 was an answer, and now it is an offer.
+ Fortunately, an answer to an answer recast as an offer is, in turn, a
+ valid offer. This re-INVITE generates a 200 OK (8) with sdp2,
+ assuming that A doesn't decide to change any aspects of the session
+ as a result of this re-INVITE. This 200 OK is ACKed (9), and then
+ media can flow from A to B. Media from B to A could already start
+ flowing once message 5 was sent.
+
+ This flow has the advantage that all final responses are immediately
+ ACKed. It therefore does not suffer from the timeout and message
+ inefficiency problems of flow 1. However, it too has troubles.
+ First off, it requires that the controller know the media types to be
+ used for the call (since it must generate a "blackhole" SDP, which
+ requires media lines). Secondly, the first INVITE to A (1) contains
+ media with a 0.0.0.0 connection address. The controller expects that
+ the response contains a valid, non-zero connection address for A.
+ However, experience has shown that many UAs respond to an offer of a
+ 0.0.0.0 connection address with an answer containing a 0.0.0.0
+ connection address. The offer-answer specification [4] explicitly
+ tells implementors not to do this, but at the time of publication of
+ this document, many implementations still did. If A should respond
+ with a 0.0.0.0 connection address in sdp2, the flow will not work.
+
+ However, the most serious flaw in this flow is the assumption that
+ the 200 OK to the re-INVITE (message 8) contains the same SDP as in
+ message 2. This may not be the case. If it is not, the controller
+ needs to re-INVITE B with that SDP (say, sdp4), which may result in
+ getting a different SDP, sdp5, in the 200 OK from B. Then, the
+ controller needs to re-INVITE A again, and so on. The result is an
+ infinite loop of re-INVITEs. It is possible to break this cycle by
+ having very smart UAs which can return the same SDP whenever
+ possible, or really smart controllers that can analyze the SDP to
+ determine if a re-INVITE is really needed. However, we wish to keep
+ this mechanism simple, and avoid SDP awareness in the controller. As
+ a result, this flow is not really workable. It is therefore NOT
+ RECOMMENDED.
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et al. Best Current Practice [Page 6]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+4.3. Flow III
+
+ A Controller B
+ |(1) INVITE no SDP | |
+ |<---------------------| |
+ |(2) 200 offer1 | |
+ |--------------------->| |
+ |(3) ACK answer1 (bh) | |
+ |<---------------------| |
+ | |(4) INVITE no SDP |
+ | |--------------------->|
+ | |(5) 200 OK offer2 |
+ | |<---------------------|
+ |(6) INVITE offer2' | |
+ |<---------------------| |
+ |(7) 200 answer2' | |
+ |--------------------->| |
+ | |(8) ACK answer2 |
+ | |--------------------->|
+ |(9) ACK | |
+ |<---------------------| |
+ |(10) RTP | |
+ |.............................................|
+
+ Figure 3
+
+ A third flow, Flow III, is shown in Figure 3.
+
+ First, the controller sends an INVITE (1) to user A without any SDP
+ (which is good, since it means that the controller doesn't need to
+ assume anything about the media composition of the session). A's
+ phone rings. When A answers, a 200 OK is generated (2) containing
+ its offer, offer1. The controller generates an immediate ACK
+ containing an answer (3). This answer is a "black hole" SDP, with
+ its connection address equal to 0.0.0.0.
+
+ The controller then sends an INVITE to B without SDP (4). This
+ causes B's phone to ring. When they answer, a 200 OK is sent,
+ containing their offer, offer2 (5). This SDP is used to create a
+ re-INVITE back to A (6). That re-INVITE is based on offer2, but may
+ need to be reorganized to match up media lines, or to trim media
+ lines. For example, if offer1 contained an audio and a video line,
+ in that order, but offer2 contained just an audio line, the
+ controller would need to add a video line to the offer (setting its
+ port to zero) to create offer2'. Since this is a re-INVITE, it
+ should complete quickly in the general case. That's good, since user
+ B is retransmitting their 200 OK, waiting for an ACK. The SDP in the
+
+
+
+
+Rosenberg, et al. Best Current Practice [Page 7]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ 200 OK (7) from A, answer2', may also need to be reorganized or
+ trimmed before sending it an the ACK to B (8) as answer2. Finally,
+ an ACK is sent to A (9), and then media can flow.
+
+ This flow has many benefits. First, it will usually operate without
+ any spurious retransmissions or timeouts (although this may still
+ happen if a re-INVITE is not responded to quickly). Secondly, it
+ does not require the controller to guess the media that will be used
+ by the participants.
+
+ There are some drawbacks. The controller does need to perform SDP
+ manipulations. Specifically, it must take some SDP, and generate
+ another SDP which has the same media composition, but has connection
+ addresses equal to 0.0.0.0. This is needed for message 3. Secondly,
+ it may need to reorder and trim SDP X, so that its media lines match
+ up with those in some other SDP, Y. Thirdly, the offer from B
+ (offer2) may have no codecs or media streams in common with the offer
+ from A (offer 1). The controller will need to detect this condition,
+ and terminate the call. Finally, the flow is far more complicated
+ than the simple and elegant Flow I (Figure 1).
+
+4.4. Flow IV
+
+ A Controller B
+ |(1) INVITE offer1 | |
+ |no media | |
+ |<---------------------| |
+ |(2) 200 answer1 | |
+ |no media | |
+ |--------------------->| |
+ |(3) ACK | |
+ |<---------------------| |
+ | |(4) INVITE no SDP |
+ | |--------------------->|
+ | |(5) 200 OK offer2 |
+ | |<---------------------|
+ |(6) INVITE offer2' | |
+ |<---------------------| |
+ |(7) 200 answer2' | |
+ |--------------------->| |
+ | |(8) ACK answer2 |
+ | |--------------------->|
+ |(9) ACK | |
+ |<---------------------| |
+ |(10) RTP | |
+ |.............................................|
+
+ Figure 4
+
+
+
+Rosenberg, et al. Best Current Practice [Page 8]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ Flow IV shows a variation on Flow III that reduces its complexity.
+ The actual message flow is identical, but the SDP placement and
+ construction differs. The initial INVITE (1) contains SDP with no
+ media at all, meaning that there are no m lines. This is valid, and
+ implies that the media makeup of the session will be established
+ later through a re-INVITE [4]. Once the INVITE is received, user A
+ is alerted. When they answer the call, the 200 OK (2) has an answer
+ with no media either. This is acknowledged by the controller (3).
+ The flow from this point onwards is identical to Flow III. However,
+ the manipulations required to convert offer2 to offer2', and answer2'
+ to answer2, are much simpler. Indeed, no media manipulations are
+ needed at all. The only change that is needed is to modify the
+ origin lines, so that the origin line in offer2' is valid based on
+ the value in offer1 (validity requires that the version increments by
+ one, and that the other parameters remain unchanged).
+
+ There are some limitations associated with this flow. First, user A
+ will be alerted without any media having been established yet. This
+ means that user A will not be able to reject or accept the call based
+ on its media composition. Secondly, both A and B will end up
+ answering the call (i.e., generating a 200 OK) before it is known
+ whether there is compatible media. If there is no media in common,
+ the call can be terminated later with a BYE. However, the users will
+ have already been alerted, resulting in user annoyance and possibly
+ resulting in billing events.
+
+5. Recommendations
+
+ Flow I (Figure 1) represents the simplest and the most efficient
+ flow. This flow SHOULD be used by a controller if it knows with
+ certainty that user B is actually an automata that will answer the
+ call immediately. This is the case for devices such as media
+ servers, conferencing servers, and messaging servers, for example.
+ Since we expect a great deal of third party call control to be to
+ automata, special casing in this scenario is reasonable.
+
+ For calls to unknown entities, or to entities known to represent
+ people, it is RECOMMENDED that Flow IV (Figure 4) be used for third
+ party call control. Flow III MAY be used instead, but it provides no
+ additional benefits over Flow IV. However, Flow II SHOULD NOT be
+ used, because of the potential for infinite ping-ponging of re-
+ INVITEs.
+
+ Several of these flows use a "black hole" connection address of
+ 0.0.0.0. This is an IPv4 address with the property that packets sent
+ to it will never leave the host which sent them; they are just
+
+
+
+
+
+Rosenberg, et al. Best Current Practice [Page 9]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ discarded. Those flows are therefore specific to IPv4. For other
+ network or address types, an address with an equivalent property
+ SHOULD be used.
+
+ In most cases, including the recommended flows, user A will hear
+ silence while the call to B completes. This may not always be ideal.
+ It can be remedied by connecting the caller to a music-on-hold source
+ while the call to B occurs.
+
+6. Error Handling
+
+ There are numerous error cases which merit discussion.
+
+ With all of the call flows in Section 4, one call is established to
+ A, and then the controller attempts to establish a call to B.
+ However, this call attempt may fail, for any number of reasons. User
+ B might be busy (resulting in a 486 response to the INVITE), there
+ may not be any media in common, the request may time out, and so on.
+ If the call attempt to B should fail, it is RECOMMENDED that the
+ controller send a BYE to A. This BYE SHOULD include a Reason header
+ [5] which carries the status code from the error response. This will
+ inform A of the precise reason for the failure. The information is
+ important from a user interface perspective. For example, if A was
+ calling from a black phone, and B generated a 486, the BYE will
+ contain a Reason code of 486, and this could be used to generate a
+ local busy signal so that A knows that B is busy.
+
+ A Controller B
+ |(1) INVITE offer1 | |
+ |no media | |
+ |<---------------------| |
+ |(2) 200 answer1 | |
+ |no media | |
+ |--------------------->| |
+ |(3) ACK | |
+ |<---------------------| |
+ | |(4) INVITE no SDP |
+ | |--------------------->|
+ | |(5) 180 |
+ | |<---------------------|
+ |(6) INVITE offer2 | |
+ |--------------------->| |
+ |(7) 491 | |
+ |<---------------------| |
+ |(8) ACK | |
+ |--------------------->| |
+
+ Figure 5
+
+
+
+Rosenberg, et al. Best Current Practice [Page 10]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ Another error condition worth discussion is shown in Figure 5. After
+ the controller establishes the dialog with A (messages 1-3) it
+ attempts to contact B (message 4). Contacting B may take some time.
+ During that interval, A could possibly attempt a re-INVITE, providing
+ an updated offer. However, the controller cannot pass this offer on
+ to B, since it has an INVITE transaction pending with it. As a
+ result, the controller needs to reject the request. It is
+ RECOMMENDED that a 491 response be used. The situation here is
+ similar to the glare condition described in [1], and thus the same
+ error handling is sensible. However, A is likely to retry its
+ request (as a result of the 491), and this may occur before the
+ exchange with B is completed. In that case, the controller would
+ respond with another 491.
+
+7. Continued Processing
+
+ Once the calls are established, both participants believe they are in
+ a single point-to-point call. However, they are exchanging media
+ directly with each other, rather than with the controller. The
+ controller is involved in two dialogs, yet sees no media.
+
+ Since the controller is still a central point for signaling, it now
+ has complete control over the call. If it receives a BYE from one of
+ the participants, it can create a new BYE and hang up with the other
+ participant. This is shown in Figure 6.
+
+ A Controller B
+ |(1) BYE | |
+ |------------------>| |
+ |(2) 200 OK | |
+ |<------------------| |
+ | |(3) BYE |
+ | |------------------>|
+ | |(4) 200 OK |
+ | |<------------------|
+
+ Figure 6
+
+ Similarly, if it receives a re-INVITE from one of the participants,
+ it can forward it to the other participant. Depending on which flow
+ was used, this may require some manipulation on the SDP before
+ passing it on.
+
+ However, the controller need not "proxy" the SIP messages received
+ from one of the parties. Since it is a Back-to-Back User Agent
+ (B2BUA), it can invoke any signaling mechanism on each dialog, as it
+ sees fit. For example, if the controller receives a BYE from A, it
+ can generate a new INVITE to a third party, C, and connect B to that
+
+
+
+Rosenberg, et al. Best Current Practice [Page 11]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ participant instead. A call flow for this is shown in Figure 7,
+ assuming the case where C represents an end user, not an automata.
+ Note that it is just Flow IV.
+
+ A Controller B C
+ |(1) BYE | | |
+ |--------------->| | |
+ |(2) 200 OK | | |
+ |<---------------| | |
+ | |(3) INV no media| |
+ | |-------------------------------->|
+ | |(4) 200 no media| |
+ | |<--------------------------------|
+ | |(5) ACK | |
+ | |-------------------------------->|
+ | |(6) INV no SDP | |
+ | |--------------->| |
+ | |(7) 200 offer3 | |
+ | |<---------------| |
+ | |(8) INV offer3' | |
+ | |-------------------------------->|
+ | |(9) 200 answer3'| |
+ | |<--------------------------------|
+ | |(10) ACK | |
+ | |-------------------------------->|
+ | |(11) ACK answer3| |
+ | |--------------->| |
+ | | |(12) RTP |
+ | | |................|
+
+ Figure 7
+
+ From here, new parties can be added, removed, transferred, and so on,
+ as the controller sees fit. In many cases, the controller will be
+ required to modify the SDP exchanged between the participants in
+ order to affect these changes. In particular, the version number in
+ the SDP will need to be changed by the controller in certain cases.
+ If the controller should issue an SDP offer on its own (for example,
+ to place a call on hold), it will need to increment the version
+ number in the SDP offer. The other participant in the call will not
+ know that the controller has done this, and any subsequent offer it
+ generates will have the wrong version number as far as its peer is
+ concerned. As a result, the controller will be required to modify
+ the version number in SDP messages to match what the recipient is
+ expecting.
+
+
+
+
+
+
+Rosenberg, et al. Best Current Practice [Page 12]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ It is important to point out that the call need not have been
+ established by the controller in order for the processing of this
+ section to be used. Rather, the controller could have acted as a
+ B2BUA during a call established by A towards B (or vice versa).
+
+
+8. 3pcc and Early Media
+
+ Early media represents the condition where the session is established
+ (as a result of the completion of an offer/answer exchange), yet the
+ call itself has not been accepted. This is usually used to convey
+ tones or announcements regarding progress of the call. Handling of
+ early media in a third party call is straightforward.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et al. Best Current Practice [Page 13]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ A Controller B
+ | | |
+ |(1) INVITE offer1 | |
+ |no media | |
+ |<---------------------| |
+ | | |
+ |<ring> | |
+ | | |
+ |<answer> | |
+ | | |
+ |(2) 200 answer1 | |
+ |no media | |
+ |--------------------->| |
+ |(3) ACK | |
+ |<---------------------| |
+ | |(4) INVITE no SDP |
+ | |--------------------->|
+ | | |<ring>
+ | |(5) 183 offer2 |
+ | |<---------------------|
+ |(6) INVITE offer2' | |
+ |<---------------------| |
+ |(7) 200 answer2' | |
+ |--------------------->| |
+ |(8) ACK | |
+ |<---------------------| |
+ | |(9) PRACK answer2 |
+ | |--------------------->|
+ | |(10) 200 PRACK |
+ | |<---------------------|
+ |(11) RTP | |
+ |.............................................|
+ | | |<answer>
+ | |(12) 200 OK |
+ | |<---------------------|
+ | |(13) ACK |
+ | |--------------------->|
+
+ Figure 8
+
+ Figure 8 shows the case where user B generates early media before
+ answering the call. The flow is almost identical to Flow IV from
+ Figure 4. The only difference is that user B generates a reliable
+ provisional response (5) [6] instead of a final response, and answer2
+ is carried in a PRACK (9) instead of an ACK. When party B finally
+ does accept the call (12), there is no change in the session state,
+ and therefore, no signaling needs to be done with user A. The
+ controller simply ACKs the 200 OK (13) to confirm the dialog.
+
+
+
+Rosenberg, et al. Best Current Practice [Page 14]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ A Controller B
+ | | |
+ |(1) INVITE offer1 | |
+ |no media | |
+ |<---------------------| |
+ | | |
+ |ring | |
+ | | |
+ |(2) 183 answer1 | |
+ |no media | |
+ |--------------------->| |
+ |(3) PRACK | |
+ |<---------------------| |
+ |(4) 200 PRACK | |
+ |--------------------->| |
+ | |(5) INVITE no SDP |
+ | |--------------------->|
+ | | |ring
+ | | |
+ | | |answer
+ | | |
+ | |(6) 200 OK offer2 |
+ | |<---------------------|
+ |(7) UPDATE offer2' | |
+ |<---------------------| |
+ | | |
+ |(8) 200 answer2' | |
+ |--------------------->| |
+ | |(9) ACK answer2 |
+ | |--------------------->|
+ |(10) RTP | |
+ |.............................................|
+ | | |
+ |answer | |
+ | | |
+ |(11) 200 OK | |
+ |--------------------->| |
+ |(12) ACK | |
+ |<---------------------| |
+
+ Figure 9
+
+ The case where user A generates early media is more complicated, and
+ is shown in Figure 9. The flow is based on Flow IV. The controller
+ sends an INVITE to user A (1), with an offer containing no media
+ streams. User A generates a reliable provisional response (2)
+ containing an answer with no media streams. The controller PRACKs
+ this provisional response (3). Now, the controller sends an INVITE
+
+
+
+Rosenberg, et al. Best Current Practice [Page 15]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ without SDP to user B (5). User B's phone rings, and they answer,
+ resulting in a 200 OK (6) with an offer, offer2. The controller now
+ needs to update the session parameters with user A. However, since
+ the call has not been answered, it cannot use a re-INVITE. Rather,
+ it uses a SIP UPDATE request (7) [7], passing the offer (after
+ modifying it to get the origin field correct). User A generates its
+ answer in the 200 OK to the UPDATE (8). This answer is passed to
+ user B in the ACK (9). When user A finally answers (11), there is no
+ change in session state, so the controller simply ACKs the 200 OK
+ (12).
+
+ Note that it is likely that there will be clipping of media in this
+ call flow. User A is likely a PSTN gateway, and has generated a
+ provisional response because of early media from the PSTN side. The
+ PSTN will deliver this media even though the gateway does not have
+ anywhere to send it, since the initial offer from the controller had
+ no media streams. When user B answers, media can begin to flow.
+ However, any media sent to the gateway from the PSTN up to that point
+ will be lost.
+
+9. Third Party Call Control and SDP Preconditions
+
+ A SIP extension has been specified that allows for the coupling of
+ signaling and resource reservation [2]. This specification relies on
+ exchanges of session descriptions before completion of the call
+ setup. These flows are initiated when certain SDP parameters are
+ passed in the initial INVITE. As a result, the interaction of this
+ mechanism with third party call control is not obvious, and worth
+ detailing.
+
+9.1. Controller Initiates
+
+ In one usage scenario, the controller wishes to make use of
+ preconditions in order to avoid the call failure scenarios documented
+ in Section 4.4. Specifically, the controller can use preconditions in
+ order to guarantee that neither party is alerted unless there is a
+ common set of media and codecs. It can also provide both parties
+ with information on the media composition of the call before they
+ decide to accept it.
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et al. Best Current Practice [Page 16]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ User A Controller Customer Service
+ (User B)
+ | | |
+ |(1) INVITE no SDP | |
+ |require precon | |
+ |<------------------| |
+ |(2) 183 offer1 | |
+ |optional precon | |
+ |------------------>| |
+ | | |
+ | |(3) INVITE offer1 |
+ | |------------------>|
+ | | |
+ | | |
+ | | |<answer>
+ | |(4) 200 OK answer1 |
+ | |no precon |
+ | |<------------------|
+ | |(5) ACK |
+ | |------------------>|
+ |(6) PRACK answer1 | |
+ |<------------------| |
+ |<ring> | |
+ | | |
+ |(7) 200 PRACK | |
+ |------------------>| |
+ |<answer> | |
+ | | |
+ |(8) 200 INVITE | |
+ |------------------>| |
+ |(9) ACK | |
+ |<------------------| |
+
+
+ Figure 10
+
+ The flow for this scenario is shown in Figure 10. In this example,
+ we assume that user B is an automata or agent of some sort which will
+ answer the call immediately. Therefore, the flow is based on Flow I.
+ The controller sends an INVITE to user A containing no SDP, but with
+ a Require header indicating that preconditions are required. This
+ specific scenario (an INVITE without an offer, but with a Require
+ header indicating preconditions) is not described in [2]. It is
+ RECOMMENDED that the UAS respond with an offer in a 1xx including the
+ media streams it wishes to use for the call, and for each, list all
+ preconditions it supports as optional. Of course, the user is not
+ alerted at this time. The controller takes this offer and passes it
+ to user B (3). User B does not support preconditions, or does, but
+
+
+
+Rosenberg, et al. Best Current Practice [Page 17]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ is not interested in them. Therefore, when it answers the call, the
+ 200 OK contains an answer without any preconditions listed (4). This
+ answer is passed to user A in the PRACK (6). At this point, user A
+ knows that there are no preconditions actually in use for the call,
+ and therefore, it can alert the user. When the call is answered,
+ user A sends a 200 OK to the controller (8) and the call is complete.
+
+ In the event that the offer generated by user A was not acceptable to
+ user B (because of non-overlapping codecs or media, for example),
+ user B would immediately reject the INVITE (message 3). The
+ controller would then CANCEL the request to user A. In this
+ situation, neither user A nor user B would have been alerted,
+ achieving the desired effect. It is interesting to note that this
+ property is achieved using preconditions even though it doesn't
+ matter what specific types of preconditions are supported by user A.
+
+ It is also entirely possible that user B does actually desire
+ preconditions. In that case, it might generate a 1xx of its own with
+ an answer containing preconditions. That answer would still be
+ passed to user A, and both parties would proceed with whatever
+ measures are necessary to meet the preconditions. Neither user would
+ be alerted until the preconditions were met.
+
+9.2. Party A Initiates
+
+ In Section 9.1, the controller requested the use of preconditions to
+ achieve a specific goal. It is also possible that the controller
+ doesn't care (or perhaps doesn't even know) about preconditions, but
+ one of the participants in the call does care. A call flow for this
+ case is shown in Figure 11.
+
+ A Controller B
+ |(1) INVITE offer1 | |
+ |no media | |
+ |<---------------------| |
+ |(2) 183 answer1 | |
+ |no media | |
+ |--------------------->| |
+ |(3) PRACK | |
+ |<---------------------| |
+ |(4) 200 OK | |
+ |--------------------->| |
+ | |(5) INVITE no SDP |
+ | |--------------------->|
+ | |(6) 183 offer2 |
+ | |des=sendrecv |
+ | |conf=recv |
+ | |cur=none |
+
+
+
+Rosenberg, et al. Best Current Practice [Page 18]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ | |<---------------------|
+ |(7) UPDATE offer2' | |
+ |des=sendrecv | |
+ |conf=recv | |
+ |cur=none | |
+ |<---------------------| |
+ |(8) 200 UPDATE | |
+ |answer2' | |
+ |des=sendrecv | |
+ |conf=recv | |
+ |cur=none | |
+ |--------------------->| |
+ | |(9) PRACK answer2 |
+ | |des=sendrecv |
+ | |conf=recv |
+ | |cur=none |
+ | |--------------------->|
+ | |(10) 200 PRACK |
+ | |<---------------------|
+ |(11) reservation | |
+ |-------------------------------------------->|
+ |(12) reservation | |
+ |<--------------------------------------------|
+ |(13) UPDATE offer3 | |
+ |des=sendrecv | |
+ |conf=recv | |
+ |cur=recv | |
+ |--------------------->| |
+ | |(14) UPDATE offer3' |
+ | |des=sendrecv |
+ | |conf=recv |
+ | |cur=recv |
+ | |--------------------->|
+ | |(15) 200 UPDATE |
+ | |answer3' |
+ | |des=sendrecv |
+ | |conf=recv |
+ | |cur=send |
+ | |<---------------------|
+ |(16) 200 UPDATE | |
+ |answer3 | |
+ |des=sendrecv | |
+ |conf=recv | |
+ |cur=send | |
+ |<---------------------| |
+ | | |<ring>
+ | |(17) UPDATE offer4 |
+ | |des=sendrecv |
+
+
+
+Rosenberg, et al. Best Current Practice [Page 19]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ | |conf=recv |
+ | |cur=sendrecv |
+ | |<---------------------|
+ |(18) UPDATE offer4' | |
+ |des=sendrecv | |
+ |conf=recv | |
+ |cur=sendrecv | |
+ |<---------------------| |
+ |<ring> | |
+ |(19) 200 UPDATE | |
+ |answer4' | |
+ |des=sendrecv | |
+ |conf=recv | |
+ |cur=sendrecv | |
+ |--------------------->| |
+ | |(20) 200 UPDATE |
+ | |answer4 |
+ | |des=sendrecv |
+ | |conf=recv |
+ | |cur=sendrecv |
+ | |--------------------->|
+ |(21) 180 INVITE | |
+ |--------------------->| |
+ | |(22) 180 INVITE |
+ | |<---------------------|
+ |<answer> | |
+ |(23) 200 INVITE | |
+ |--------------------->| |
+ |(24) ACK | |
+ |<---------------------| |
+ | | |<answer>
+ | |(25) 200 INVITE |
+ | |<---------------------|
+ | |(26) ACK |
+ | |--------------------->|
+
+ Figure 11
+
+ The controller follows Flow IV; it has no specific requirements for
+ support of the preconditions specification [2]. Therefore, it sends
+ an INVITE (1) with SDP that contains no media lines. User A is
+ interested in supporting preconditions, and does not want to ring its
+ phone until resources are reserved. Since there are no media streams
+ in the INVITE, it can't reserve resources for media streams, and
+ therefore it can't ring the phone until they are conveyed in a
+ subsequent offer and then reserved. Therefore, it generates a 183
+ with the answer, and doesn't alert the user (2). The controller
+ PRACKs this (3) and A responds to the PRACK (4).
+
+
+
+Rosenberg, et al. Best Current Practice [Page 20]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ At this point, the controller attempts to bring B into the call. It
+ sends B an INVITE without SDP (5). B is interested in having
+ preconditions for this call. Therefore, it generates its offer in a
+ 183 that contains the appropriate SDP attributes (6). The controller
+ passes this offer to A in an UPDATE request (7). The controller uses
+ UPDATE because the call has not been answered yet, and therefore, it
+ cannot use a re-INVITE. User A sees that its peer is capable of
+ supporting preconditions. Since it desires preconditions for the
+ call, it generates an answer in the 200 OK (8) to the UPDATE. This
+ answer, in turn, is passed to B in the PRACK for the provisional
+ response (9). Now, both sides perform resource reservation. User A
+ succeeds first, and passes an updated session description in an
+ UPDATE request (13). The controller simply passes this to A (after
+ the manipulation of the origin field, as required in Flow IV) in an
+ UPDATE (14), and the answer (15) is passed back to A (16). The same
+ flow happens, but from B to A, when B's reservation succeeds (17-20).
+ Since the preconditions have been met, both sides ring (21 and 22),
+ and then both answer (23 and 25), completing the call.
+
+ What is important about this flow is that the controller doesn't know
+ anything about preconditions. It merely passes the SDP back and
+ forth as needed. The trick is the usage of UPDATE and PRACK to pass
+ the SDP when needed. That determination is made entirely based on
+ the offer/answer rules described in [6] and [7], and is independent
+ of preconditions.
+
+10. Example Call Flows
+
+10.1. Click-to-Dial
+
+ The first application of this capability we discuss is click-to-dial.
+ In this service, a user is browsing the web page of an e-commerce
+ site, and would like to speak to a customer service representative.
+ The user clicks on a link, and a call is placed to a customer service
+ representative. When the representative picks up, the phone on the
+ user's desk rings. When the user pick up, the customer service
+ representative is there, ready to talk to the user.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et al. Best Current Practice [Page 21]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+Customer Service Controller User's Phone User's Browser
+ | |(1) HTTP POST | |
+ | |<--------------------------------------|
+ | |(2) HTTP 200 OK | |
+ | |-------------------------------------->|
+ |(3) INVITE offer1 | | |
+ |no media | | |
+ |<------------------| | |
+ |(4) 200 answer1 | | |
+ |no media | | |
+ |------------------>| | |
+ |(5) ACK | | |
+ |<------------------| | |
+ | |(6) INVITE no SDP | |
+ | |------------------>| |
+ | |(7) 200 OK offer2 | |
+ | |<------------------| |
+ |(8) INVITE offer2' | | |
+ |<------------------| | |
+ |(9) 200 answer2' | | |
+ |------------------>| | |
+ | |(10) ACK answer2 | |
+ | |------------------>| |
+ |(11) ACK | | |
+ |<------------------| | |
+ |(12) RTP | | |
+ |.......................................| |
+
+ Figure 12
+
+ The call flow for this service is given in Figure 12. It is
+ identical to that of Figure 4, with the exception that the service is
+ triggered through an HTTP POST request when the user clicks on the
+ link. Normally, this POST request would contain neither the number
+ of the user or of the customer service representative. The user's
+ number would typically be obtained by the web application from back-
+ end databases, since the user would have presumably logged into the
+ site, giving the server the needed context. The customer service
+ number would typically be obtained through provisioning. Thus, the
+ HTTP POST is actually providing the server nothing more than an
+ indication that a call is desired.
+
+ We note that this service can be provided through other mechanisms,
+ namely PINT [9]. However, there are numerous differences between the
+ way in which the service is provided by PINT, and the way in which it
+ is provided here:
+
+
+
+
+
+Rosenberg, et al. Best Current Practice [Page 22]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ o The PINT solution enables calls only between two PSTN endpoints.
+ The solution described here allows calls between PSTN phones
+ (through SIP enabled gateways) and native IP phones.
+
+ o When used for calls between two PSTN phones, the solution here may
+ result in a portion of the call being routed over the Internet.
+ In PINT, the call is always routed only over the PSTN. This may
+ result in better quality calls with the PINT solution, depending
+ on the codec in use and QoS capabilities of the network routing
+ the Internet portion of the call.
+
+ o The PINT solution requires extensions to SIP (PINT is an extension
+ to SIP), whereas the solution described here is done with baseline
+ SIP.
+
+ o The PINT solution allows the controller (acting as a PINT client)
+ to "step out" once the call is established. The solution
+ described here requires the controller to maintain call state for
+ the entire duration of the call.
+
+10.2. Mid-Call Announcement Capability
+
+ The third party call control mechanism described here can also be
+ used to enable mid-call announcements. Consider a service for pre-
+ paid calling cards. Once the pre-paid call is established, the
+ system needs to set a timer to fire when they run out of minutes.
+ When this timer fires, we would like the user to hear an announcement
+ which tells them to enter a credit card to continue. Once they enter
+ the credit card info, more money is added to the pre-paid card, and
+ the user is reconnected to the destination party.
+
+ We consider here the usage of third party call control just for
+ playing the mid-call dialog to collect the credit card information.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et al. Best Current Practice [Page 23]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ Pre-Paid User Controller Called Party Media Server
+ | |(1) INV SDP c=bh | |
+ | |------------------>| |
+ | |(2) 200 answer1 | |
+ | |<------------------| |
+ | |(3) ACK | |
+ | |------------------>| |
+ |(4) INV no SDP | | |
+ |<------------------| | |
+ |(5) 200 offer2 | | |
+ |------------------>| | |
+ | |(6) INV offer2 | |
+ | |-------------------------------------->|
+ | |(7) 200 answer2 | |
+ | |<--------------------------------------|
+ |(8) ACK answer2 | | |
+ |<------------------| | |
+ | |(9) ACK | |
+ | |-------------------------------------->|
+ |(10) RTP | | |
+ |...........................................................|
+ | |(11) BYE | |
+ | |-------------------------------------->|
+ | |(12) 200 OK | |
+ | |<--------------------------------------|
+ | |(13) INV no SDP | |
+ | |------------------>| |
+ | |(14) 200 offer3 | |
+ | |<------------------| |
+ |(15) INV offer3' | | |
+ |<------------------| | |
+ |(16) 200 answer3' | | |
+ |------------------>| | |
+ | |(17) ACK answer3' | |
+ | |------------------>| |
+ |(18) ACK | | |
+ |<------------------| | |
+ |(19) RTP | | |
+ |.......................................| |
+
+ Figure 13
+
+ We assume the call is set up so that the controller is in the call as
+ a B2BUA. When the timer fires, we wish to connect the caller to a
+ media server. The flow for this is shown in Figure 13. When the
+ timer expires, the controller places the called party with a
+ connection address of 0.0.0.0 (1). This effectively "disconnects"
+ the called party. The controller then sends an INVITE without SDP to
+
+
+
+Rosenberg, et al. Best Current Practice [Page 24]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ the pre-paid caller (4). The offer returned from the caller (5) is
+ used in an INVITE to the media server which will be collecting digits
+ (6). This is an instantiation of Flow I. This flow can only be used
+ here because the media server is an automata, and will answer the
+ INVITE immediately. If the controller was connecting the pre-paid
+ user with another end user, Flow III would need to be used. The
+ media server returns an immediate 200 OK (7) with an answer, which is
+ passed to the caller in an ACK (8). The result is that the media
+ server and the pre-paid caller have their media streams connected.
+
+ The media server plays an announcement, and prompts the user to enter
+ a credit card number. After collecting the number, the card number
+ is validated. The media server then passes the card number to the
+ controller (using some means outside the scope of this
+ specification), and then hangs up the call (11).
+
+ After hanging up with the media server, the controller reconnects the
+ user to the original called party. To do this, the controller sends
+ an INVITE without SDP to the called party (13). The 200 OK (14)
+ contains an offer, offer3. The controller modifies the SDP (as is
+ done in Flow III), and passes the offer in an INVITE to the pre-paid
+ user (15). The pre-paid user generates an answer in a 200 OK (16)
+ which the controller passes to user B in the ACK (17). At this
+ point, the caller and called party are reconnected.
+
+11. Implementation Recommendations
+
+ Most of the work involved in supporting third party call control is
+ within the controller. A standard SIP UA should be controllable
+ using the mechanisms described here. However, third party call
+ control relies on a few features that might not be implemented. As
+ such, we RECOMMEND that implementors of user agent servers support
+ the following:
+
+ o Offers and answers that contain a connection line with an address
+ of 0.0.0.0.
+
+ o Re-INVITE requests that change the port to which media should be
+ sent
+
+ o Re-INVITEs that change the connection address
+
+ o Re-INVITEs that add a media stream
+
+ o Re-INVITEs that remove a media stream (setting its port to zero)
+
+ o Re-INVITEs that add a codec amongst the set in a media stream
+
+
+
+
+Rosenberg, et al. Best Current Practice [Page 25]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ o SDP Connection address of zero
+
+ o Initial INVITE requests with a connection address of zero
+
+ o Initial INVITE requests with no SDP
+
+ o Initial INVITE requests with SDP but no media lines
+
+ o Re-INVITEs with no SDP
+
+ o The UPDATE method [7]
+
+ o Reliability of provisional responses [6]
+
+ o Integration of resource management and SIP [2].
+
+12. Security Considerations
+
+12.1. Authorization and Authentication
+
+ In most uses of SIP INVITE, whether or not a call is accepted is
+ based on a decision made by a human when presented information about
+ the call, such as the identity of the caller. In other cases,
+ automata answer the calls, and whether or not they do so may depend
+ on the particular application to which SIP is applied. For example,
+ if a caller makes a SIP call to a voice portal service, the call may
+ be rejected unless the caller has previously signed up (perhaps via a
+ web site). In other cases, call handling policies are made based on
+ automated scripts, such as those described by the Call Processing
+ Language [11]. Frequently, those decisions are also made based on
+ the identity of the caller.
+
+ These authorization mechanisms would be applied to normal first party
+ calls and third party calls, as these two are indistinguishable. As
+ a result, it is important for these authorization policies to
+ continue to operate correctly for third party calls. Of course,
+ third party calls introduce a new party - the one initiating the
+ third party call. Do the authorization policies apply based on the
+ identity of that third party, or do they apply based on the
+ participants in the call? Ideally, the participants would be able to
+ know the identities of both other parties, and have authorization
+ policies be based on those, as appropriate. However, this is not
+ possible using existing mechanisms. As a result, the next best thing
+ is for the INVITE requests to contain the identity of the third
+ party. Ultimately, this is the user who is requesting communication,
+ and it makes sense for call authorization policies to be based on
+ that identity.
+
+
+
+
+Rosenberg, et al. Best Current Practice [Page 26]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ This requires, in turn, that the controller authenticate itself as
+ that third party. This can be challenging, and the appropriate
+ mechanism depends on the specific application scenario.
+
+ In one common scenario, the controller is acting on behalf of one of
+ the participants in the call. A typical example is click-to-dial,
+ where the controller and the customer service representative are run
+ by the same administrative domain. Indeed, for the purposes of
+ identification, the controller can legitimately claim to be the
+ customer service representative. In this scenario, it would be
+ appropriate for the INVITE to the end user to contain a From field
+ identifying the customer service rep, and authenticate the request
+ using S/MIME (see RFC 3261 [1], Section 23) signed by the key of the
+ customer service rep (which is held by the controller).
+
+ This requires the controller to actually have credentials with which
+ it can authenticate itself as the customer support representative.
+ In many other cases, the controller is representing one of the
+ participants, but does not possess their credentials. Unfortunately,
+ there are currently no standardized mechanisms that allow a user to
+ delegate credentials to the controller in a way that limits their
+ usage to specific third party call control operations. In the
+ absence of such a mechanisms, the best that can be done is to use the
+ display name in the From field to indicate the identity of the user
+ on whose behalf the call is being made. It is RECOMMENDED that the
+ display name be set to "[controller] on behalf of [user]", where user
+ and controller are textual identities of the user and controller,
+ respectively. In this case, the URI in the From field would identify
+ the controller.
+
+ In other situations, there is no real relationship between the
+ controller and the participants in the call. In these situations,
+ ideally the controller would have a means to assert that the call is
+ from a particular identity (which could be one of the participants,
+ or even a third party, depending on the application), and to validate
+ that assertion with a signature using the key of the controller.
+
+12.2. End-to-End Encryption and Integrity
+
+ With third party call control, the controller is actually one of the
+ participants as far as the SIP dialog is concerned. Therefore,
+ encryption and integrity of the SIP messages, as provided by S/MIME,
+ will occur between participants and the controller, rather than
+ directly between participants.
+
+ However, integrity, authenticity and confidentiality of the media
+ sessions can be provided through a controller. End-to-end media
+ security is based on the exchange of keying material within SDP [10].
+
+
+
+Rosenberg, et al. Best Current Practice [Page 27]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+ The proper operation of these mechanisms with third party call
+ control depends on the controller behaving properly. So long as it
+ is not attempting to explicitly disable these mechanisms, the
+ protocols will properly operate between the participants, resulting
+ in a secure media session that even the controller cannot eavesdrop
+ or modify. Since third party call control is based on a model of
+ trust between the users and the controller, it is reasonable to
+ assume it is operating in a well-behaved manner. However, there is
+ no cryptographic means that can prevent the controller from
+ interfering with the initial exchanges of keying materials. As a
+ result, it is trivially possibly for the controller to insert itself
+ as an intermediary on the media exchange, if it should so desire.
+
+13. Acknowledgements
+
+ The authors would like to thank Paul Kyzivat, Rohan Mahy, Eric
+ Rescorla, Allison Mankin and Sriram Parameswar for their comments.
+
+14. References
+
+14.1. Normative References
+
+ [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+ Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
+ Session Initiation Protocol", RFC 3261, June 2002.
+
+ [2] Camarillo, G., Ed., Marshall, W., Ed. and J. Rosenberg,
+ "Integration of Resource Management and Session Initiation
+ Protocol (SIP)", RFC 3312, October 2002.
+
+ [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
+ Session Description Protocol (SDP)", RFC 3264, June 2002.
+
+ [5] Schulzrinne, H., Oran, D. and G. Camarillo, "The Reason Header
+ Field for the Session Initiation Protocol (SIP)", RFC 3326,
+ December 2002.
+
+ [6] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
+ Responses in Session Initiation Protocol (SIP)", RFC 3262, June
+ 2002.
+
+ [7] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
+ Method", RFC 3311, October 2002.
+
+
+
+
+
+Rosenberg, et al. Best Current Practice [Page 28]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+14.2. Informative References
+
+ [8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
+ "RTP: A Transport Protocol for Real-Time Applications", RFC
+ 3550, July 2003.
+
+ [9] Petrack, S. and L. Conroy, "The PINT Service Protocol:
+ Extensions to SIP and SDP for IP Access to Telephone Call
+ Services", RFC 2848, June 2000.
+
+ [10] Andreasen, F., Baugher, M. and D. Wing, "SDP Security
+ Descriptions for Media Streams", Work in Progress, October 2003.
+
+ [11] Lennox, J., Wu, X. and H. Schulzrinne, "CPL: A Language for User
+ Control of Internet Telephony Services", Work in Progress,
+ August 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et al. Best Current Practice [Page 29]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+15. Authors' Addresses
+
+ Jonathan Rosenberg
+ dynamicsoft
+ 600 Lanidex Plaza
+ Parsippany, NJ 07054
+ US
+
+ Phone: +1 973 952-5000
+ EMail: jdrosen@dynamicsoft.com
+ URI: http://www.jdrosen.net
+
+
+ Jon Peterson
+ Neustar
+ 1800 Sutter Street
+ Suite 570
+ Concord, CA 94520
+ US
+
+ Phone: +1 925 363-8720
+ EMail: jon.peterson@neustar.biz
+ URI: http://www.neustar.biz
+
+
+ Henning Schulzrinne
+ Columbia University
+ M/S 0401
+ 1214 Amsterdam Ave.
+ New York, NY 10027
+ US
+
+ EMail: schulzrinne@cs.columbia.edu
+ URI: http://www.cs.columbia.edu/~hgs
+
+
+ Gonzalo Camarillo
+ Ericsson
+ Hirsalantie 11
+ Jorvas 02420
+ Finland
+
+ EMail: Gonzalo.Camarillo@ericsson.com
+
+
+
+
+
+
+
+
+Rosenberg, et al. Best Current Practice [Page 30]
+
+RFC 3725 SIP 3pcc April 2004
+
+
+16. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78 and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+ REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+ INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed
+ to pertain to the implementation or use of the technology
+ described in this document or the extent to which any license
+ under such rights might or might not be available; nor does it
+ represent that it has made any independent effort to identify any
+ such rights. Information on the procedures with respect to
+ rights in RFC documents can be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use
+ of such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository
+ at http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention
+ any copyrights, patents or patent applications, or other
+ proprietary rights that may cover technology that may be required
+ to implement this standard. Please address the information to the
+ IETF at ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Rosenberg, et al. Best Current Practice [Page 31]
+