draft-ietf-sipping-3pcc-05.txt   draft-ietf-sipping-3pcc-06.txt 
SIPPING J. Rosenberg SIPPING J. Rosenberg
Internet-Draft dynamicsoft Internet-Draft dynamicsoft
Expires: April 26, 2004 J. Peterson Expires: June 23, 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
October 27, 2003 December 24, 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-05 draft-ietf-sipping-3pcc-06
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 April 26, 2004. This Internet-Draft will expire on June 23, 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 communication 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4
4. 3pcc Call Establishment . . . . . . . . . . . . . . . . . . 4 4. 3pcc Call Establishment . . . . . . . . . . . . . . . . . . 4
4.1 Flow I . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1 Flow I . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2 Flow II . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2 Flow II . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3 Flow III . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3 Flow III . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4 Flow IV . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4 Flow IV . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Recommendations . . . . . . . . . . . . . . . . . . . . . . 10 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . 10
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 10 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 10
7. Continued Processing . . . . . . . . . . . . . . . . . . . . 11 7. Continued Processing . . . . . . . . . . . . . . . . . . . . 11
8. 3pcc and Early Media . . . . . . . . . . . . . . . . . . . . 13 8. 3pcc and Early Media . . . . . . . . . . . . . . . . . . . . 14
9. Third Party Call Control and SDP Preconditions . . . . . . . 16 9. Third Party Call Control and SDP Preconditions . . . . . . . 16
9.1 Controller Initiates . . . . . . . . . . . . . . . . . . . . 16 9.1 Controller Initiates . . . . . . . . . . . . . . . . . . . . 16
9.2 Party A Initiates . . . . . . . . . . . . . . . . . . . . . 18 9.2 Party A Initiates . . . . . . . . . . . . . . . . . . . . . 18
10. Example Call Flows . . . . . . . . . . . . . . . . . . . . . 21 10. Example Call Flows . . . . . . . . . . . . . . . . . . . . . 21
10.1 Click to Dial . . . . . . . . . . . . . . . . . . . . . . . 21 10.1 Click to Dial . . . . . . . . . . . . . . . . . . . . . . . 21
10.2 Mid-Call Announcement Capability . . . . . . . . . . . . . . 23 10.2 Mid-Call Announcement Capability . . . . . . . . . . . . . . 23
11. Implementation Recommendations . . . . . . . . . . . . . . . 25 11. Implementation Recommendations . . . . . . . . . . . . . . . 25
12. Security Considerations . . . . . . . . . . . . . . . . . . 25 12. Security Considerations . . . . . . . . . . . . . . . . . . 26
12.1 Authorization and Authentication . . . . . . . . . . . . . . 25 12.1 Authorization and Authentication . . . . . . . . . . . . . . 26
12.2 End-to-End Encryption and Integrity . . . . . . . . . . . . 27 12.2 End-to-End Encryption and Integrity . . . . . . . . . . . . 27
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
Normative References . . . . . . . . . . . . . . . . . . . . 27 Normative References . . . . . . . . . . . . . . . . . . . . 28
Informative References . . . . . . . . . . . . . . . . . . . 28 Informative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . 31
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.
Similarly, many SIP services are possible through third party call Similarly, many SIP services are possible through third party call
control. These include the traditional ones on the PSTN, but also new 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 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 web page when they wish to speak to a customer service
representative. The web server then creates a call between the user representative. The web server then creates a call between the user
and a customer service representative. The call can be between two and a customer service representative. The call can be between two
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, and is discussed in Section 9. Similarly, the usage of non-trivial, and is discussed in Section 9. Similarly, the usage of
early media (where session data is exchanged before the call is early media (where session data is exchanged before the call is
accepted) with third party call control is not trivial, and is accepted) with third party call control is not trivial; both of them
discussed in Section 8. 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.
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 10, line 6 skipping to change at page 10, line 6
at all. The only change that is needed is to modify the origin lines, 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 so that the origin line in offer2' is valid based on the value in
offer1 (validify requires that the version increments by one, and offer1 (validify requires that the version increments by one, and
that the other parameters remain unchanged). that the other parameters remain unchanged).
There are some limitations associated with this flow. First, user A There are some limitations associated with this flow. First, user A
will be alerted without any media having been established yet. This 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 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 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 answering the call (i.e., generating a 200 OK) before it is known
whether their is compatible media. If there is no media in common, 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 the call can be terminated later with a BYE. However, the users will
have already been alerted, resulting in user annoyance and possibly have already been alerted, resulting in user annoyance and possibly
resulting in billing events. resulting in billing events.
5. Recommendations 5. Recommendations
Flow I (Figure 1) represents the simplest and the most efficient Flow I (Figure 1) represents the simplest and the most efficient
flow. This flow SHOULD be used by a controller if it knows with 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 certainty that user B is actually an automata that will answer the
call immediately. This is the case for devices such as media servers, call immediately. This is the case for devices such as media servers,
skipping to change at page 10, line 35 skipping to change at page 10, line 35
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 of 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 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 to it will never leave the host which sent them; they are just
discarded. Those flows are therefore specific to IPv4. For other discarded. Those flows are therefore specific to IPv4. For other
network or address types, an address with an equivalent property network or address types, an address with an equivalent property
SHOULD be used. SHOULD be used.
In most cases, including the recommended flow, 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 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.
If the call attempt to B should fail, it is RECOMMENDED that the If the call attempt to B should fail, it is RECOMMENDED that the
skipping to change at page 12, line 23 skipping to change at page 12, line 28
| |<------------------| | |<------------------|
Figure 6 Figure 6
Similarly, if it receives a re-INVITE from one of the participants, Similarly, if it receives a re-INVITE from one of the participants,
it can forward it to the other participant. Depending on which flow it can forward it to the other participant. Depending on which flow
was used, this may require some manipulation on the SDP before was used, this may require some manipulation on the SDP before
passing it on. passing it on.
However, the controller need not "proxy" the SIP messages received However, the controller need not "proxy" the SIP messages received
from one of the parties. Since it is a B2BUA, it can invoke any from one of the parties. Since it is a Back to Back User Agent
signaling mechanism on each dialog, as it sees fit. For example, if (B2BUA), it can invoke any signaling mechanism on each dialog, as it
the controller receives a BYE from A, it can generate a new INVITE to sees fit. For example, if the controller receives a BYE from A, it
a third party, C, and connect B to that participant instead. A call can generate a new INVITE to a third party, C, and connect B to that
flow for this is shown in Figure 7, assuming the case where C participant instead. A call flow for this is shown in Figure 7,
represents an end user, not an automata. Note that it is just Flow assuming the case where C represents an end user, not an automata.
IV. Note that it is just Flow IV.
A Controller B C A Controller B C
|(1) BYE | | | |(1) BYE | | |
|--------------->| | | |--------------->| | |
|(2) 200 OK | | | |(2) 200 OK | | |
|<---------------| | | |<---------------| | |
| |(3) INV no media| | | |(3) INV no media| |
| |-------------------------------->| | |-------------------------------->|
| |(4) 200 no media| | | |(4) 200 no media| |
| |<--------------------------------| | |<--------------------------------|
skipping to change at page 13, line 34 skipping to change at page 13, line 34
| |(10) ACK | | | |(10) ACK | |
| |-------------------------------->| | |-------------------------------->|
| |(11) ACK answer3| | | |(11) ACK answer3| |
| |--------------->| | | |--------------->| |
| | |(12) RTP | | | |(12) RTP |
| | |................| | | |................|
Figure 7 Figure 7
From here, new parties can be added, removed, transferred, and so on, From here, new parties can be added, removed, transferred, and so on,
as the controller sees fit. 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.
It is important to point out that the call need not have been It is important to point out that the call need not have been
established by the controller in order for the processing of this established by the controller in order for the processing of this
section to be used. Rather, the controller could have acted as a section to be used. Rather, the controller could have acted as a
B2BUA during a call established by A towards B (or vice a versa). B2BUA during a call established by A towards B (or vice a versa).
8. 3pcc and Early Media 8. 3pcc and Early Media
Early media represents the condition where the session is established Early media represents the condition where the session is established
(as a result of the completion of an offer/answer exchange), yet the (as a result of the completion of an offer/answer exchange), yet the
skipping to change at page 22, line 37 skipping to change at page 22, line 37
| |------------------>| | | |------------------>| |
|(11) ACK | | | |(11) ACK | | |
|<------------------| | | |<------------------| | |
|(12) RTP | | | |(12) RTP | | |
|.......................................| | |.......................................| |
Figure 12 Figure 12
The call flow for this service is given in Figure 12. It is identical 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 to that of Figure 4, with the exception that the service is triggered
through an http GET request when the user clicks on the link. 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 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, We note that this service can be provided through other mechanisms,
namely PINT [10]. However, there are numerous differences between the namely PINT [10]. However, there are numerous differences between the
way in which the service is provided by pint, and the way in which it way in which the service is provided by pint, and the way in which it
is provided here: is provided here:
o The pint solution enables calls only between two PSTN endpoints. o The pint solution enables calls only between two PSTN endpoints.
The solution described here allows calls between PSTN phones The solution described here allows calls between PSTN phones
(through SIP enabled gateways) and native IP phones. (through SIP enabled gateways) and native IP phones.
o When used for calls between two PSTN phones, the solution here may 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 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 pint, the call is always routed only over the PSTN. This may
result in better quality calls with the pint solution, depending result in better quality calls with the pint solution, depending
on the codec in use and QoS capabilities of the network routing on the codec in use and QoS capabilities of the network routing
the Internet portion of the call. the Internet portion of the call.
skipping to change at page 27, line 27 skipping to change at page 27, line 34
that assertion with a signature using the key of the controller. that assertion with a signature using the key of the controller.
12.2 End-to-End Encryption and Integrity 12.2 End-to-End Encryption and Integrity
With third party call control, the controller is actually one of the With third party call control, the controller is actually one of the
participants as far as the SIP dialog is concerened. Therefore, participants as far as the SIP dialog is concerened. Therefore,
encryption and integrity of the SIP messages, as provided by S/MIME, encryption and integrity of the SIP messages, as provided by S/MIME,
will occur between participants and the controller, rather than will occur between participants and the controller, rather than
directly between participants. directly between participants.
However, end-to-end integrity, authenticity and confidentiality of However, integrity, authenticity and confidentiality of the media
the media sessions can be guaranteed through a controller. End-to-end sessions can be provided through a controller. End-to-end media
media security is based on the exchange of keying material within SDP security is based on the exchange of keying material within SDP [12].
[12]. The proper operation of these mechanisms with third party call The proper operation of these mechanisms with third party call
control depends on the controller behaving properly. So long as it is control depends on the controller behaving properly. So long as it is
not attempting to explicitly disable these mechanisms, the protocols not attempting to explicitly disable these mechanisms, the protocols
will properly operate end-to-end, resulting in a secure media session will properly operate between the participants, resulting in a secure
that even the controller cannot eavesdrop or modify. Since third media session that even the controller cannot eavesdrop or modify.
party call control is based on a model of trust between the users and Since third party call control is based on a model of trust between
the controller, it is reasonable to assume it is operating in a the users and the controller, it is reasonable to assume it is
well-behaved manner. 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. IANA Considerations 13. IANA Considerations
There are no IANA considerations associated with this specification. There are no IANA considerations associated with this specification.
14. Acknowledgements 14. Acknowledgements
The authors would like to thank Paul Kyzivat, Rohan Mahy, Eric The authors would like to thank Paul Kyzivat, Rohan Mahy, Eric
Rescorla, Allison Mankin and Sriram Parameswar for their comments. Rescorla, Allison Mankin and Sriram Parameswar for their comments.
Normative References Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
skipping to change at page 28, line 21 skipping to change at page 28, line 31
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Schulzrinne, H., Oran, D. and G. Camarillo, "The Reason Header [5] Schulzrinne, H., Oran, D. and G. Camarillo, "The Reason Header
Field for the Session Initiation Protocol (SIP)", RFC 3326, Field for the Session Initiation Protocol (SIP)", RFC 3326,
December 2002. December 2002.
[6] jdrosen@dynamicsoft.com and schulzrinne@cs.columbia.edu, [6] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
"Reliability of Provisional Responses in Session Initiation Responses in Session Initiation Protocol (SIP)", RFC 3262, June
Protocol (SIP)", RFC 3262, June 2002. 2002.
[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,
 End of changes. 

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