draft-ietf-sipping-3pcc-04.txt   draft-ietf-sipping-3pcc-05.txt 
SIPPING J. Rosenberg SIPPING J. Rosenberg
Internet-Draft dynamicsoft Internet-Draft dynamicsoft
Expires: December 29, 2003 J. Peterson Expires: April 26, 2004 J. Peterson
Neustar Neustar
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
G. Camarillo G. Camarillo
Ericsson Advanced Signalling Ericsson Advanced Signalling
Research Lab Research Lab
June 30, 2003 October 27, 2003
Best Current Practices for Third Party Call Control in the Session Best Current Practices for Third Party Call Control in the Session
Initiation Protocol Initiation Protocol
draft-ietf-sipping-3pcc-04 draft-ietf-sipping-3pcc-05
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 29, 2003. This Internet-Draft will expire on April 26, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
Third party call control refers to the ability of one entity to Third party call control refers to the ability of one entity to
create a call in which communications is actually between other create a call in which communications is actually between other
parties. Third party call control is possible using the mechanisms parties. Third party call control is possible using the mechanisms
specified within the Session Initiation Protocol (SIP). However, specified within the Session Initiation Protocol (SIP). However,
there are several possible approaches, each with different benefits there are several possible approaches, each with different benefits
and drawbacks. This document discusses best current practices for the and drawbacks. This document discusses best current practices for the
usage of SIP for third party call control. usage of SIP for third party call control.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4
4. 3pcc Call Establishment . . . . . . . . . . . . . . . . . . 6 4. 3pcc Call Establishment . . . . . . . . . . . . . . . . . . 4
4.1 Flow I . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1 Flow I . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2 Flow II . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2 Flow II . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3 Flow III . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3 Flow III . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4 Flow IV . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4 Flow IV . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Recommendations . . . . . . . . . . . . . . . . . . . . . . 13 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . 10
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 14 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 10
7. Continued Processing . . . . . . . . . . . . . . . . . . . . 16 7. Continued Processing . . . . . . . . . . . . . . . . . . . . 11
8. 3pcc and Early Media . . . . . . . . . . . . . . . . . . . . 18 8. 3pcc and Early Media . . . . . . . . . . . . . . . . . . . . 13
9. Third Party Call Control and SDP Preconditions . . . . . . . 21 9. Third Party Call Control and SDP Preconditions . . . . . . . 16
9.1 Controller Initiates . . . . . . . . . . . . . . . . . . . . 21 9.1 Controller Initiates . . . . . . . . . . . . . . . . . . . . 16
9.2 Party A Initiates . . . . . . . . . . . . . . . . . . . . . 23 9.2 Party A Initiates . . . . . . . . . . . . . . . . . . . . . 18
10. Example Call Flows . . . . . . . . . . . . . . . . . . . . . 27 10. Example Call Flows . . . . . . . . . . . . . . . . . . . . . 21
10.1 Click to Dial . . . . . . . . . . . . . . . . . . . . . . . 27 10.1 Click to Dial . . . . . . . . . . . . . . . . . . . . . . . 21
10.2 Mid-Call Announcement Capability . . . . . . . . . . . . . . 28 10.2 Mid-Call Announcement Capability . . . . . . . . . . . . . . 23
11. Implementation Recommendations . . . . . . . . . . . . . . . 31 11. Implementation Recommendations . . . . . . . . . . . . . . . 25
12. Security Considerations . . . . . . . . . . . . . . . . . . 32 12. Security Considerations . . . . . . . . . . . . . . . . . . 25
12.1 Identity . . . . . . . . . . . . . . . . . . . . . . . . . . 32 12.1 Authorization and Authentication . . . . . . . . . . . . . . 25
12.2 End-to-End Encryption and Integrity . . . . . . . . . . . . 32 12.2 End-to-End Encryption and Integrity . . . . . . . . . . . . 27
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
Normative References . . . . . . . . . . . . . . . . . . . . 36 Normative References . . . . . . . . . . . . . . . . . . . . 27
Informative References . . . . . . . . . . . . . . . . . . . 37 Informative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . 39 Intellectual Property and Copyright Statements . . . . . . . 30
1. Introduction 1. Introduction
In the traditional telephony context, third party call control allows In the traditional telephony context, third party call control allows
one entity (which we call the controller) to set up and manage a one entity (which we call the controller) to set up and manage a
communications relationship between two or more other parties. Third communications relationship between two or more other parties. Third
party call control (referred to as 3pcc) is often used for operator party call control (referred to as 3pcc) is often used for operator
services (where an operator creates a call that connects two services (where an operator creates a call that connects two
participants together), and conferencing. participants together), and conferencing.
skipping to change at page 3, line 30 skipping to change at page 3, line 30
phones, a phone and an IP host, or two IP hosts. phones, a phone and an IP host, or two IP hosts.
Third party call control is possible using only the mechanisms Third party call control is possible using only the mechanisms
specified within RFC 3261 [1]. Indeed, many different call flows are specified within RFC 3261 [1]. Indeed, many different call flows are
possible, each of which will work with SIP compliant user agents. possible, each of which will work with SIP compliant user agents.
However, there are benefits and drawbacks to each of these flows. The However, there are benefits and drawbacks to each of these flows. The
usage of third party call control also becomes more complex when usage of third party call control also becomes more complex when
aspects of the call utilize SIP extensions or optional features of aspects of the call utilize SIP extensions or optional features of
SIP. In particular, the usage of RFC 3312 [2] (used for coupling of SIP. In particular, the usage of RFC 3312 [2] (used for coupling of
signaling to resource reservation) with third party call control is signaling to resource reservation) with third party call control is
non-trivial. Similarly, the usage of early media (where session data non-trivial, and is discussed in Section 9. Similarly, the usage of
is exchanged before the call is accepted) with third party call early media (where session data is exchanged before the call is
control is not trivial. accepted) with third party call control is not trivial, and is
discussed in Section 8.
This document serves as a best current practice for implementing This document serves as a best current practice for implementing
third party call control without usage of any extensions specifically third party call control without usage of any extensions specifically
designed for that purpose. Section 4 presents the known call flows designed for that purpose. Section 4 presents the known call flows
that can be used to achieve third party call control, and provides that can be used to achieve third party call control, and provides
guidelines on their usage. Section 9 discusses the interactions of guidelines on their usage. Section 9 discusses the interactions of
RFC 3312 [2] with third party call control. Section 8 discusses the RFC 3312 [2] with third party call control. Section 8 discusses the
interactions of early media with third party call control. Section 10 interactions of early media with third party call control. Section 10
provides example applications that make usage of the flows provides example applications that make usage of the flows
recommended here. recommended here.
skipping to change at page 7, line 39 skipping to change at page 5, line 50
|(9) ACK | | |(9) ACK | |
|<------------------| | |<------------------| |
|(10) RTP | | |(10) RTP | |
|.......................................| |.......................................|
Figure 2 Figure 2
An alternative flow, Flow II, is shown in Figure 2. The controller 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, 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, containing an offer (sdp1) with a single audio media line, one codec,
a random port number (but not zero), and a connection address that is a random port number (but not zero), and a connection address of
somewhere within the .invalid DNS top level domain (TLD) [8] (for 0.0.0.0. This creates an initial media stream that is ``black
example, rtp.invalid). The use of a connection address in the invalid holed'', since no media (or RTCP packets [9] will flow from A. The
domain creates an initial media stream that is ``black holed'', since INVITE causes A's phone to ring.
no media (or RTCP packets [9] will flow from A. The INVITE causes A's
phone to ring.
When A answers (2), the 200 OK contains an answer, sdp2, with a valid
address in the connection line.
A user agent should respond to an offer containing a .invalid Note that the usage of 0.0.0.0, though recommended by RFC 3264,
domain just as it would any other offer. The answer contains its has numerous drawbacks. It is anticipated that a future
own address in the connection line. However, due to the presence specification will recommend usage of a domain within the .invalid
of a purposefully invalid domain name, media would not be sent to DNS top level domain instead of the 0.0.0.0 IP address. As a
the offerer. result, implementors are encouraged to track such developments
once they arise.
The controller sends an ACK (4). It then generates a second INVITE When A answers (2), the 200 OK contains an answer, sdp2, with a valid
(3). This INVITE is addressed to user B, and it contains sdp2 as the address in the connection line. The controller sends an ACK (4). It
offer to B. Note that the role of sdp2 has changed. In the 200 OK then generates a second INVITE (3). This INVITE is addressed to user
(message 2), it was an answer, but in the INVITE, it is an offer. B, and it contains sdp2 as the offer to B. Note that the role of sdp2
Fortunatly, all valid answers are valid initial offers. This INVITE has changed. In the 200 OK (message 2), it was an answer, but in the
causes B's phone to ring. When it answers, it generates a 200 OK (5) INVITE, it is an offer. Fortunatly, all valid answers are valid
with an answer, sdp3. The controller then generates an ACK (6). Next, initial offers. This INVITE causes B's phone to ring. When it
it sends a re-INVITE to A (7) containing sdp3 as the offer. Once answers, it generates a 200 OK (5) with an answer, sdp3. The
again, there has been a reversal of roles. sdp3 was an answer, and controller then generates an ACK (6). Next, it sends a re-INVITE to A
now it is an offer. Fortunately, an answer to an answer recast as an (7) containing sdp3 as the offer. Once again, there has been a
offer is, in turn, a valid offer. This re-INVITE generates a 200 OK reversal of roles. sdp3 was an answer, and now it is an offer.
(8) with sdp2, assuming that A doesn't decide to change any aspects Fortunately, an answer to an answer recast as an offer is, in turn, a
of the session as a result of this re-INVITE. This 200 OK is ACKed valid offer. This re-INVITE generates a 200 OK (8) with sdp2,
(9), and then media can flow from A to B. Media from B to A could assuming that A doesn't decide to change any aspects of the session
already start flowing once message 5 was sent. 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 advtange that all final responses are immediately This flow has the advantage that all final responses are immediately
ACKed. It therefore does not suffer from the timeout and message ACKed. It therefore does not suffer from the timeout and message
inefficiency problems of flow 1. However, it too has troubles. First inefficiency problems of flow 1. However, it too has troubles. First
off, it requires that the controller know the media types to be used off, it requires that the controller know the media types to be used
for the call (since it must generate a ``blackhole'' SDP, which for the call (since it must generate a "blackhole" SDP, which
requires media lines). Secondly, the first INVITE to A (1) contains requires media lines). Secondly, the first INVITE to A (1) contains
media with a rtp.invalid connection address to indicate that neither media with a 0.0.0.0 connection address. The controller expects that
media nor RTCP packets should be sent. This mechanism for indicating the response contains a valid, non-zero connection address for A.
that neither media or RTCP should be sent is different the one However, experience has shown that many UAs respond to an offer of a
documented in RFC 3264 [4], which uses 0.0.0.0 for this purpose. 0.0.0.0 connection address with an answer containing a 0.0.0.0
However, according to RFC 3330 [11], 0.0.0.0 is a special case connection address. The offer-answer specification [4] explicitly
address which refers to hosts on this network. This is not the same tells implementors not to do this, but at the time of publication of
as the desired semantic, which is much closer to the meaning of the this document, many implementations still did. If A should respond
.invalid TLD. However, it is unknown how off-the-shelf user agents with a 0.0.0.0 connection address in sdp2, the flow will not work.
will react to an SDP that contains a .invalid TLD in a connection
line.
However, the most serious flaw in this flow is the assumption that 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 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 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 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 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 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 infinite loop of re-INVITEs. It is possible to break this cycle by
having very smart UAs which can return the same SDP whenever having very smart UAs which can return the same SDP whenever
possible, or really smart controllers that can analyze the SDP to possible, or really smart controllers that can analyze the SDP to
skipping to change at page 9, line 40 skipping to change at page 7, line 47
Figure 3 Figure 3
A third flow, Flow III, is shown in 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 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 (which is good, since it means that the controller doesn't need to
assume anything about the media composition of the session). A's assume anything about the media composition of the session). A's
phone rings. When A answers, a 200 OK is generated (2) containing its phone rings. When A answers, a 200 OK is generated (2) containing its
offer, offer1. The controller generates an immediate ACK containing offer, offer1. The controller generates an immediate ACK containing
an answer (3). This answer is a ``black hole'' SDP, with its an answer (3). This answer is a "black hole" SDP, with its connection
connection address set to any domain in the .invalid TLD, such as address equal to 0.0.0.0.
media.invalid.
The controller then sends an INVITE to B without SDP (4). This causes 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 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 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 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 reorganized to match up media lines, or to trim media lines. For
example, if offer1 contained an audio and a video line, in that example, if offer1 contained an audio and a video line, in that
order, but offer2 contained just an audio line, the controller would 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 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 create offer2'. Since this is a re-INVITE, it should complete quickly
skipping to change at page 10, line 21 skipping to change at page 8, line 27
This flow has many benefits. First, it will usually operate without This flow has many benefits. First, it will usually operate without
any spurious retransmissions or timeouts (although this may still any spurious retransmissions or timeouts (although this may still
happen if a re-INVITE is not responded to quickly). Secondly, it does 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 not require the controller to guess the media that will be used by
the participants. the participants.
There are some drawbacks. The controller does need to perform SDP There are some drawbacks. The controller does need to perform SDP
manipulations. Specifically, it must take some SDP, and generate manipulations. Specifically, it must take some SDP, and generate
another SDP which has the same media composition, but has connection another SDP which has the same media composition, but has connection
addresses within the .invalid TLD. This is needed for message 3. addresses equal to 0.0.0.0. This is needed for message 3. Secondly,
Secondly, it may need to reorder and trim on SDP X, so that its media it may need to reorder and trim on SDP X, so that its media lines
lines match up with those in some other SDP, Y. Thirdly, the offer match up with those in some other SDP, Y. Thirdly, the offer from B
from B (offer2) may have no codecs or media streams in common with (offer2) may have no codecs or media streams in common with the offer
the offer from A (offer 1). The controller will need to detect this from A (offer 1). The controller will need to detect this condition,
condition, and terminate the call. Fourth, it requires usage of the and terminate the call. Finally, the flow is far more complicated
.invalid TLD within SDP, which may not be supported. Finally, the than the simple and elegant Flow I (Figure 1).
flow is far more complicated than the simple and elegant Flow I
(Figure 1).
4.4 Flow IV 4.4 Flow IV
A Controller B A Controller B
|(1) INVITE offer1 | | |(1) INVITE offer1 | |
|no media | | |no media | |
|<---------------------| | |<---------------------| |
|(2) 200 answer1 | | |(2) 200 answer1 | |
|no media | | |no media | |
|--------------------->| | |--------------------->| |
skipping to change at page 13, line 22 skipping to change at page 10, line 28
expect a great deal of third party call control to be to automata, expect a great deal of third party call control to be to automata,
special caseing this scenario is reasonable. special caseing this scenario is reasonable.
For calls to unknown entities, or to entities known to represent For calls to unknown entities, or to entities known to represent
people, it is RECOMMENDED that Flow IV (Figure 4) be used for third 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 party call control. Flow III MAY be used instead, but it provides no
additional benefits over Flow IV. However, Flow II SHOULD NOT be additional benefits over Flow IV. However, Flow II SHOULD NOT be
used, because of the potential for infinite ping-ponging of used, because of the potential for infinite ping-ponging of
re-INVITEs. re-INVITEs.
Several of these flows use a ``black hole'' connection address, which Several of these flows use a ``black hole'' connection address of
is any domain in the .invalid domain. A UA MUST be prepared to 0.0.0.0. This is an IPV4 address with the property that packets sent
receive offers or answers with connection lines containing addresses to it will never leave the host which sent them; they are just
within this domain. A UA receiving such a domain proceeds with normal discarded. Those flows are therefore specific to IPv4. For other
RFC 3264 offer/answer processing. However, it will not send media to network or address types, an address with an equivalent property
the address. A UA MAY bypass DNS lookup of the connection line when SHOULD be used.
it sees it's within the .invalid domain. Of course, a host that
performs a lookup with receive a response indicating that the host
name is invalid.
6. Error Handling 6. Error Handling
There are numerous error cases which merit discussion. There are numerous error cases which merit discussion.
With all of the call flows in Section 4, one call is established to 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. A, and then the controller attempts to establish a call to B.
However, this call attempt may fail, for any number of reasons. User 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 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. may not be any media in common, the request may time out, and so on.
skipping to change at page 28, line 43 skipping to change at page 23, line 30
system needs to set a timer to fire when they run out of minutes. 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 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 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 credit card info, more money is added to the pre-paid card, and
the user is reconnected to the destination party. the user is reconnected to the destination party.
We consider here the usage of third party call control just for We consider here the usage of third party call control just for
playing the mid-call dialog to collect the credit card information. playing the mid-call dialog to collect the credit card information.
Pre-Paid User Controller Called Party Media Server Pre-Paid User Controller Called Party Media Server
| |(1) INV SDP c=invld| | | |(1) INV SDP c=bh | |
| |------------------>| | | |------------------>| |
| |(2) 200 answer1 | | | |(2) 200 answer1 | |
| |<------------------| | | |<------------------| |
| |(3) ACK | | | |(3) ACK | |
| |------------------>| | | |------------------>| |
|(4) INV no SDP | | | |(4) INV no SDP | | |
|<------------------| | | |<------------------| | |
|(5) 200 offer2 | | | |(5) 200 offer2 | | |
|------------------>| | | |------------------>| | |
| |(6) INV offer2 | | | |(6) INV offer2 | |
skipping to change at page 29, line 42 skipping to change at page 24, line 29
|<------------------| | | |<------------------| | |
|(19) RTP | | | |(19) RTP | | |
|.......................................| | |.......................................| |
Figure 13 Figure 13
We assume the call is set up so that the controller is in the call as 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 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 media server. The flow for this is shown in Figure 13. When the timer
expires, the controller places the called party with a connection expires, the controller places the called party with a connection
address of rtp.invalid (1). This effectively ``disconnects'' the address of 0.0.0.0 (1). This effectively ``disconnects'' the called
called party. The controller then sends an INVITE without SDP to the party. The controller then sends an INVITE without SDP to the the
the pre-paid caller (4). The offer returned from the caller (5) is pre-paid caller (4). The offer returned from the caller (5) is used
used in an INVITE to the media server which will be collecting digits in an INVITE to the media server which will be collecting digits (6).
(6). This is an instantiation of Flow I. This flow can only be used This is an instantiation of Flow I. This flow can only be used here
here because the media server is an automata, and will answer the because the media server is an automata, and will answer the INVITE
INVITE immediately. If the controller was connecting the pre-paid immediately. If the controller was connecting the pre-paid user with
user with another end user, Flow III would need to be used. The media another end user, Flow III would need to be used. The media server
server returns an immediate 200 OK (7) with an answer, which is returns an immediate 200 OK (7) with an answer, which is passed to
passed to the caller in an ACK (8). The result is that the media the caller in an ACK (8). The result is that the media server and the
server and the pre-paid caller have their media streams connected. pre-paid caller have their media streams connected.
The media server plays an announcement, and prompts the user to enter The media server plays an announcement, and prompts the user to enter
a credit card number. After collecting the number, the card number is a credit card number. After collecting the number, the card number is
validated. The media server then passes the card number to the validated. The media server then passes the card number to the
controller (using some means outside the scope of this controller (using some means outside the scope of this
specification), and then hangs up the call (11). specification), and then hangs up the call (11).
After hanging up with the media server, the controller reconnects the After hanging up with the media server, the controller reconnects the
user to the original called party. To do this, the controller sends 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) an INVITE without SDP to the called party (13). The 200 OK (14)
skipping to change at page 31, line 15 skipping to change at page 25, line 18
11. Implementation Recommendations 11. Implementation Recommendations
Most of the work involved in supporting third party call control is Most of the work involved in supporting third party call control is
within the controller. A standard SIP UA should be controllable using within the controller. A standard SIP UA should be controllable using
the mechanisms described here. However, third party call control the mechanisms described here. However, third party call control
relies on a few features that might not be implemented. As such, we relies on a few features that might not be implemented. As such, we
RECOMMEND that implementors of user agent servers to support the RECOMMEND that implementors of user agent servers to support the
following: following:
o Offers and answers that contain a connection line with an address o Offers and answers that contain a connection line with an address
within the .invalid TLD. of 0.0.0.0.
o Re-invites that change the port to which media should be sent o Re-invites that change the port to which media should be sent
o Re-invites that change the connection address o Re-invites that change the connection address
o Re-invites that add a media stream 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 remove a media stream (setting its port to zero)
o Re-invites that add a codec amongst the set in a media stream o Re-invites that add a codec amongst the set in a media stream
skipping to change at page 32, line 7 skipping to change at page 25, line 48
o Re-invites with no SDP o Re-invites with no SDP
o The UPDATE method [7] o The UPDATE method [7]
o Reliability of provisional responses [6] o Reliability of provisional responses [6]
o Integration of resource management and SIP [2]. o Integration of resource management and SIP [2].
12. Security Considerations 12. Security Considerations
12.1 Identity 12.1 Authorization and Authentication
The principal security consideration with third party call control is In most uses of SIP INVITE, whether or not a call is accepted is
identity. When the controller initiates the call, what identity does based on a decision made by a human when presented information about
it place in the From field of the INVITE? The controller could the call, such as the identity of the caller. In other cases,
indicate that the call is from itself (From: automata answer the calls, and whether or not they do so may depend
sip:controller@example.com), but the call is really from some user, on the particular application to which SIP is applied. For example,
and is just facilitated by the controller. This impacts on how the if a caller makes a SIP call to a voice portal service, the call may
call is authenticated by the end users. 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 desribed by the Call Processing
Language [13]. Frequently, those decisions are also made based on the
identity of the caller.
There are many cases, and the right one depends on the application of These authorization mechanisms would be applied to normal first party
3pcc. In one common scenario, the controller is acting on behalf of calls and third party calls, as these two are indistinguishable. As a
one of the participants in the call. A typical example is result, it is important for these authorization policies to continue
click-to-dial, where the controller and the customer service to operate correctly for third party calls. Of course, third party
representative are run by the same administrative domain. Indeed, for calls introduce a new party - the one initiating the third party
the purposes of identification, the controller can legitimately claim call. Do the authorization policies apply based on the identity of
to be the customer service representative. In this scenario, it would that third party, or do they apply based on the participants in the
be appropriate for the INVITE to the end user to contain a From field 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.
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 identifying the customer service rep, and authenticate the request
using S/MIME signed by the key of the customer service rep (which is using S/MIME (see RFC 3261 [1], Section 23) signed by the key of the
held by the controller) customer service rep (which is held by the controller)
This requires the controller to actually have credentials with which This requires the controller to actually have credentials with which
it can authenticate itself as the customer support representative. In it can authenticate itself as the customer support representative. In
many other cases, the controller is representing one of the many other cases, the controller is representing one of the
participants, but does not possess their credentials. Unfortunately, participants, but does not possess their credentials. Unfortunately,
there are currently no standardized mechanisms that allow a user to there are currently no standardized mechanisms that allow a user to
delegate credentials to the controller in a way that limits their delegate credentials to the controller in a way that limits their
usage to specific third party call control operations. In the absence 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 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 who's name in the From field to indicate the identity of the user on who's
skipping to change at page 37, line 9 skipping to change at page 28, line 35
[7] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE [7] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002. Method", RFC 3311, October 2002.
[8] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP [8] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP
32, RFC 2606, June 1999. 32, RFC 2606, June 1999.
Informative References Informative References
[9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, [9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC "RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996. 3550, July 2003.
[10] Petrack, S. and L. Conroy, "The PINT Service Protocol: [10] Petrack, S. and L. Conroy, "The PINT Service Protocol:
Extensions to SIP and SDP for IP Access to Telephone Call Extensions to SIP and SDP for IP Access to Telephone Call
Services", RFC 2848, June 2000. Services", RFC 2848, June 2000.
[11] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. [11] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[12] Baugher, M. and D. Wing, "SDP Security Descriptions for Media [12] Andreasen, F., Baugher, M. and D. Wing, "SDP Security
Streams", draft-ietf-mmusic-sdescriptions-00 (work in Descriptions for Media Streams",
progress), February 2003. draft-ietf-mmusic-sdescriptions-02 (work in progress), October
2003.
[13] Lennox, J., Wu, X. and H. Schulzrinne, "CPL: A Language for
User Control of Internet Telephony Services",
draft-ietf-iptel-cpl-08 (work in progress), August 2003.
Authors' Addresses Authors' Addresses
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
Phone: +1 973 952-5000 Phone: +1 973 952-5000
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/