draft-ietf-sipping-3pcc-02.txt   draft-ietf-sipping-3pcc-03.txt 
Internet Engineering Task Force SIPPING WG Internet Engineering Task Force SIPPING WG
Internet Draft J. Rosenberg Internet Draft J. Rosenberg
dynamicsoft dynamicsoft
J. Peterson J. Peterson
Neustar Neustar
H. Schulzrinne H. Schulzrinne
Columbia U. Columbia U.
G. Camarillo G. Camarillo
Ericsson Ericsson
draft-ietf-sipping-3pcc-02.txt draft-ietf-sipping-3pcc-03.txt
June 5, 2002 March 2, 2003
Expires: December 2002 Expires: September 2003
Best Current Practices for Third Party Call Control in the Session Initiation Protocol Best Current Practices for Third Party Call Control
in the Session Initiation Protocol
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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 47 skipping to change at page 1, line 48
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
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 the SIP for third party call control. usage of SIP for third party call control.
1 Introduction Table of Contents
(Note to RFC Editor - please replace all instances of RFC BBBB with 1 Introduction ........................................ 3
RFC 3261 when draft-ietf-sip-rfc2543bis is published as an RFC. 2 Terminology ......................................... 3
Please replace all instances of RFC MMMM with the RFC number of 3 Definitions ......................................... 3
draft-ietf-sip-manyfolks-resource when it issues as an RFC.) 4 3pcc Call Establishment ............................. 4
4.1 Flow I .............................................. 4
4.2 Flow II ............................................. 5
4.3 Flow III ............................................ 7
4.4 Flow IV ............................................. 8
4.5 Recommendations ..................................... 9
5 Error Handling ...................................... 10
6 Continued Processing ................................ 11
7 3pcc and Early Media ................................ 12
8 Third Party Call Control and SDP Preconditions ...... 16
8.1 Controller Initiates ................................ 16
8.2 Party A Initiates ................................... 17
9 Example Call Flows .................................. 20
9.1 Click to Dial ....................................... 20
9.2 Mid-Call Announcement Capability .................... 22
10 Implementation Recommendations ...................... 24
11 Security Considerations ............................. 24
11.1 Identity ............................................ 24
11.2 End-to-End Encryption and Integrity ................. 25
12 IANA Considerations ................................. 26
13 Acknowledgements .................................... 26
14 Authors Addresses ................................... 26
15 Normative References ................................ 27
16 Informative References .............................. 27
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 BBBB [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 MMMM [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. Similarly, the usage of early media (where session data
is exchanged before the call is accepted) with third party call is exchanged before the call is accepted) with third party call
control is not trivial. control is not trivial.
This document serves as a best current practice for implementing This document serves as a best current practice for implementing
third party call control. Section 4 presents the known call flows 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 that can be used to achieve third party call control, and provides
guidelines on their usage. Section 8 discusses the interactions of guidelines on their usage. Section 8 discusses the interactions of
RFC MMMM [2] with third party call control. Section 7 discusses the RFC 3312 [2] with third party call control. Section 7 discusses the
interactions of early media with third party call control. Section 9 interactions of early media with third party call control. Section 9
provides example applications that make usage of the flows provides example applications that make usage of the flows
recommended here. recommended here.
2 Terminology 2 Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and
indicate requirement levels for compliant implementations. indicate requirement levels for compliant implementations.
skipping to change at page 1, line 156 skipping to change at page 5, line 16
The controller sends an ACK to B (5), and then passes answer1 to A in 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 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. answer generated by B, the actual media session is between A and B.
Therefore, media flows between them (7). Therefore, media flows between them (7).
This flow is simple, requires no manipulation of the SDP by the This flow is simple, requires no manipulation of the SDP by the
controller, and works for any media types supported by both controller, and works for any media types supported by both
endpoints. However, it has a serious timeout problem. User B may not endpoints. However, it has a serious timeout problem. User B may not
answer the call immediately. The result is that the controller cannot 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 send the ACK to A right away. This causes A to retransmit the 200 OK
response periodically. As specified in RFC BBBB Section 13.3.1.4, the 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 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 arrive by then, the call is considered to have failed. This limits
the applicability of this flow to scenarios where the controller the applicability of this flow to scenarios where the controller
knows that B will answer the INVITE immediately. knows that B will answer the INVITE immediately.
4.2 Flow II 4.2 Flow II
An alternative flow, Flow II, is shown in Figure 2. The controller
first sends an INVITE 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.
When A answers (2), the 200 OK contains an answer, sdp2. 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. Fortunatly,
all valid answers are valid 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
A Controller B A Controller B
|(1) INVITE bh sdp1 | | |(1) INVITE bh sdp1 | |
|<------------------| | |<------------------| |
|(2) 200 sdp2 | | |(2) 200 sdp2 | |
|------------------>| | |------------------>| |
| |(3) INVITE sdp2 | | |(3) INVITE sdp2 |
| |------------------>| | |------------------>|
|(4) ACK | | |(4) ACK | |
|<------------------| | |<------------------| |
| |(5) 200 OK sdp3 | | |(5) 200 OK sdp3 |
skipping to change at page 1, line 210 skipping to change at page 6, line 4
|(7) INVITE sdp3 | | |(7) INVITE sdp3 | |
|<------------------| | |<------------------| |
|(8) 200 OK sdp2 | | |(8) 200 OK sdp2 | |
|------------------>| | |------------------>| |
|(9) ACK | | |(9) ACK | |
|<------------------| | |<------------------| |
|(10) RTP | | |(10) RTP | |
|.......................................| |.......................................|
Figure 2: 3pcc Flow II Figure 2: 3pcc Flow II
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.
When A answers (2), the 200 OK contains an answer, sdp2. 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. Fortunatly,
all valid answers are valid 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. start flowing once message 5 was sent.
This flow has the advtange that all final responses are immediately This flow has the advtange 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 0.0.0.0 connection address. The controller expects that media with a 0.0.0.0 connection address. The controller expects that
the response contains a valid, non-zero connection address for A. the response contains a valid, non-zero connection address for A.
skipping to change at page 1, line 321 skipping to change at page 8, line 46
4.4 Flow IV 4.4 Flow IV
Flow IV shows a variation on Flow III that reduces its complexity. Flow IV shows a variation on Flow III that reduces its complexity.
The actual message flow is identical, but the SDP placement and The actual message flow is identical, but the SDP placement and
construction differs. The initial INVITE (1) contains SDP with no construction differs. The initial INVITE (1) contains SDP with no
media at all, meaning that there are no m lines. This is valid, and 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 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 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 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,
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 | |
|--------------------->| | |--------------------->| |
|(3) ACK | | |(3) ACK | |
|<---------------------| | |<---------------------| |
| |(4) INVITE no SDP | | |(4) INVITE no SDP |
skipping to change at page 1, line 347 skipping to change at page 9, line 30
|--------------------->| | |--------------------->| |
| |(8) ACK answer2 | | |(8) ACK answer2 |
| |--------------------->| | |--------------------->|
|(9) ACK | | |(9) ACK | |
|<---------------------| | |<---------------------| |
|(10) RTP | | |(10) RTP | |
|.............................................| |.............................................|
Figure 4: 3pcc Flow IV Figure 4: 3pcc Flow IV
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 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 their is compatible media. If there is no media in common,
skipping to change at page 1, line 413 skipping to change at page 10, line 47
important from a user interface perspective. For example, if A was important from a user interface perspective. For example, if A was
calling from a black phone, and B generated a 486, the BYE will 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 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. local busy signal so that A knows that B is busy.
Another error condition worth discussion is shown in Figure 5. After Another error condition worth discussion is shown in Figure 5. After
the controller establishes the dialog with A (messages 1-3) it the controller establishes the dialog with A (messages 1-3) it
attempts to contact B (message 4). Contacting B may take some time. attempts to contact B (message 4). Contacting B may take some time.
During that interval, A could possibly attempt a re-INVITE, providing During that interval, A could possibly attempt a re-INVITE, providing
an updated offer. However, the controller cannot pass this offer on 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
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 | |
|--------------------->| | |--------------------->| |
|(3) ACK | | |(3) ACK | |
|<---------------------| | |<---------------------| |
| |(4) INVITE no SDP | | |(4) INVITE no SDP |
skipping to change at page 1, line 435 skipping to change at page 11, line 26
| |<---------------------| | |<---------------------|
|(6) INVITE offer2 | | |(6) INVITE offer2 | |
|--------------------->| | |--------------------->| |
|(7) 491 | | |(7) 491 | |
|<---------------------| | |<---------------------| |
|(8) ACK | | |(8) ACK | |
|--------------------->| | |--------------------->| |
Figure 5: Glare Error Condition Figure 5: Glare Error Condition
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 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. the 491), and this may occur before the exchange with B is completed.
In that case, the controller would respond with another 491. In that case, the controller would respond with another 491.
6 Continued Processing 6 Continued Processing
Once the calls are established, both participants believe they are in Once the calls are established, both participants believe they are in
a single point-to-point call. However, they are exchanging media a single point-to-point call. However, they are exchanging media
directly with each other, rather than with the controller. The directly with each other, rather than with the controller. The
controller is involved in two dialogs, yet sees no media. controller is involved in two dialogs, yet sees no media.
Since the controller is still a central point for signaling, it now 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 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 the participants, it can create a new BYE and hang up with the other
participant. This is shown in Figure 6. participant. This is shown in 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
was used, this may require some manipulation on the SDP before
passing it on.
A Controller B A Controller B
|(1) BYE | | |(1) BYE | |
|------------------>| | |------------------>| |
|(2) 200 OK | | |(2) 200 OK | |
|<------------------| | |<------------------| |
| |(3) BYE | | |(3) BYE |
| |------------------>| | |------------------>|
| |(4) 200 OK | | |(4) 200 OK |
| |<------------------| | |<------------------|
Figure 6: Hanging Up with 3PCC Figure 6: Hanging Up with 3PCC
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 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 B2BUA, it can invoke any
signaling mechanism on each dialog, as it sees fit. For example, if 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 the controller receives a BYE from A, it can generate a new INVITE to
a third party, C, and connect B to that participant instead. A call a third party, C, and connect B to that participant instead. A call
flow for this is shown in Figure 7, assuming the case where C 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 represents an end user, not an automata. Note that it is just Flow
IV. IV.
From here, new parties can be added, removed, transferred, and so on, From here, new parties can be added, removed, transferred, and so on,
skipping to change at page 1, line 498 skipping to change at page 12, line 43
7 3pcc and Early Media 7 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
call itself has not been accepted. This is usually used to convey call itself has not been accepted. This is usually used to convey
tones or announcements regarding progress of the call. Handling of tones or announcements regarding progress of the call. Handling of
early media in a third party call is straightforward. early media in a third party call is straightforward.
Figure 8 shows the case where user B generates early media before 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 (8) instead of an ACK. When party B finally
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| |
| |<--------------------------------| | |<--------------------------------|
| |(5) ACK | | | |(5) ACK | |
skipping to change at page 1, line 526 skipping to change at page 13, line 32
| |<--------------------------------| | |<--------------------------------|
| |(10) ACK | | | |(10) ACK | |
| |-------------------------------->| | |-------------------------------->|
| |(11) ACK answer3| | | |(11) ACK answer3| |
| |--------------->| | | |--------------->| |
| | |(12) RTP | | | |(12) RTP |
| | |................| | | |................|
Figure 7: Alternative to Hangup Figure 7: Alternative to Hangup
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 (8) instead of an ACK. When party B finally
does accept the call (11), there is no change in the session state, does accept the call (11), there is no change in the session state,
and therefore, no signaling needs to be done with user A. The and therefore, no signaling needs to be done with user A. The
controller simply ACKs the 200 OK (12) to confirm the dialog. controller simply ACKs the 200 OK (12) to confirm the dialog.
The case where user A generates early media is more complicated, and 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 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 sends an INVITE to user A (1), with an offer containing no media
streams. User A generates a reliable provisional response (2) streams. User A generates a reliable provisional response (2)
containing an answer with no media streams. The controller PRACKs containing an answer with no media streams. The controller PRACKs
this provisional response (3). Now, the controller sends an INVITE this provisional response (3). Now, the controller sends an INVITE
without SDP to user B (5). User B's phone rings, and they answer, 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
A Controller B A Controller B
| | | | | |
|(1) INVITE offer1 | | |(1) INVITE offer1 | |
|no media | | |no media | |
|<---------------------| | |<---------------------| |
| | | | | |
|<ring> | | |<ring> | |
| | | | | |
| | | | | |
|<answer> | | |<answer> | |
skipping to change at page 1, line 654 skipping to change at page 16, line 6
|(11) 200 OK | | |(11) 200 OK | |
|--------------------->| | |--------------------->| |
| | | | | |
|(12) ACK | | |(12) ACK | |
|<---------------------| | |<---------------------| |
| | | | | |
| | | | | |
| | | | | |
Figure 9: Early Media from User A Figure 9: Early Media from User A
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 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 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 ACK (9). When user A finally answers (11), there is no change in
session state, so the controller simply ACKs the 200 OK (12). 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 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 call flow. User A is likely a PSTN gateway, and has generated a
provisional response because of early media from the PSTN side. The provisional response because of early media from the PSTN side. The
PSTN will deliver this media even though the gateway does not have PSTN will deliver this media even though the gateway does not have
anywhere to send it, since the initial offer from the controller had anywhere to send it, since the initial offer from the controller had
skipping to change at page 1, line 746 skipping to change at page 17, line 48
support of the preconditions specification [2]. Therefore, it sends support of the preconditions specification [2]. Therefore, it sends
an INVITE (1) with SDP that contains no media lines. User A is an INVITE (1) with SDP that contains no media lines. User A is
interested in supporting preconditions, and does not want to ring its interested in supporting preconditions, and does not want to ring its
phone until resources are reserved. Since there are no media streams phone until resources are reserved. Since there are no media streams
in the INVITE, it can't reserve resources for media streams, and 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 therefore it can't ring the phone until they are conveyed in a
subsequent offer and then reserved. Therefore, it generates a 183 subsequent offer and then reserved. Therefore, it generates a 183
with the answer, and doesn't alert the user (2). The controller with the answer, and doesn't alert the user (2). The controller
PRACKs this (3) and A responds to the PRACK (4). PRACKs this (3) and A responds to the PRACK (4).
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
User Controller Customer Service User Controller Customer Service
| | | | | |
|(1) INVITE no SDP | | |(1) INVITE no SDP | |
|require precon | | |require precon | |
|<------------------| | |<------------------| |
|(2) 183 offer1 | | |(2) 183 offer1 | |
|optional precon | | |optional precon | |
|------------------>| | |------------------>| |
| | | | | |
| |(3) INVITE offer1 | | |(3) INVITE offer1 |
skipping to change at page 1, line 894 skipping to change at page 20, line 6
|--------------------->| | |--------------------->| |
|(24) ACK | | |(24) ACK | |
|<---------------------| | |<---------------------| |
| | |<answer> | | |<answer>
| |(25) 200 INVITE | | |(25) 200 INVITE |
| |<---------------------| | |<---------------------|
| |(26) ACK | | |(26) ACK |
| |--------------------->| | |--------------------->|
Figure 11: User A Initiated Preconditions Figure 11: User A Initiated Preconditions
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 183 that contains the appropriate SDP attributes (6). The controller
passes this offer to A in an UPDATE request (7). The controller uses 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 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 cannot use a re-INVITE. User A sees that its peer is capable of
supporting preconditions. Since it desires preconditions for the supporting preconditions. Since it desires preconditions for the
call, it generates an answer in the 200 OK (8) to the UPDATE. This 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 answer, in turn, is passed to B in the PRACK for the provisional
response (9). Now, both sides perform resource reservation. User A response (9). Now, both sides perform resource reservation. User A
succeeds first, and passes an updated session description in an succeeds first, and passes an updated session description in an
UPDATE request (13). The controller simply passes this to A (after UPDATE request (13). The controller simply passes this to A (after
skipping to change at page 1, line 938 skipping to change at page 20, line 47
representative. When the representative picks up, the phone on the representative. When the representative picks up, the phone on the
user's desk rings. When they pick up, the customer service user's desk rings. When they pick up, the customer service
representative is there, ready to talk to the user. representative is there, ready to talk to the user.
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 GET request when the user clicks on the link.
We note that this service can be provided through other mechanisms, We note that this service can be provided through other mechanisms,
namely PINT [9]. However, there are numerous differences between the 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:
Customer Service Controller Users Phone Users Browser Customer Service Controller Users Phone Users Browser
| |(1) HTTP POST | | | |(1) HTTP POST | |
| |<--------------------------------------| | |<--------------------------------------|
| |(2) HTTP 200 OK | | | |(2) HTTP 200 OK | |
| |-------------------------------------->| | |-------------------------------------->|
|(3) INVITE offer1 | | | |(3) INVITE offer1 | | |
|no media | | | |no media | | |
|<------------------| | | |<------------------| | |
|(4) 200 answer1 | | | |(4) 200 answer1 | | |
|no media | | | |no media | | |
skipping to change at page 1, line 968 skipping to change at page 21, line 35
|------------------>| | | |------------------>| | |
| |(10) ACK answer2 | | | |(10) ACK answer2 | |
| |------------------>| | | |------------------>| |
|(11) ACK | | | |(11) ACK | | |
|<------------------| | | |<------------------| | |
|(12) RTP | | | |(12) RTP | | |
|.......................................| | |.......................................| |
Figure 12: Click to Dial Call Flow Figure 12: Click to Dial Call Flow
way in which the service is provided by pint, and the way in which it
is provided here:
o The pint solution enables calls only between two PSTN o The pint solution enables calls only between two PSTN
endpoints. The solution described here allows calls between endpoints. The solution described here allows calls between
PSTN phones (through SIP enabled gateways) and native IP PSTN phones (through SIP enabled gateways) and native IP
phones. phones.
o When used for calls between two PSTN phones, the solution here o When used for calls between two PSTN phones, the solution here
may result in a portion of the call being routed over the may result in a portion of the call being routed over the
Internet. In pint, the call is always routed only over the Internet. In pint, the call is always routed only over the
PSTN. This may result in better quality calls with the pint PSTN. This may result in better quality calls with the pint
solution, depending on the codec in use and QoS capabilities solution, depending on the codec in use and QoS capabilities
skipping to change at page 1, line 1030 skipping to change at page 22, line 49
server and the pre-paid caller have their media streams connected. server and the 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)
contains an offer, offer3. The controller modifies the SDP (as is
Pre-Paid User Controller Called Party Media Server Pre-Paid User Controller Called Party Media Server
| |(1) INV SDP c=0 | | | |(1) INV SDP c=0 | |
| |------------------>| | | |------------------>| |
| |(2) 200 answer1 | | | |(2) 200 answer1 | |
| |<------------------| | | |<------------------| |
| |(3) ACK | | | |(3) ACK | |
| |------------------>| | | |------------------>| |
|(4) INV no SDP | | | |(4) INV no SDP | | |
|<------------------| | | |<------------------| | |
|(5) 200 offer2 | | | |(5) 200 offer2 | | |
skipping to change at page 1, line 1071 skipping to change at page 24, line 4
|(16) 200 answer3' | | | |(16) 200 answer3' | | |
|------------------>| | | |------------------>| | |
| |(17) ACK answer3' | | | |(17) ACK answer3' | |
| |------------------>| | | |------------------>| |
|(18) ACK | | | |(18) ACK | | |
|<------------------| | | |<------------------| | |
|(19) RTP | | | |(19) RTP | | |
|.......................................| | |.......................................| |
Figure 13: Mid-Call Announcement Figure 13: Mid-Call Announcement
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 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) 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, which the controller passes to user B in the ACK (17). At this point,
the caller and called party are reconnected. the caller and called party are reconnected.
10 Implementation Recommendations 10 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
skipping to change at page 1, line 1122 skipping to change at page 25, line 5
o Integration of resource management and SIP [2]. o Integration of resource management and SIP [2].
11 Security Considerations 11 Security Considerations
11.1 Identity 11.1 Identity
The principal security consideration with third party call control is The principal security consideration with third party call control is
identity. When the controller initiates the call, what identity does identity. When the controller initiates the call, what identity does
it place in the From field of the INVITE? The controller could it place in the From field of the INVITE? The controller could
indicate that the call is from itself (From: indicate that the call is from itself (From:
sip:controller@company.com), but the call is really from some user, sip:controller@example.com), but the call is really from some user,
and is just facilitated by the controller. This impacts on how the and is just facilitated by the controller. This impacts on how the
call is authenticated by the end users. call is authenticated by the end users.
There are many cases, and the right one depends on the application of There are many cases, and the right one depends on the application of
3pcc. In one common scenario, the controller is acting on behalf of 3pcc. In one common scenario, the controller is acting on behalf of
one of the participants in the call. A typical example is click-to- one of the participants in the call. A typical example is click-to-
dial, where the controller and the customer service representative dial, where the controller and the customer service representative
are run by the same administrative domain. Indeed, for the purposes are run by the same administrative domain. Indeed, for the purposes
of identification, the controller can legitimately claim to be the of identification, the controller can legitimately claim to be the
customer service representative. In this scenario, it would be customer service representative. In this scenario, it would be
appropriate for the INVITE to the end user to contain a From field 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 signed by the key of the customer service rep (which is
held by the controller). 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 who's
behalf the call is being made. It is RECOMMENDED that the display
name be set to "<user> on behalf of <controller>", 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 In other situations, there is no real relationship between the
controller and the participants in the call. In these situations, controller and the participants in the call. In these situations,
ideally the controller would have a means to assert that the call is ideally the controller would have a means to assert that the call is
from a particular identity (which could be one of the participants, from a particular identity (which could be one of the participants,
or even a third party, depending on the application), and to validate or even a third party, depending on the application), and to validate
that assertion with a signature using the key of the controller. that assertion with a signature using the key of the controller.
11.2 End-to-End Encryption and Integrity 11.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
the media sessions can be guaranteed through a controller. End-to-end
media security is based on the exchange of keying material within
SDP. For example, protocols such as MIKEY [10] can be used within
SDP. 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 end-to-end, 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.
12 IANA Considerations 12 IANA Considerations
There are no IANA considerations associated with this specification. There are no IANA considerations associated with this specification.
13 Acknowledgements 13 Acknowledgements
The authors would like to thank Paul Kyzivat and Sriram Parameswar The authors would like to thank Paul Kyzivat, Rohan Mahy, Eric
for their comments. Rescorla, Allison Mankin and Sriram Parameswar for their comments.
14 Authors Addresses 14 Authors Addresses
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
72 Eagle Rock Avenue 72 Eagle Rock Avenue
First Floor First Floor
East Hanover, NJ 07936 East Hanover, NJ 07936
US
email: jdrosen@dynamicsoft.com email: jdrosen@dynamicsoft.com
Jon Peterson Jon Peterson
NeuStar, Inc NeuStar, Inc.
1800 Sutter Street, Suite 570 1800 Sutter St
Suite 570
Concord, CA 94520 Concord, CA 94520
USA US
email: jon.peterson@neustar.com EMail: jon.peterson@neustar.biz
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
M/S 0401 M/S 0401
1214 Amsterdam Ave. 1214 Amsterdam Ave.
New York, NY 10027-7003 New York, NY 10027-7003
US
email: schulzrinne@cs.columbia.edu email: schulzrinne@cs.columbia.edu
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Advanced Signalling Research Lab. Advanced Signalling Research Lab.
FIN-02420 Jorvas FIN-02420 Jorvas
Finland Finland
Phone: +358 9 299 3371 Phone: +358 9 299 3371
Fax: +358 9 299 3052 Fax: +358 9 299 3052
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
15 Normative References 15 Normative References
skipping to change at page 1, line 1196 skipping to change at page 27, line 15
Ericsson Ericsson
Advanced Signalling Research Lab. Advanced Signalling Research Lab.
FIN-02420 Jorvas FIN-02420 Jorvas
Finland Finland
Phone: +358 9 299 3371 Phone: +358 9 299 3371
Fax: +358 9 299 3052 Fax: +358 9 299 3052
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
15 Normative References 15 Normative References
[1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.
protocol," Internet Draft, Internet Engineering Task Force, Feb. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
2002. Work in progress. initiation protocol," RFC 3261, Internet Engineering Task Force, June
2002.
[2] W. Marshall, G. Camarillo, and J. Rosenberg, "Integration of [2] "Integration of resource management and session initiation
resource management and SIP," Internet Draft, Internet Engineering protocol (SIP)," RFC 3312, Internet Engineering Task Force, Oct.
Task Force, Apr. 2002. Work in progress. 2002.
[3] S. Bradner, "Key words for use in RFCs to indicate requirement [3] S. Bradner, "Key words for use in rfcs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[4] J. Rosenberg and H. Schulzrinne, "An offer/answer model with [4] J. Rosenberg and H. Schulzrinne, "An offer/answer model with
SDP," Internet Draft, Internet Engineering Task Force, Feb. 2002. session description protocol (SDP)," RFC 3264, Internet Engineering
Work in progress. Task Force, June 2002.
[5] H. Schulzrinne, D. Oran, and G. Camarillo, "The reason header [5] H. Schulzrinne, D. Oran, and G. Camarillo, "The reason header
field for the session initiation protocol," Internet Draft, Internet field for the session initiation protocol (SIP)," RFC 3326, Internet
Engineering Task Force, May 2002. Work in progress. Engineering Task Force, Dec. 2002.
[6] J. Rosenberg and H. Schulzrinne, "Reliability of provisional [6] J. Rosenberg and H. Schulzrinne, "Reliability of provisional
responses in SIP," Internet Draft, Internet Engineering Task Force, responses in session initiation protocol (SIP)," RFC 3262, Internet
Feb. 2002. Work in progress. Engineering Task Force, June 2002.
[7] J. Rosenberg, "The session initiation protocol UPDATE method," [7] J. Rosenberg, "The session initiation protocol (SIP) UPDATE
Internet Draft, Internet Engineering Task Force, May 2002. Work in method," RFC 3311, Internet Engineering Task Force, Oct. 2002.
progress.
16 Informative References 16 Informative References
[8] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a [8] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
transport protocol for real-time applications," RFC 1889, Internet transport protocol for real-time applications," RFC 1889, Internet
Engineering Task Force, Jan. 1996. Engineering Task Force, Jan. 1996.
[9] S. Petrack and L. Conroy, "The PINT service protocol: Extensions [9] S. Petrack and L. Conroy, "The PINT service protocol: Extensions
to SIP and SDP for IP access to telephone call services," RFC 2848, to SIP and SDP for IP access to telephone call services," RFC 2848,
Internet Engineering Task Force, June 2000. Internet Engineering Task Force, June 2000.
[10] J. Arkko et al. , "MIKEY: multimedia Internet keying," internet
draft, Internet Engineering Task Force, Feb. 2003. Work in progress.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement Full Copyright Statement
Copyright (c) The Internet Society (2002). All Rights Reserved. Copyright (c) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at page 1, line 1260 skipping to change at line 1339
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Table of Contents
1 Introduction ........................................ 3
2 Terminology ......................................... 3
3 Definitions ......................................... 4
4 3pcc Call Establishment ............................. 4
4.1 Flow I .............................................. 4
4.2 Flow II ............................................. 5
4.3 Flow III ............................................ 7
4.4 Flow IV ............................................. 8
4.5 Recommendations ..................................... 10
5 Error Handling ...................................... 10
6 Continued Processing ................................ 11
7 3pcc and Early Media ................................ 12
8 Third Party Call Control and SDP Preconditions ...... 16
8.1 Controller Initiates ................................ 16
8.2 Party A Initiates ................................... 17
9 Example Call Flows .................................. 20
9.1 Click to Dial ....................................... 20
9.2 Mid-Call Announcement Capability .................... 22
10 Implementation Recommendations ...................... 24
11 Security Considerations ............................. 24
11.1 Identity ............................................ 24
11.2 End-to-End Encryption and Integrity ................. 25
12 IANA Considerations ................................. 25
13 Acknowledgements .................................... 25
14 Authors Addresses ................................... 25
15 Normative References ................................ 26
16 Informative References .............................. 27
 End of changes. 

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