draft-ietf-sipping-3pcc-00.txt   draft-ietf-sipping-3pcc-01.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-00.txt draft-ietf-sipping-3pcc-01.txt
May 10, 2002 May 29, 2002
Expires: November 2002 Expires: November 2002
Best Current Practices for Third Party Call Control Best Current Practices for Third Party Call Control
in the Session Initiation Protocol 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.
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 ............................................. 8 4.4 Flow IV ............................................. 8
4.5 Recommendations ..................................... 9 4.5 Recommendations ..................................... 10
5 Error Handling ...................................... 10 5 Error Handling ...................................... 10
6 Continued Processing ................................ 10 6 Continued Processing ................................ 11
7 3pcc and Early Media ................................ 11 7 3pcc and Early Media ................................ 12
8 Third arty call control and SDP preconditions ....... 14 8 Third Party Call Control and SDP Preconditions ...... 16
9 Example Call Flows .................................. 15 8.1 Controller Initiates ................................ 16
9.1 Click to Dial ....................................... 15 8.2 Party A Initiates ................................... 17
9.2 Mid-Call Announcement Capability .................... 18 9 Example Call Flows .................................. 20
10 Implementation Recommendations ...................... 20 9.1 Click to Dial ....................................... 20
11 Security Considerations ............................. 21 9.2 Mid-Call Announcement Capability .................... 22
12 IANA Considerations ................................. 21 10 Implementation Recommendations ...................... 24
13 Authors Addresses ................................... 21 11 Security Considerations ............................. 24
14 Normative References ................................ 22 11.1 Identity ............................................ 24
15 Informative References .............................. 22 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
1 Introduction 1 Introduction
(Note to RFC Editor - please replace all instances of RFC BBBB with (Note to RFC Editor - please replace all instances of RFC BBBB with
RFC 3261 when draft-ietf-sip-rfc2543bis is published as an RFC. RFC 3261 when draft-ietf-sip-rfc2543bis is published as an RFC.
Please replace all instances of RFC MMMM with the RFC number of Please replace all instances of RFC MMMM with the RFC number of
draft-ietf-sip-manyfolks-resource when it issues as an RFC.) draft-ietf-sip-manyfolks-resource when it issues as an RFC.)
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
skipping to change at page 4, line 42 skipping to change at page 4, line 42
|------------------>| | |------------------>| |
| |(3) INVITE offer1 | | |(3) INVITE offer1 |
| |------------------>| | |------------------>|
| |(4) 200 OK answer1 | | |(4) 200 OK answer1 |
| |<------------------| | |<------------------|
| |(5) ACK | | |(5) ACK |
| |------------------>| | |------------------>|
|(6) ACK answer1 | | |(6) ACK answer1 | |
|<------------------| | |<------------------| |
|(7) RTP | | |(7) RTP | |
|-------------------------------------->| |.......................................|
Figure 1: 3pcc Flow I Figure 1: 3pcc Flow I
The call flow for Flow I is shown in Figure 1. The controller first The call flow for Flow I is shown in Figure 1. The controller first
sends an INVITE A (1). This INVITE has no session description. A's sends an INVITE A (1). This INVITE has no session description. A's
phone rings, and A answers. This results in a 200 OK (2) that phone rings, and A answers. This results in a 200 OK (2) that
contains an offer [4]. The controller needs to send its answer in the contains an offer [4]. The controller needs to send its answer in the
ACK, as mandated by [1]. To obtain the answer, it sends the offer it ACK, as mandated by [1]. To obtain the answer, it sends the offer it
got from A (offer1) in an INVITE to B (3). B's phone rings. When B got from A (offer1) in an INVITE to B (3). B's phone rings. When B
answers, the 200 OK (4) contains the answer to this offer, answer1. answers, the 200 OK (4) contains the answer to this offer, answer1.
skipping to change at page 5, line 47 skipping to change at page 5, line 47
controller sends an ACK (4). It then generates a second INVITE (3). 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 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 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, 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 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 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 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, 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 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, an offer. Fortunately, an answer to an answer recast as an offer is,
in turn, a valid offer. This re-INVITE generatea a 200 OK (8) with 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 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 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 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 |
| |------------------>| | |------------------>|
skipping to change at page 6, line 24 skipping to change at page 6, line 24
| |<------------------| | |<------------------|
| |(6) ACK | | |(6) ACK |
| |------------------>| | |------------------>|
|(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
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. If 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.
However, experience has shown that many UAs respond to an offer of a However, experience has shown that many UAs respond to an offer of a
0.0.0.0 connection address with an answer containing a 0.0.0.0 0.0.0.0 connection address with an answer containing a 0.0.0.0
connection address. The offer-answer specification [4] now explicitly connection address. The offer-answer specification [4] now explicitly
tells implementors not to do this, but at the time of publication of tells implementors not to do this, but at the time of publication of
skipping to change at page 7, line 37 skipping to change at page 7, line 37
| |<---------------------| | |<---------------------|
|(6) INVITE offer2' | | |(6) INVITE offer2' | |
|<---------------------| | |<---------------------| |
|(7) 200 answer2' | | |(7) 200 answer2' | |
|--------------------->| | |--------------------->| |
| |(8) ACK answer2 | | |(8) ACK answer2 |
| |--------------------->| | |--------------------->|
|(9) ACK | | |(9) ACK | |
|<---------------------| | |<---------------------| |
|(10) RTP | | |(10) RTP | |
|-------------------------------------------->| |.............................................|
Figure 3: 3pcc Flow III Figure 3: 3pcc Flow III
A thid 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 connection an answer (3). This answer is a "black hole" SDP, with its connection
address set to 0.0.0.0. address set to 0.0.0.0.
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
skipping to change at page 8, line 49 skipping to change at page 8, line 49
terminate the call. Finally, the flow is far more complicated than terminate the call. Finally, the flow is far more complicated than
the simple and elegant Flow I (Figure 1). the simple and elegant Flow I (Figure 1).
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]. The 200 OK (2) has an answer with no later through a re-INVITE [4]. Once the INVITE is received, user A is
media either. This is acknowledged by the controller (3). The flow alerted. When they answer the call, the 200 OK (2) has an answer with
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 9, line 26 skipping to change at page 9, line 26
| |<---------------------| | |<---------------------|
|(6) INVITE offer2' | | |(6) INVITE offer2' | |
|<---------------------| | |<---------------------| |
|(7) 200 answer2' | | |(7) 200 answer2' | |
|--------------------->| | |--------------------->| |
| |(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 from this point onwards is identical to Flow III. However, the
manipuldations required to convert offer2 to offer2', and answer2' to manipulations required to convert offer2 to offer2', and answer2' to
answer2, are much simpler. Indeed, no media manipulations are needed answer2, are much simpler. Indeed, no media manipulations are needed
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
will be alerted without any media having been established yet. This
means that user A will not be able to reject or accept the call based
on its media composition. Secondly, both A and B will end up
answering the call (i.e., generating a 200 OK) before it is known
whether their is compatible media. If there is no media in common,
the call can be terminated later with a BYE. However, the users will
have already been alerted, resulting in user annoyance and possibly
resulting in billing events.
4.5 Recommendations 4.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,
conferencing servers, and messaging servers, for example. Since we conferencing servers, and messaging servers, for example. Since we
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.
skipping to change at page 10, line 21 skipping to change at page 10, line 31
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.
5 Error Handling 5 Error Handling
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
controller send a BYE to A. This BYE SHOULD include a Reason header controller send a BYE to A. This BYE SHOULD include a Reason header
[5] which carries the status code from the error response. This will [5] which carries the status code from the error response. This will
inform A of the precise reason for the failure. The information is inform A of the precise reason for the failure. The information is
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
the controller establishes the dialog with A (messages 1-3) it
attempts to contact B (message 4). Contacting B may take some time.
During that interval, A could possibly attempt a re-INVITE, providing
an updated offer. However, the controller cannot pass this offer on
A Controller B
|(1) INVITE offer1 | |
|no media | |
|<---------------------| |
|(2) 200 answer1 | |
|no media | |
|--------------------->| |
|(3) ACK | |
|<---------------------| |
| |(4) INVITE no SDP |
| |--------------------->|
| |(5) 180 |
| |<---------------------|
|(6) INVITE offer2 | |
|--------------------->| |
|(7) 491 | |
|<---------------------| |
|(8) ACK | |
|--------------------->| |
Figure 5: 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
the 491), and this may occur before the exchange with B is completed.
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 5. 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 5: 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 6, 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,
as the controller sees fit. as the controller sees fit.
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).
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 7 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 12, line 28 skipping to change at page 13, line 28
| |<---------------| | | |<---------------| |
| |(8) INV offer3' | | | |(8) INV offer3' | |
| |-------------------------------->| | |-------------------------------->|
| |(9) 200 answer3'| | | |(9) 200 answer3'| |
| |<--------------------------------| | |<--------------------------------|
| |(10) ACK | | | |(10) ACK | |
| |-------------------------------->| | |-------------------------------->|
| |(11) ACK answer3| | | |(11) ACK answer3| |
| |--------------->| | | |--------------->| |
| | |(12) RTP | | | |(12) RTP |
| | |--------------->| | | |................|
Figure 6: 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 8. 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> | |
| | |
| | |
|<answer> | |
| | |
|(2) 200 answer1 | | |(2) 200 answer1 | |
|no media | | |no media | |
|--------------------->| | |--------------------->| |
| | |
|(3) ACK | | |(3) ACK | |
|<---------------------| | |<---------------------| |
| | |
| |(4) INVITE no SDP | | |(4) INVITE no SDP |
| |--------------------->| | |--------------------->|
| | |
| | |<ring>
| | |
| | |
| |(5) 183 offer2 | | |(5) 183 offer2 |
| |<---------------------| | |<---------------------|
| | |
|(6) INVITE offer2' | | |(6) INVITE offer2' | |
|<---------------------| | |<---------------------| |
| | |
|(7) 200 answer2' | | |(7) 200 answer2' | |
|--------------------->| | |--------------------->| |
| |(8) PRACK answer2 | | | |
|(8) ACK | |
|<---------------------| |
| | |
| |(9) PRACK answer2 |
| |--------------------->| | |--------------------->|
| |(9) 200 PRACK | | | |
| |(10) 200 PRACK |
| |<---------------------| | |<---------------------|
|(10) RTP | | | | |
|<--------------------------------------------| |(11) RTP | |
| |(11) 200 OK | |.............................................|
| | |
| | |<answer>
| | |
| | |
| |(12) 200 OK |
| |<---------------------| | |<---------------------|
| |(12) ACK | | | |
| |(13) ACK |
| |--------------------->| | |--------------------->|
| | |
| | |
| | |
Figure 7: Early Media from User B Figure 8: Early Media from User B
it to get the origin field correct). User A generates its answer in
the 200 OK to the UPDATE (8). This answer is passed to user B in the
ACK (9). When user A finally answers (11), there is no change in
session state, so the controller simply ACKs the 200 OK (12).
Note that it is likely that there will be clipping of media in this
call flow. User A is likely a PSTN gateway, and has generated a
provisional response because of early media from the PSTN side. The
PSTN will deliver this media even though the gateway does not have
anywhere to send it, since the initial offer from the controller had
no media streams. When user B answers, media can begin to flow.
However, any media sent to the gateway from the PSTN up to that point
will be lost.
A Controller B A Controller B
| | |
|(1) INVITE offer1 | | |(1) INVITE offer1 | |
|no media | | |no media | |
|<---------------------| | |<---------------------| |
| | |
|ring | |
| | |
|(2) 183 answer1 | | |(2) 183 answer1 | |
|no media | | |no media | |
|--------------------->| | |--------------------->| |
| | |
|(3) PRACK | | |(3) PRACK | |
|<---------------------| | |<---------------------| |
| | |
|(4) 200 PRACK | | |(4) 200 PRACK | |
|--------------------->| | |--------------------->| |
| | |
| |(5) INVITE no SDP | | |(5) INVITE no SDP |
| |--------------------->| | |--------------------->|
| | |
| | |ring
| | |
| | |
| | |answer
| | |
| | |
| |(6) 200 OK offer2 | | |(6) 200 OK offer2 |
| |<---------------------| | |<---------------------|
| | |
|(7) UPDATE offer2' | | |(7) UPDATE offer2' | |
|<---------------------| | |<---------------------| |
| | |
|answer | |
| | |
| | |
|(8) 200 answer2' | | |(8) 200 answer2' | |
|--------------------->| | |--------------------->| |
| | |
| |(9) ACK answer2 | | |(9) ACK answer2 |
| |--------------------->| | |--------------------->|
| | |
|(10) RTP | | |(10) RTP | |
|-------------------------------------------->| |.............................................|
| | |
|(11) 200 OK | | |(11) 200 OK | |
|--------------------->| | |--------------------->| |
| | |
|(12) ACK | | |(12) ACK | |
|<---------------------| | |<---------------------| |
| | |
| | |
| | |
Figure 9: Early Media from User A
Figure 8: 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
the 200 OK to the UPDATE (8). This answer is passed to user B in the
ACK (9). When user A finally answers (11), there is no change in
session state, so the controller simply ACKs the 200 OK (12).
8 Third arty call control and SDP preconditions Note that it is likely that there will be clipping of media in this
call flow. User A is likely a PSTN gateway, and has generated a
provisional response because of early media from the PSTN side. The
PSTN will deliver this media even though the gateway does not have
anywhere to send it, since the initial offer from the controller had
no media streams. When user B answers, media can begin to flow.
However, any media sent to the gateway from the PSTN up to that point
will be lost.
8 Third Party Call Control and SDP Preconditions
A SIP extension has been specified that allows for the coupling of A SIP extension has been specified that allows for the coupling of
signaling and resource reservation [2]. This draft relies on signaling and resource reservation [2]. This draft relies on
exchanges of session descriptions before completion of the call exchanges of session descriptions before completion of the call
setup. These flows are initiated when certain SDP parameters are setup. These flows are initiated when certain SDP parameters are
passed in the initial INVITE. As a result, the interaction of this passed in the initial INVITE. As a result, the interaction of this
mechanism with third party call control is not obvious, and worth mechanism with third party call control is not obvious, and worth
detailing. detailing.
Consider the call flow in Figure 9. The controller follows Flow IV; 8.1 Controller Initiates
it has no specific requirements for support of the preconditions
specification [2]. Indeed, there is no mechanism that can be used
with Flow IV which allows the controller to request preconditions.
Therefore, it sends an INVITE (1) with SDP that contains no media
lines. User A is interested in supporting preconditions, and does not
want to ring its phone until resources are reserved. Since there are
no media streams in the INVITE, it can't ring the phone until they
are conveyed in a subsequent offer. Therefore, it generates a 183
with the answer, and doesn't alert the user (2). The controller
PRACKs this (3) and A responds to the PRACK (4).
At this point, the controller attempts to bring B into the call. It In one usage scenario, the controller wishes to make use of
sends B an INVITE without SDP (5). B is interested in having preconditions in order to avoid the call failure scenarios documented
preconditions for this call. Therefore, it generates its offer in a in Section 4.4. Specifically, the controller can use preconditions in
183 that contains the appropriate SDP attributes (6). The controller order to guarantee that neither party is alerted unless there is a
passes this offer to A in an UPDATE request (7). The controller uses common set of media and codecs. It can also provide both parties with
UPDATE because the call has not been answered yet, and therefore, it information on the media composition of the call before they decide
cannot use a re-INVITE. User A sees that its peer is capable of to accept it.
supporting preconditions. Since it desires preconditions for the
call, it generates an answer in the 200 OK (8) to the UPDATE. This
answer, in turn, is passed to B in the PRACK for the provisional
response (9). Now, both sides perform resource reservation. User A
succeeds first, and passes an updated session description in an
UPDATE request (13). The controller simply passes this to A (after
the manipulation of the origin field, as required in Flow IV) in an
UPDATE (14), and the answer (15) is passed back to A (16). The same
flow happens, but from B to A, when B's reservation succeeds (17-20).
Since the preconditions have been met, both sides ring (21 and 22),
and then both answer (23 and 25), completing the call.
What is important about this flow is that the controller doesn't know The flow for this scenario is shown in Figure 10. In this example, we
anything about preconditions. It merely passes the SDP back and forth assume that user B is an automata or agent of some sort which will
as needed. The trick is the usage of UPDATE and PRACK to pass the SDP answer the call immediately. Therefore, the flow is based on Flow I.
when needed. That determination is made entirely based on the The controller sends an INVITE to user A containing no SDP, but with
offer/answer rules described in [6] and [7], and is independent of a Require header indicating that preconditions are required. This
preconditions. specific scenario (an INVITE without an offer, but with a Require
header indicating preconditions) is not described in [2]. It is
RECOMMENDED that the UAS respond with an offer in a 1xx including the
media streams it wishes to use for the call, and for each, list all
preconditions it supports as optional. Of course, the user is not
alerted at this time. The controller takes this offer and passes it
to user B (3). User B does not support preconditions, or does, but is
not interested in them. Therefore, when it answers the call, the 200
OK contains an answer without any preconditions listed (4). This
answer is passed to user A in the PRACK (6). At this point, user A
knows that there are no preconditions actually in use for the call,
and therefore, it can alert the user. When the call is answered, user
A sends a 200 OK to the controller (8) and the call is complete.
9 Example Call Flows In the event that the offer generated by user A was not acceptable to
user B (because of non-overlapping codecs or media, for example),
user B would immediately reject the INVITE (message 3). The
controller would then CANCEL the request to user A. In this
situation, neither user A nor user B would have been alerted,
achieving the desired effect. It is interesting to note that this
property is achieved using preconditions even though it doesn't
matter what specific types of preconditions are supported by user A.
9.1 Click to Dial It is also entirely possible that user B does actually desire
preconditions. In that case, it might generate a 1xx of its own with
an answer containing preconditions. That answer would still be passed
to user A, and both parties would proceed with whatever measures are
necessary to meet the preconditions. Neither user would be alerted
until the preconditions were met.
The first application of this capability we discuss is click to dial. 8.2 Party A Initiates
In this service, a user is browsing the web page of an e-commerce
site, and would like to speak to a customer service representative. In Section 8.1, the controller requested the use of preconditions to
They click on a link, and a call is placed to a customer service achieve a specific goal. It is also possible that the controller
representative. When the representative picks up, the phone on the doesn't care (or perhaps doesn't even know) about preconditions, but
user's desk rings. When they pick up, the customer service one of the participants in the call does care. A call flow for this
representative is there, ready to talk to the user. case is shown in Figure 11.
The controller follows Flow IV; it has no specific requirements for
support of the preconditions specification [2]. Therefore, it sends
an INVITE (1) with SDP that contains no media lines. User A is
interested in supporting preconditions, and does not want to ring its
phone until resources are reserved. Since there are no media streams
in the INVITE, it can't reserve resources for media streams, and
therefore it can't ring the phone until they are conveyed in a
subsequent offer and then reserved. Therefore, it generates a 183
with the answer, and doesn't alert the user (2). The controller
PRACKs this (3) and A responds to the PRACK (4).
User Controller Customer Service
| | |
|(1) INVITE no SDP | |
|require precon | |
|<------------------| |
|(2) 183 offer1 | |
|optional precon | |
|------------------>| |
| | |
| |(3) INVITE offer1 |
| |------------------>|
| | |
| | |<ring>
| | |
| | |
| | |<answer>
| | |
| |(4) 200 OK answer1 |
| |no precon |
| |<------------------|
| | |
| |(5) ACK |
| |------------------>|
| | |
|(6) PRACK answer1 | |
|<------------------| |
| | |
|<ring> | |
| | |
| | |
|(7) 200 PRACK | |
|------------------>| |
| | |
|<answer> | |
| | |
| | |
|(8) 200 INVITE | |
|------------------>| |
| | |
|(9) ACK | |
|<------------------| |
| | |
| | |
| | |
Figure 10: Controller Initiated Preconditions
A Controller B A Controller B
|(1) INVITE offer1 | | |(1) INVITE offer1 | |
|no media | | |no media | |
|<---------------------| | |<---------------------| |
|(2) 183 answer1 | | |(2) 183 answer1 | |
|no media | | |no media | |
|--------------------->| | |--------------------->| |
|(3) PRACK | | |(3) PRACK | |
|<---------------------| | |<---------------------| |
|(4) 200 OK | | |(4) 200 OK | |
skipping to change at page 16, line 67 skipping to change at page 19, line 66
| |des=sendrecv | | |des=sendrecv |
| |conf=recv | | |conf=recv |
| |cur=send | | |cur=send |
| |<---------------------| | |<---------------------|
|(16) 200 UPDATE | | |(16) 200 UPDATE | |
|answer3 | | |answer3 | |
|des=sendrecv | | |des=sendrecv | |
|conf=recv | | |conf=recv | |
|cur=send | | |cur=send | |
|<---------------------| | |<---------------------| |
| | |<ring>
| |(17) UPDATE offer4 | | |(17) UPDATE offer4 |
| |des=sendrecv | | |des=sendrecv |
| |conf=recv | | |conf=recv |
| |cur=sendrecv | | |cur=sendrecv |
| |<---------------------| | |<---------------------|
|(18) UPDATE offer4' | | |(18) UPDATE offer4' | |
|des=sendrecv | | |des=sendrecv | |
|conf=recv | | |conf=recv | |
|cur=sendrecv | | |cur=sendrecv | |
|<---------------------| | |<---------------------| |
|<ring> | |
|(19) 200 UPDATE | | |(19) 200 UPDATE | |
|answer4' | | |answer4' | |
|des=sendrecv | | |des=sendrecv | |
|conf=recv | | |conf=recv | |
|cur=sendrecv | | |cur=sendrecv | |
|--------------------->| | |--------------------->| |
| |(20) 200 UPDATE | | |(20) 200 UPDATE |
| |answer4 | | |answer4 |
| |des=sendrecv | | |des=sendrecv |
| |conf=recv | | |conf=recv |
| |cur=sendrecv | | |cur=sendrecv |
| |--------------------->| | |--------------------->|
|(21) 180 INVITE | | |(21) 180 INVITE | |
|--------------------->| | |--------------------->| |
| |(22) 180 INVITE | | |(22) 180 INVITE |
| |<---------------------| | |<---------------------|
|<answer> | |
|(23) 200 INVITE | | |(23) 200 INVITE | |
|--------------------->| | |--------------------->| |
|(24) ACK | | |(24) ACK | |
|<---------------------| | |<---------------------| |
| | |<answer>
| |(25) 200 INVITE | | |(25) 200 INVITE |
| |<---------------------| | |<---------------------|
| |(26) ACK | | |(26) ACK |
| |--------------------->| | |--------------------->|
Figure 11: User A Initiated Preconditions
Figure 9: Call Flow for 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
passes this offer to A in an UPDATE request (7). The controller uses
UPDATE because the call has not been answered yet, and therefore, it
cannot use a re-INVITE. User A sees that its peer is capable of
supporting preconditions. Since it desires preconditions for the
call, it generates an answer in the 200 OK (8) to the UPDATE. This
answer, in turn, is passed to B in the PRACK for the provisional
response (9). Now, both sides perform resource reservation. User A
succeeds first, and passes an updated session description in an
UPDATE request (13). The controller simply passes this to A (after
the manipulation of the origin field, as required in Flow IV) in an
UPDATE (14), and the answer (15) is passed back to A (16). The same
flow happens, but from B to A, when B's reservation succeeds (17-20).
Since the preconditions have been met, both sides ring (21 and 22),
and then both answer (23 and 25), completing the call.
What is important about this flow is that the controller doesn't know
anything about preconditions. It merely passes the SDP back and forth
as needed. The trick is the usage of UPDATE and PRACK to pass the SDP
when needed. That determination is made entirely based on the
offer/answer rules described in [6] and [7], and is independent of
preconditions.
9 Example Call Flows
9.1 Click to Dial
The first application of this capability we discuss is click to dial.
In this service, a user is browsing the web page of an e-commerce
site, and would like to speak to a customer service representative.
They click on a link, and a call is placed to a customer service
representative. When the representative picks up, the phone on the
user's desk rings. When they pick up, the customer service
representative is there, ready to talk to the user.
The call flow for this service is given in Figure 12. It is identical
to that of Figure 4, with the exception that the service is triggered
through an http GET request when the user clicks on the link.
We note that this service can be provided through other mechanisms,
namely PINT [9]. However, there are numerous differences between the
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 17, line 30 skipping to change at page 21, line 30
| |<------------------| | | |<------------------| |
|(8) INVITE offer2' | | | |(8) INVITE offer2' | | |
|<------------------| | | |<------------------| | |
|(9) 200 answer2' | | | |(9) 200 answer2' | | |
|------------------>| | | |------------------>| | |
| |(10) ACK answer2 | | | |(10) ACK answer2 | |
| |------------------>| | | |------------------>| |
|(11) ACK | | | |(11) ACK | | |
|<------------------| | | |<------------------| | |
|(12) RTP | | | |(12) RTP | | |
|-------------------------------------->| | |.......................................| |
Figure 10: Click to Dial Call Flow
The call flow for this service is given in Figure 10. It is identical Figure 12: Click to Dial Call Flow
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.
We note that this service can be provided through other mechanisms,
namely PINT [9]. However, there are numerous differences between the
way in which the service is provided by pint, and the way in which it 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 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
skipping to change at page 18, line 37 skipping to change at page 22, line 30
timer fires, we would like the user to hear an announcement which timer fires, we would like the user to hear an announcement which
tells them to enter a credit card to continue. Once they enter the 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. 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.
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 11. When the media server. The flow for this is shown in Figure 13. When the
timer expires, the controller places the called party with a timer expires, the controller places the called party with a
connection address of zero (1). This effectively "disconnects" the connection address of 0.0.0.0 (1). This effectively "disconnects" the
called party. The controller then sends an INVITE without SDP to the called party. The controller then sends an INVITE without SDP to the
the pre-paid caller (4). The offer returned from the caller (5) is the pre-paid caller (4). The offer returned from the caller (5) is
used in an INVITE to the media server which will be collecting digits used in an INVITE to the media server which will be collecting digits
(6). This is an instantiation of Flow II. This flow can only be used (6). This is an instantiation of Flow I. This flow can only be used
here because the media server is an automata, and will answer the here because the media server is an automata, and will answer the
INVITE immediately. If the controller was connecting the pre-paid INVITE immediately. If the controller was connecting the pre-paid
user with another end user, Flow III would need to be used. The media user with another end user, Flow III would need to be used. The media
server returns an immediate 200 OK (7) with an answer, which is server returns an immediate 200 OK (7) with an answer, which is
passed to the caller in an ACK (8). The result is that the media passed to the caller in an ACK (8). The result is that the media
server and the pre-paid caller have their media streams connected. 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
validated. The media server then passes the card number to the
controller (using some means outside the scope of this
specification), and then hangs up the call (11).
After hanging up with the media server, the controller reconnects the
user to the original called party. To do this, the controller sends
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 | | |
|------------------>| | | |------------------>| | |
| |(6) INV offer2 | | | |(6) INV offer2 | |
| |-------------------------------------->| | |-------------------------------------->|
| |(7) 200 answer2 | | | |(7) 200 answer2 | |
| |<--------------------------------------| | |<--------------------------------------|
|(8) ACK answer2 | | | |(8) ACK answer2 | | |
|<------------------| | | |<------------------| | |
| |(9) ACK | | | |(9) ACK | |
| |-------------------------------------->| | |-------------------------------------->|
|(10) RTP | | | |(10) RTP | | |
|---------------------------------------------------------->| |...........................................................|
| |(11) BYE | | | |(11) BYE | |
| |-------------------------------------->| | |-------------------------------------->|
| |(12) 200 OK | | | |(12) 200 OK | |
| |<--------------------------------------| | |<--------------------------------------|
| |(13) INV no SDP | | | |(13) INV no SDP | |
| |------------------>| | | |------------------>| |
| |(14) 200 offer3 | | | |(14) 200 offer3 | |
| |<------------------| | | |<------------------| |
|(15) INV offer3' | | | |(15) INV offer3' | | |
|<------------------| | | |<------------------| | |
|(16) 200 answer3' | | | |(16) 200 answer3' | | |
|------------------>| | | |------------------>| | |
| |(17) ACK answer3' | | | |(17) ACK answer3' | |
| |------------------>| | | |------------------>| |
|(18) ACK | | | |(18) ACK | | |
|<------------------| | | |<------------------| | |
|(19) RTP | | | |(19) RTP | | |
|-------------------------------------->| | |.......................................| |
Figure 11: Mid-Call Announcement
a credit card number. After collecting the number, the card number is
validated. The controller can then hang up the call to the media
server (11). How the controller can know when to hang up the call is
outside the scope of this document, and might have been done through
an HTTP message from the media server to the controller, for example.
After hanging up with the media server, the controller reconnects the Figure 13: Mid-Call Announcement
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)
contains an offer, offer3. The controller modifies the SDP (as is 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
skipping to change at page 21, line 5 skipping to change at page 24, line 45
o Initial invites with no SDP o Initial invites with no SDP
o Initial invites with SDP but no media lines o Initial invites with SDP but no media lines
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].
11 Security Considerations 11 Security Considerations
The mechanism described here introduces several security 11.1 Identity
considerations. The first issue is that of identity. When the
controller initiates the call, what identity does it place in the
From field of the INVITE? The controller could indicate that the call
is from itself (From: sip:controller@company.com), but in many cases,
the service is more usable if it "spoofs" the identity of the
participant that is actually calling. However, to differentiate
legitimate use of 3pcc from real attacks where a caller is faking an
identity, user agents SHOULDauthenticate the requests. The controller
will, of course, authenticate itself as the controller, rather than
either participant. It is RECOMMENDED that user agents be
configurable with credentials for entities that are legitimate
controllers. Note that this will result in SIP messages whose From
field does not match the identity of originator as determined from
the authentication mechanism.
Some of the flows require the controller to manipulate the SDP. If The principal security consideration with third party call control is
S/MIME is used to encrypt or sign the bodies of the request end-to- identity. When the controller initiates the call, what identity does
end, third party call control will fail. it place in the From field of the INVITE? The controller could
indicate that the call is from itself (From:
sip:controller@company.com), but the call is really from some user,
and is just facilitated by the controller. This impacts on how the
call is authenticated by the end users.
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
one of the participants in the call. A typical example is click-to-
dial, where the controller and the customer service representative
are run by the same administrative domain. Indeed, for the purposes
of identification, the controller can legitimately claim to be the
customer service representative. In this scenario, it would be
appropriate for the INVITE to the end user to contain a From field
identifying the customer service rep, and authenticate the request
using S/MIME signed by the key of the customer service rep (which is
held by the controller).
In other situations, there is no real relationship between the
controller and the participants in the call. In these situations,
ideally the controller would have a means to assert that the call is
from a particular identity (which could be one of the participants,
or even a third party, depending on the application), and to validate
that assertion with a signature using the key of the controller.
11.2 End-to-End Encryption and Integrity
With third party call control, the controller is actually one of the
participants as far as the SIP dialog is concerened. Therefore,
encryption and integrity of the SIP messages, as provided by S/MIME,
will occur between participants and the controller, rather than
directly between participants.
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 Authors Addresses 13 Acknowledgements
The authors would like to thank Paul Kyzivat and Sriram Parameswar
for their comments.
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
email: jdrosen@dynamicsoft.com email: jdrosen@dynamicsoft.com
Jon Peterson Jon Peterson
NeuStar, Inc NeuStar, Inc
skipping to change at page 22, line 17 skipping to change at page 26, line 33
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
14 Normative References 15 Normative References
[1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation [1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
protocol," Internet Draft, Internet Engineering Task Force, Feb. protocol," Internet Draft, Internet Engineering Task Force, Feb.
2002. Work in progress. 2002. Work in progress.
[2] W. Marshall, G. Camarillo, and J. Rosenberg, "Integration of [2] W. Marshall, G. Camarillo, and J. Rosenberg, "Integration of
resource management and SIP," Internet Draft, Internet Engineering resource management and SIP," Internet Draft, Internet Engineering
Task Force, Apr. 2002. Work in progress. Task Force, Apr. 2002. Work in progress.
[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. SDP," Internet Draft, Internet Engineering Task Force, Feb. 2002.
Work in progress. Work in progress.
[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," Internet Draft, Internet
Engineering Task Force, Apr. 2002. Work in progress. Engineering Task Force, May 2002. Work in progress.
[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 SIP," Internet Draft, Internet Engineering Task Force,
Feb. 2002. Work in progress. Feb. 2002. Work in progress.
[7] J. Rosenberg, "The SIP UPDATE method," Internet Draft, Internet [7] J. Rosenberg, "The session initiation protocol UPDATE method,"
Engineering Task Force, Mar. 2002. Work in progress. Internet Draft, Internet Engineering Task Force, May 2002. Work in
progress.
15 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.
Full Copyright Statement Full Copyright Statement
 End of changes. 

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