draft-ietf-sipping-3pcc-06.txt   rfc3725.txt 
SIPPING J. Rosenberg Network Working Group J. Rosenberg
Internet-Draft dynamicsoft Request for Comments: 3725 dynamicsoft
Expires: June 23, 2004 J. Peterson BCP: 85 J. Peterson
Neustar Category: Best Current Practice Neustar
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
G. Camarillo G. Camarillo
Ericsson Advanced Signalling Ericsson
Research Lab April 2004
December 24, 2003
Best Current Practices for Third Party Call Control in the Session Best Current Practices for Third Party Call Control (3pcc)
Initiation Protocol in the Session Initiation Protocol (SIP)
draft-ietf-sipping-3pcc-06
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet Best Current Practices for the
all provisions of Section 10 of RFC2026. Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 23, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
Third party call control refers to the ability of one entity to Third party call control refers to the ability of one entity to
create a call in which communication is actually between other create a call in which communication is actually between other
parties. Third party call control is possible using the mechanisms parties. Third party call control is possible using the mechanisms
specified within the Session Initiation Protocol (SIP). However, specified within the Session Initiation Protocol (SIP). However,
there are several possible approaches, each with different benefits there are several possible approaches, each with different benefits
and drawbacks. This document discusses best current practices for the and drawbacks. This document discusses best current practices for
usage of SIP for third party call control. the usage of SIP for third party call control.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
4. 3pcc Call Establishment . . . . . . . . . . . . . . . . . . 4 4. 3pcc Call Establishment . . . . . . . . . . . . . . . . . . 3
4.1 Flow I . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Flow I . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2 Flow II . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Flow II. . . . . . . . . . . . . . . . . . . . . . . . 5
4.3 Flow III . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Flow III . . . . . . . . . . . . . . . . . . . . . . . 7
4.4 Flow IV . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Flow IV. . . . . . . . . . . . . . . . . . . . . . . . 8
5. Recommendations . . . . . . . . . . . . . . . . . . . . . . 10 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . 9
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 10 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 10
7. Continued Processing . . . . . . . . . . . . . . . . . . . . 11 7. Continued Processing . . . . . . . . . . . . . . . . . . . . 11
8. 3pcc and Early Media . . . . . . . . . . . . . . . . . . . . 14 8. 3pcc and Early Media . . . . . . . . . . . . . . . . . . . . 13
9. Third Party Call Control and SDP Preconditions . . . . . . . 16 9. Third Party Call Control and SDP Preconditions . . . . . . . 16
9.1 Controller Initiates . . . . . . . . . . . . . . . . . . . . 16 9.1. Controller Initiates . . . . . . . . . . . . . . . . . 16
9.2 Party A Initiates . . . . . . . . . . . . . . . . . . . . . 18 9.2. Party A Initiates. . . . . . . . . . . . . . . . . . . 18
10. Example Call Flows . . . . . . . . . . . . . . . . . . . . . 21 10. Example Call Flows . . . . . . . . . . . . . . . . . . . . . 21
10.1 Click to Dial . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. Click-to-Dial. . . . . . . . . . . . . . . . . . . . . 21
10.2 Mid-Call Announcement Capability . . . . . . . . . . . . . . 23 10.2. Mid-Call Announcement Capability . . . . . . . . . . . 23
11. Implementation Recommendations . . . . . . . . . . . . . . . 25 11. Implementation Recommendations . . . . . . . . . . . . . . . 25
12. Security Considerations . . . . . . . . . . . . . . . . . . 26 12. Security Considerations. . . . . . . . . . . . . . . . . . . 26
12.1 Authorization and Authentication . . . . . . . . . . . . . . 26 12.1. Authorization and Authentication . . . . . . . . . . . 26
12.2 End-to-End Encryption and Integrity . . . . . . . . . . . . 27 12.2. End-to-End Encryption and Integrity. . . . . . . . . . 27
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
Normative References . . . . . . . . . . . . . . . . . . . . 28 14.1. Normative References . . . . . . . . . . . . . . . . . 28
Informative References . . . . . . . . . . . . . . . . . . . 28 14.2. Informative References . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . 31 16. Full Copyright Statement . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
In the traditional telephony context, third party call control allows In the traditional telephony context, third party call control allows
one entity (which we call the controller) to set up and manage a one entity (which we call the controller) to set up and manage a
communications relationship between two or more other parties. Third communications relationship between two or more other parties. Third
party call control (referred to as 3pcc) is often used for operator party call control (referred to as 3pcc) is often used for operator
services (where an operator creates a call that connects two services (where an operator creates a call that connects two
participants together) and conferencing. participants together) and conferencing.
Similarly, many SIP services are possible through third party call Similarly, many SIP services are possible through third party call
control. These include the traditional ones on the PSTN, but also new control. These include the traditional ones on the PSTN, but also
ones such as click-to-dial. Click-to-dial allows a user to click on a new ones such as click-to-dial. Click-to-dial allows a user to click
web page when they wish to speak to a customer service on a web page when they wish to speak to a customer service
representative. The web server then creates a call between the user representative. The web server then creates a call between the user
and a customer service representative. The call can be between two and a customer service representative. The call can be between two
phones, a phone and an IP host, or two IP hosts. phones, a phone and an IP host, or two IP hosts.
Third party call control is possible using only the mechanisms Third party call control is possible using only the mechanisms
specified within RFC 3261 [1]. Indeed, many different call flows are specified within RFC 3261 [1]. Indeed, many different call flows are
possible, each of which will work with SIP compliant user agents. possible, each of which will work with SIP compliant user agents.
However, there are benefits and drawbacks to each of these flows. The However, there are benefits and drawbacks to each of these flows.
usage of third party call control also becomes more complex when The usage of third party call control also becomes more complex when
aspects of the call utilize SIP extensions or optional features of aspects of the call utilize SIP extensions or optional features of
SIP. In particular, the usage of RFC 3312 [2] (used for coupling of SIP. In particular, the usage of RFC 3312 [2] (used for coupling of
signaling to resource reservation) with third party call control is signaling to resource reservation) with third party call control is
non-trivial, and is discussed in Section 9. Similarly, the usage of non-trivial, and is discussed in Section 9. Similarly, the usage of
early media (where session data is exchanged before the call is early media (where session data is exchanged before the call is
accepted) with third party call control is not trivial; both of them accepted) with third party call control is not trivial; both of them
specify the way in which user agents generate and respond to SDP, and specify the way in which user agents generate and respond to SDP, and
it is not clear how to do both at the same time. This is discussed it is not clear how to do both at the same time. This is discussed
further in Section 8. further in Section 8.
This document serves as a best current practice for implementing This document serves as a best current practice for implementing
third party call control without usage of any extensions specifically third party call control without usage of any extensions specifically
designed for that purpose. Section 4 presents the known call flows designed for that purpose. Section 4 presents the known call flows
that can be used to achieve third party call control, and provides that can be used to achieve third party call control, and provides
guidelines on their usage. Section 9 discusses the interactions of guidelines on their usage. Section 9 discusses the interactions of
RFC 3312 [2] with third party call control. Section 8 discusses the RFC 3312 [2] with third party call control. Section 8 discusses the
interactions of early media with third party call control. Section 10 interactions of early media with third party call control. Section
provides example applications that make usage of the flows 10 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.
3. Definitions 3. Definitions
skipping to change at page 4, line 25 skipping to change at page 4, line 5
4. 3pcc Call Establishment 4. 3pcc Call Establishment
The primary primitive operation of third party call control is the The primary primitive operation of third party call control is the
establishment of a session between participants A and B. establishment of a session between participants A and B.
Establishment of this session is orchestrated by a third party, Establishment of this session is orchestrated by a third party,
referred to as the controller. referred to as the controller.
This section documents three call flows that the controller can This section documents three call flows that the controller can
utilize in order to provide this primitive operation. utilize in order to provide this primitive operation.
4.1 Flow I 4.1. Flow I
A Controller B A Controller B
|(1) INVITE no SDP | | |(1) INVITE no SDP | |
|<------------------| | |<------------------| |
|(2) 200 offer1 | | |(2) 200 offer1 | |
|------------------>| | |------------------>| |
| |(3) INVITE offer1 | | |(3) INVITE offer1 |
| |------------------>| | |------------------>|
| |(4) 200 OK answer1 | | |(4) 200 OK answer1 |
| |<------------------| | |<------------------|
skipping to change at page 4, line 48 skipping to change at page 4, line 28
|(6) ACK answer1 | | |(6) ACK answer1 | |
|<------------------| | |<------------------| |
|(7) RTP | | |(7) RTP | |
|.......................................| |.......................................|
Figure 1 Figure 1
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
ACK, as mandated by [1]. To obtain the answer, it sends the offer it the ACK, as mandated by [1]. To obtain the answer, it sends the
got from A (offer1) in an INVITE to B (3). B's phone rings. When B offer it got from A (offer1) in an INVITE to B (3). B's phone rings.
answers, the 200 OK (4) contains the answer to this offer, answer1. When B answers, the 200 OK (4) contains the answer to this offer,
The controller sends an ACK to B (5), and then passes answer1 to A in answer1. The controller sends an ACK to B (5), and then passes
an ACK sent to it (6). Because the offer was generated by A, and the answer1 to A in an ACK sent to it (6). Because the offer was
answer generated by B, the actual media session is between A and B. generated by A, and the answer generated by B, the actual media
Therefore, media flows between them (7). session is between A and B. 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
answer the call immediately. The result is that the controller cannot not answer the call immediately. The result is that the controller
send the ACK to A right away. This causes A to retransmit the 200 OK cannot send the ACK to A right away. This causes A to retransmit the
response periodically. As specified in RFC 3261 Section 13.3.1.4, the 200 OK response periodically. As specified in RFC 3261 Section
200 OK will be retransmitted for 64*T1 seconds. If an ACK does not 13.3.1.4, the 200 OK will be retransmitted for 64*T1 seconds. If an
arrive by then, the call is considered to have failed. This limits ACK does not arrive by then, the call is considered to have failed.
the applicability of this flow to scenarios where the controller This limits the applicability of this flow to scenarios where the
knows that B will answer the INVITE immediately. controller knows that B will answer the INVITE immediately.
4.2 Flow II 4.2. Flow II
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 | |
|<------------------| | |<------------------| |
skipping to change at page 6, line 4 skipping to change at page 5, line 35
|<------------------| | |<------------------| |
|(10) RTP | | |(10) RTP | |
|.......................................| |.......................................|
Figure 2 Figure 2
An alternative flow, Flow II, is shown in Figure 2. The controller An alternative flow, Flow II, is shown in Figure 2. The controller
first sends an INVITE to user A (1). This is a standard INVITE, first sends an INVITE to user A (1). This is a standard INVITE,
containing an offer (sdp1) with a single audio media line, one codec, containing an offer (sdp1) with a single audio media line, one codec,
a random port number (but not zero), and a connection address of 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 0.0.0.0. This creates an initial media stream that is "black holed",
holed'', since no media (or RTCP packets [9] will flow from A. The since no media (or RTCP packets [8]) will flow from A. The INVITE
INVITE causes A's phone to ring. causes A's phone to ring.
Note that the usage of 0.0.0.0, though recommended by RFC 3264, Note that the usage of 0.0.0.0, though recommended by RFC 3264,
has numerous drawbacks. It is anticipated that a future has numerous drawbacks. It is anticipated that a future
specification will recommend usage of a domain within the .invalid specification will recommend usage of a domain within the .invalid
DNS top level domain instead of the 0.0.0.0 IP address. As a DNS top level domain instead of the 0.0.0.0 IP address. As a
result, implementors are encouraged to track such developments result, implementors are encouraged to track such developments
once they arise. once they arise.
When A answers (2), the 200 OK contains an answer, sdp2, with a valid When A answers (2), the 200 OK contains an answer, sdp2, with a valid
address in the connection line. The controller sends an ACK (4). It address in the connection line. The controller sends an ACK (4). It
then generates a second INVITE (3). This INVITE is addressed to user 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 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 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 INVITE, it is an offer. Fortunately, all valid answers are valid
initial offers. This INVITE causes B's phone to ring. When it initial offers. This INVITE causes B's phone to ring. When it
answers, it generates a 200 OK (5) with an answer, sdp3. The 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 controller then generates an ACK (6). Next, it sends a re-INVITE to
(7) containing sdp3 as the offer. Once again, there has been a 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. 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 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, 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 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 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 media can flow from A to B. Media from B to A could already start
flowing once message 5 was sent. flowing once message 5 was sent.
This flow has the advantage that all final responses are immediately This flow has the advantage that all final responses are immediately
ACKed. It therefore does not suffer from the timeout and message ACKed. It therefore does not suffer from the timeout and message
inefficiency problems of flow 1. However, it too has troubles. First inefficiency problems of flow 1. However, it too has troubles.
off, it requires that the controller know the media types to be used First off, it requires that the controller know the media types to be
for the call (since it must generate a "blackhole" SDP, which used 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] explicitly connection address. The offer-answer specification [4] 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
this document, many implementations still did. If A should respond this document, many implementations still did. If A should respond
with a 0.0.0.0 connection address in sdp2, the flow will not work. with a 0.0.0.0 connection address in sdp2, the flow will not work.
skipping to change at page 7, line 14 skipping to change at page 7, line 5
getting a different SDP, sdp5 , in the 200 OK from B. Then, the getting a different SDP, sdp5 , in the 200 OK from B. Then, the
controller needs to re-INVITE A again, and so on. The result is an controller needs to re-INVITE A again, and so on. The result is an
infinite loop of re-INVITEs. It is possible to break this cycle by infinite loop of re-INVITEs. It is possible to break this cycle by
having very smart UAs which can return the same SDP whenever having very smart UAs which can return the same SDP whenever
possible, or really smart controllers that can analyze the SDP to possible, or really smart controllers that can analyze the SDP to
determine if a re-INVITE is really needed. However, we wish to keep determine if a re-INVITE is really needed. However, we wish to keep
this mechanism simple, and avoid SDP awareness in the controller. As this mechanism simple, and avoid SDP awareness in the controller. As
a result, this flow is not really workable. It is therefore NOT a result, this flow is not really workable. It is therefore NOT
RECOMMENDED. RECOMMENDED.
4.3 Flow III 4.3. Flow III
A Controller B A Controller B
|(1) INVITE no SDP | | |(1) INVITE no SDP | |
|<---------------------| | |<---------------------| |
|(2) 200 offer1 | | |(2) 200 offer1 | |
|--------------------->| | |--------------------->| |
|(3) ACK answer1 (bh) | | |(3) ACK answer1 (bh) | |
|<---------------------| | |<---------------------| |
| |(4) INVITE no SDP | | |(4) INVITE no SDP |
| |--------------------->| | |--------------------->|
skipping to change at page 7, line 40 skipping to change at page 7, line 31
|--------------------->| | |--------------------->| |
| |(8) ACK answer2 | | |(8) ACK answer2 |
| |--------------------->| | |--------------------->|
|(9) ACK | | |(9) ACK | |
|<---------------------| | |<---------------------| |
|(10) RTP | | |(10) RTP | |
|.............................................| |.............................................|
Figure 3 Figure 3
A third flow, Flow III, is shown in Figure 3 A third flow, Flow III, is shown in Figure 3.
First, the controller sends an INVITE (1) to user A without any SDP First, the controller sends an INVITE (1) to user A without any SDP
(which is good, since it means that the controller doesn't need to (which is good, since it means that the controller doesn't need to
assume anything about the media composition of the session). A's assume anything about the media composition of the session). A's
phone rings. When A answers, a 200 OK is generated (2) containing its phone rings. When A answers, a 200 OK is generated (2) containing
offer, offer1. The controller generates an immediate ACK containing its offer, offer1. The controller generates an immediate ACK
an answer (3). This answer is a "black hole" SDP, with its connection containing an answer (3). This answer is a "black hole" SDP, with
address equal to 0.0.0.0. its connection address equal 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
B's phone to ring. When they answer, a 200 OK is sent, containing causes B's phone to ring. When they answer, a 200 OK is sent,
their offer, offer2 (5). This SDP is used to create a re-INVITE back containing their offer, offer2 (5). This SDP is used to create a
to A (6). That re-INVITE is based on offer2, but may need to be re-INVITE back to A (6). That re-INVITE is based on offer2, but may
reorganized to match up media lines, or to trim media lines. For need to be reorganized to match up media lines, or to trim media
example, if offer1 contained an audio and a video line, in that lines. For example, if offer1 contained an audio and a video line,
order, but offer2 contained just an audio line, the controller would in that order, but offer2 contained just an audio line, the
need to add a video line to the offer (setting its port to zero) to controller would need to add a video line to the offer (setting its
create offer2'. Since this is a re-INVITE, it should complete quickly port to zero) to create offer2'. Since this is a re-INVITE, it
in the general case. Thats good, since user B is retransmitting their should complete quickly in the general case. That's good, since user
200 OK, waiting for an ACK. The SDP in the 200 OK (7) from A, B is retransmitting their 200 OK, waiting for an ACK. The SDP in the
answer2', may also need to be reorganized or trimmed before sending 200 OK (7) from A, answer2', may also need to be reorganized or
it an the ACK to B (8) as answer2. Finally, an ACK is sent to A (9), trimmed before sending it an the ACK to B (8) as answer2. Finally,
and then media can flow. an ACK is sent to A (9), and then media can flow.
This flow has many benefits. First, it will usually operate without This flow has many benefits. First, it will usually operate without
any spurious retransmissions or timeouts (although this may still any spurious retransmissions or timeouts (although this may still
happen if a re-INVITE is not responded to quickly). Secondly, it does happen if a re-INVITE is not responded to quickly). Secondly, it
not require the controller to guess the media that will be used by does not require the controller to guess the media that will be used
the participants. by the participants.
There are some drawbacks. The controller does need to perform SDP There are some drawbacks. The controller does need to perform SDP
manipulations. Specifically, it must take some SDP, and generate manipulations. Specifically, it must take some SDP, and generate
another SDP which has the same media composition, but has connection another SDP which has the same media composition, but has connection
addresses equal to 0.0.0.0. This is needed for message 3. Secondly, addresses equal to 0.0.0.0. This is needed for message 3. Secondly,
it may need to reorder and trim on SDP X, so that its media lines it may need to reorder and trim SDP X, so that its media lines match
match up with those in some other SDP, Y. Thirdly, the offer from B up with those in some other SDP, Y. Thirdly, the offer from B
(offer2) may have no codecs or media streams in common with the offer (offer2) may have no codecs or media streams in common with the offer
from A (offer 1). The controller will need to detect this condition, from A (offer 1). The controller will need to detect this condition,
and terminate the call. Finally, the flow is far more complicated and terminate the call. Finally, the flow is far more complicated
than the simple and elegant Flow I (Figure 1). than the simple and elegant Flow I (Figure 1).
4.4 Flow IV 4.4. Flow IV
A Controller B A Controller B
|(1) INVITE offer1 | | |(1) INVITE offer1 | |
|no media | | |no media | |
|<---------------------| | |<---------------------| |
|(2) 200 answer1 | | |(2) 200 answer1 | |
|no media | | |no media | |
|--------------------->| | |--------------------->| |
|(3) ACK | | |(3) ACK | |
|<---------------------| | |<---------------------| |
skipping to change at page 9, line 32 skipping to change at page 9, line 4
|(7) 200 answer2' | | |(7) 200 answer2' | |
|--------------------->| | |--------------------->| |
| |(8) ACK answer2 | | |(8) ACK answer2 |
| |--------------------->| | |--------------------->|
|(9) ACK | | |(9) ACK | |
|<---------------------| | |<---------------------| |
|(10) RTP | | |(10) RTP | |
|.............................................| |.............................................|
Figure 4 Figure 4
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
alerted. When they answer the call, the 200 OK (2) has an answer with is alerted. When they answer the call, the 200 OK (2) has an answer
no media either. This is acknowledged by the controller (3). The flow with no media either. This is acknowledged by the controller (3).
from this point onwards is identical to Flow III. However, the The flow from this point onwards is identical to Flow III. However,
manipulations required to convert offer2 to offer2', and answer2' to the manipulations required to convert offer2 to offer2', and answer2'
answer2, are much simpler. Indeed, no media manipulations are needed to answer2, are much simpler. Indeed, no media manipulations are
at all. The only change that is needed is to modify the origin lines, needed at all. The only change that is needed is to modify the
so that the origin line in offer2' is valid based on the value in origin lines, so that the origin line in offer2' is valid based on
offer1 (validify requires that the version increments by one, and the value in offer1 (validity requires that the version increments by
that the other parameters remain unchanged). one, and 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 there is compatible media. If there is no media in common, whether there is compatible media. If there is no media in common,
the call can be terminated later with a BYE. However, the users will the call can be terminated later with a BYE. However, the users will
have already been alerted, resulting in user annoyance and possibly have already been alerted, resulting in user annoyance and possibly
resulting in billing events. resulting in billing events.
5. Recommendations 5. Recommendations
Flow I (Figure 1) represents the simplest and the most efficient Flow I (Figure 1) represents the simplest and the most efficient
flow. This flow SHOULD be used by a controller if it knows with flow. This flow SHOULD be used by a controller if it knows with
certainty that user B is actually an automata that will answer the certainty that user B is actually an automata that will answer the
call immediately. This is the case for devices such as media servers, call immediately. This is the case for devices such as media
conferencing servers, and messaging servers, for example. Since we servers, conferencing servers, and messaging servers, for example.
expect a great deal of third party call control to be to automata, Since we expect a great deal of third party call control to be to
special caseing this scenario is reasonable. automata, special casing in this scenario is reasonable.
For calls to unknown entities, or to entities known to represent For calls to unknown entities, or to entities known to represent
people, it is RECOMMENDED that Flow IV (Figure 4) be used for third people, it is RECOMMENDED that Flow IV (Figure 4) be used for third
party call control. Flow III MAY be used instead, but it provides no party call control. Flow III MAY be used instead, but it provides no
additional benefits over Flow IV. However, Flow II SHOULD NOT be additional benefits over Flow IV. However, Flow II SHOULD NOT be
used, because of the potential for infinite ping-ponging of used, because of the potential for infinite ping-ponging of re-
re-INVITEs. INVITEs.
Several of these flows use a ``black hole'' connection address of Several of these flows use a "black hole" connection address of
0.0.0.0. This is an IPV4 address with the property that packets sent 0.0.0.0. This is an IPv4 address with the property that packets sent
to it will never leave the host which sent them; they are just to it will never leave the host which sent them; they are just
discarded. Those flows are therefore specific to IPv4. For other discarded. Those flows are therefore specific to IPv4. For other
network or address types, an address with an equivalent property network or address types, an address with an equivalent property
SHOULD be used. SHOULD be used.
In most cases, including the recommended flow, user A will hear In most cases, including the recommended flows, user A will hear
silence while the call to B completes. This may not always be ideal. silence while the call to B completes. This may not always be ideal.
It can be remedied by connecting the caller to a music-on-hold source It can be remedied by connecting the caller to a music-on-hold source
while the call to B occurs. while the call to B occurs.
6. Error Handling 6. Error Handling
There are numerous error cases which merit discussion. There are numerous error cases which merit discussion.
With all of the call flows in Section 4, one call is established to With all of the call flows in Section 4, one call is established to
A, and then the controller attempts to establish a call to B. A, and then the controller attempts to establish a call to B.
skipping to change at page 11, line 31 skipping to change at page 11, line 4
| |(5) 180 | | |(5) 180 |
| |<---------------------| | |<---------------------|
|(6) INVITE offer2 | | |(6) INVITE offer2 | |
|--------------------->| | |--------------------->| |
|(7) 491 | | |(7) 491 | |
|<---------------------| | |<---------------------| |
|(8) ACK | | |(8) ACK | |
|--------------------->| | |--------------------->| |
Figure 5 Figure 5
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 to B, since it has an INVITE transaction pending with it. As a
result, the controller needs to reject the request. It is RECOMMENDED result, the controller needs to reject the request. It is
that a 491 response be used. The situation here is similar to the RECOMMENDED that a 491 response be used. The situation here is
glare condition described in [1], and thus the same error handling is similar to the glare condition described in [1], and thus the same
sensible. However, A is likely to retry its request (as a result of error handling is sensible. However, A is likely to retry its
the 491), and this may occur before the exchange with B is completed. request (as a result of the 491), and this may occur before the
In that case, the controller would respond with another 491. exchange with B is completed. In that case, the controller would
respond with another 491.
7. Continued Processing 7. 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
skipping to change at page 12, line 28 skipping to change at page 11, line 48
| |<------------------| | |<------------------|
Figure 6 Figure 6
Similarly, if it receives a re-INVITE from one of the participants, Similarly, if it receives a re-INVITE from one of the participants,
it can forward it to the other participant. Depending on which flow it can forward it to the other participant. Depending on which flow
was used, this may require some manipulation on the SDP before was used, this may require some manipulation on the SDP before
passing it on. passing it on.
However, the controller need not "proxy" the SIP messages received However, the controller need not "proxy" the SIP messages received
from one of the parties. Since it is a Back to Back User Agent from one of the parties. Since it is a Back-to-Back User Agent
(B2BUA), it can invoke any signaling mechanism on each dialog, as it (B2BUA), it can invoke any signaling mechanism on each dialog, as it
sees fit. For example, if the controller receives a BYE from A, it sees fit. For example, if the controller receives a BYE from A, it
can generate a new INVITE to a third party, C, and connect B to that can generate a new INVITE to a third party, C, and connect B to that
participant instead. A call flow for this is shown in Figure 7, participant instead. A call flow for this is shown in Figure 7,
assuming the case where C represents an end user, not an automata. assuming the case where C represents an end user, not an automata.
Note that it is just Flow IV. Note that it is just Flow IV.
A Controller B C A Controller B C
|(1) BYE | | | |(1) BYE | | |
|--------------->| | | |--------------->| | |
skipping to change at page 13, line 43 skipping to change at page 12, line 46
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. In many cases, the controller will be as the controller sees fit. In many cases, the controller will be
required to modify the SDP exchanged between the participants in required to modify the SDP exchanged between the participants in
order to affect these changes. In particular, the version number in order to affect these changes. In particular, the version number in
the SDP will need to be changed by the controller in certain cases. the SDP will need to be changed by the controller in certain cases.
If the controller should issue an SDP offer on its own (for example, If the controller should issue an SDP offer on its own (for example,
to place a call on hold), it will need to increment the version to place a call on hold), it will need to increment the version
number in the SDP offer. The other participant in the call will not number in the SDP offer. The other participant in the call will not
know that the controller has done this, and any subsequent offer it know that the controller has done this, and any subsequent offer it
generates will have the wrong version number as far as its peer is generates will have the wrong version number as far as its peer is
concerned. As a result, the controller will be required to modify the concerned. As a result, the controller will be required to modify
version number in SDP messages to match what the recipient is the version number in SDP messages to match what the recipient is
expecting. expecting.
It is important to point out that the call need not have been It is important to point out that the call need not have been
established by the controller in order for the processing of this established by the controller in order for the processing of this
section to be used. Rather, the controller could have acted as a section to be used. Rather, the controller could have acted as a
B2BUA during a call established by A towards B (or vice a versa). B2BUA during a call established by A towards B (or vice versa).
8. 3pcc and Early Media 8. 3pcc and Early Media
Early media represents the condition where the session is established Early media represents the condition where the session is established
(as a result of the completion of an offer/answer exchange), yet the (as a result of the completion of an offer/answer exchange), yet the
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.
A Controller B A Controller B
skipping to change at page 15, line 4 skipping to change at page 14, line 42
| |--------------------->| | |--------------------->|
| |(10) 200 PRACK | | |(10) 200 PRACK |
| |<---------------------| | |<---------------------|
|(11) RTP | | |(11) RTP | |
|.............................................| |.............................................|
| | |<answer> | | |<answer>
| |(12) 200 OK | | |(12) 200 OK |
| |<---------------------| | |<---------------------|
| |(13) ACK | | |(13) ACK |
| |--------------------->| | |--------------------->|
Figure 8 Figure 8
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 answering the call. The flow is almost identical to Flow IV from
Figure 4. The only difference is that user B generates a reliable Figure 4. The only difference is that user B generates a reliable
provisional response (5) [6] instead of a final response, and answer2 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 is carried in a PRACK (9) 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 (12), 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 (13) to confirm the dialog.
A Controller B A Controller B
| | | | | |
|(1) INVITE offer1 | | |(1) INVITE offer1 | |
|no media | | |no media | |
|<---------------------| | |<---------------------| |
| | | | | |
|ring | | |ring | |
| | | | | |
|(2) 183 answer1 | | |(2) 183 answer1 | |
skipping to change at page 15, line 40 skipping to change at page 15, line 30
| |(5) INVITE no SDP | | |(5) INVITE no SDP |
| |--------------------->| | |--------------------->|
| | |ring | | |ring
| | | | | |
| | |answer | | |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 | |
|.............................................| |.............................................|
| | |
|answer | |
| | |
|(11) 200 OK | | |(11) 200 OK | |
|--------------------->| | |--------------------->| |
|(12) ACK | | |(12) ACK | |
|<---------------------| | |<---------------------| |
Figure 9 Figure 9
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 resulting in a 200 OK (6) with an offer, offer2. The controller now
needs to update the session parameters with user A. However, since 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 the call has not been answered, it cannot use a re-INVITE. Rather,
uses a SIP UPDATE request (7) [7], passing the offer (after modifying it uses a SIP UPDATE request (7) [7], passing the offer (after
it to get the origin field correct). User A generates its answer in modifying it to get the origin field correct). User A generates its
the 200 OK to the UPDATE (8). This answer is passed to user B in the answer in the 200 OK to the UPDATE (8). This answer is passed to
ACK (9). When user A finally answers (11), there is no change in user B in the ACK (9). When user A finally answers (11), there is no
session state, so the controller simply ACKs the 200 OK (12). 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 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
no media streams. When user B answers, media can begin to flow. 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 However, any media sent to the gateway from the PSTN up to that point
will be lost. will be lost.
9. Third Party Call Control and SDP Preconditions 9. 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 specification relies on signaling and resource reservation [2]. This specification 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.
9.1 Controller Initiates 9.1. Controller Initiates
In one usage scenario, the controller wishes to make use of In one usage scenario, the controller wishes to make use of
preconditions in order to avoid the call failure scenarios documented preconditions in order to avoid the call failure scenarios documented
in Section 4.4. Specifically, the controller can use preconditions in in Section 4.4. Specifically, the controller can use preconditions in
order to guarantee that neither party is alerted unless there is a order to guarantee that neither party is alerted unless there is a
common set of media and codecs. It can also provide both parties with common set of media and codecs. It can also provide both parties
information on the media composition of the call before they decide with information on the media composition of the call before they
to accept it. decide to accept it.
User Controller Customer Service User A Controller Customer Service
(User B)
| | | | | |
|(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 |
| |------------------>| | |------------------>|
| | |<ring> | | |
| | | | | |
| | |<answer> | | |<answer>
| |(4) 200 OK answer1 | | |(4) 200 OK answer1 |
| |no precon | | |no precon |
| |<------------------| | |<------------------|
| |(5) ACK | | |(5) ACK |
| |------------------>| | |------------------>|
|(6) PRACK answer1 | | |(6) PRACK answer1 | |
|<------------------| | |<------------------| |
|<ring> | | |<ring> | |
skipping to change at page 17, line 40 skipping to change at page 17, line 40
|------------------>| | |------------------>| |
|<answer> | | |<answer> | |
| | | | | |
|(8) 200 INVITE | | |(8) 200 INVITE | |
|------------------>| | |------------------>| |
|(9) ACK | | |(9) ACK | |
|<------------------| | |<------------------| |
Figure 10 Figure 10
The flow for this scenario is shown in Figure 10. In this example, we The flow for this scenario is shown in Figure 10. In this example,
assume that user B is an automata or agent of some sort which will we assume that user B is an automata or agent of some sort which will
answer the call immediately. Therefore, the flow is based on Flow I. answer the call immediately. Therefore, the flow is based on Flow I.
The controller sends an INVITE to user A containing no SDP, but with The controller sends an INVITE to user A containing no SDP, but with
a Require header indicating that preconditions are required. This a Require header indicating that preconditions are required. This
specific scenario (an INVITE without an offer, but with a Require specific scenario (an INVITE without an offer, but with a Require
header indicating preconditions) is not described in [2]. It is header indicating preconditions) is not described in [2]. It is
RECOMMENDED that the UAS respond with an offer in a 1xx including the 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 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 preconditions it supports as optional. Of course, the user is not
alerted at this time. The controller takes this offer and passes it 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 to user B (3). User B does not support preconditions, or does, but
not interested in them. Therefore, when it answers the call, the 200 is not interested in them. Therefore, when it answers the call, the
OK contains an answer without any preconditions listed (4). This 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 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, 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 and therefore, it can alert the user. When the call is answered,
A sends a 200 OK to the controller (8) and the call is complete. user A sends a 200 OK to the controller (8) and the call is complete.
In the event that the offer generated by user A was not acceptable to 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 (because of non-overlapping codecs or media, for example),
user B would immediately reject the INVITE (message 3). The user B would immediately reject the INVITE (message 3). The
controller would then CANCEL the request to user A. In this controller would then CANCEL the request to user A. In this
situation, neither user A nor user B would have been alerted, situation, neither user A nor user B would have been alerted,
achieving the desired effect. It is interesting to note that this achieving the desired effect. It is interesting to note that this
property is achieved using preconditions even though it doesn't property is achieved using preconditions even though it doesn't
matter what specific types of preconditions are supported by user A. matter what specific types of preconditions are supported by user A.
It is also entirely possible that user B does actually desire It is also entirely possible that user B does actually desire
preconditions. In that case, it might generate a 1xx of its own with preconditions. In that case, it might generate a 1xx of its own with
an answer containing preconditions. That answer would still be passed an answer containing preconditions. That answer would still be
to user A, and both parties would proceed with whatever measures are passed to user A, and both parties would proceed with whatever
necessary to meet the preconditions. Neither user would be alerted measures are necessary to meet the preconditions. Neither user would
until the preconditions were met. be alerted until the preconditions were met.
9.2 Party A Initiates 9.2. Party A Initiates
In Section 9.1, the controller requested the use of preconditions to In Section 9.1, the controller requested the use of preconditions to
achieve a specific goal. It is also possible that the controller achieve a specific goal. It is also possible that the controller
doesn't care (or perhaps doesn't even know) about preconditions, but doesn't care (or perhaps doesn't even know) about preconditions, but
one of the participants in the call does care. A call flow for this one of the participants in the call does care. A call flow for this
case is shown in Figure 11. case is shown in Figure 11.
A Controller B A Controller B
|(1) INVITE offer1 | | |(1) INVITE offer1 | |
|no media | | |no media | |
skipping to change at page 21, line 28 skipping to change at page 21, line 25
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
the manipulation of the origin field, as required in Flow IV) in an 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 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). 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), Since the preconditions have been met, both sides ring (21 and 22),
and then both answer (23 and 25), completing the call. and then both answer (23 and 25), completing the call.
What is important about this flow is that the controller doesn't know What is important about this flow is that the controller doesn't know
anything about preconditions. It merely passes the SDP back and forth anything about preconditions. It merely passes the SDP back and
as needed. The trick is the usage of UPDATE and PRACK to pass the SDP forth as needed. The trick is the usage of UPDATE and PRACK to pass
when needed. That determination is made entirely based on the offer/ the SDP when needed. That determination is made entirely based on
answer rules described in [6] and [7], and is independent of the offer/answer rules described in [6] and [7], and is independent
preconditions. of preconditions.
10. Example Call Flows 10. Example Call Flows
10.1 Click to Dial 10.1. Click-to-Dial
The first application of this capability we discuss is 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 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. 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 The user clicks on a link, and a call is placed to a customer service
representative. When the representative picks up, the phone on the 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 the user pick up, the customer service
representative is there, ready to talk to the user. representative is there, ready to talk to the user.
Customer Service Controller Users Phone Users Browser Customer Service Controller User's Phone User's 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 22, line 35 skipping to change at page 22, line 35
|------------------>| | | |------------------>| | |
| |(10) ACK answer2 | | | |(10) ACK answer2 | |
| |------------------>| | | |------------------>| |
|(11) ACK | | | |(11) ACK | | |
|<------------------| | | |<------------------| | |
|(12) RTP | | | |(12) RTP | | |
|.......................................| | |.......................................| |
Figure 12 Figure 12
The call flow for this service is given in Figure 12. It is identical The call flow for this service is given in Figure 12. It is
to that of Figure 4, with the exception that the service is triggered identical to that of Figure 4, with the exception that the service is
through an http POST request when the user clicks on the link. triggered through an HTTP POST request when the user clicks on the
Normally, this POST request would contain neither the number of the link. Normally, this POST request would contain neither the number
user or of the customer service representative. The user's number of the user or of the customer service representative. The user's
would typically be obtained by web application from back-end number would typically be obtained by the web application from back-
databases, since the user would have presumably logged into the site, end databases, since the user would have presumably logged into the
giving the server the needed context. The customer service number site, giving the server the needed context. The customer service
would typically be obtained through provisioning. Thus, the HTTP POST number would typically be obtained through provisioning. Thus, the
is actually providing the server nothing more than an indication that HTTP POST is actually providing the server nothing more than an
a call is desired. indication that a call is desired.
We note that this service can be provided through other mechanisms, We note that this service can be provided through other mechanisms,
namely PINT [10]. However, there are numerous differences between the namely PINT [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 endpoints. o The PINT solution enables calls only between two PSTN endpoints.
The solution described here allows calls between PSTN phones The solution described here allows calls between PSTN phones
(through SIP enabled gateways) and native IP phones. (through SIP enabled gateways) and native IP phones.
o When used for calls between two PSTN phones, the solution here may o When used for calls between two PSTN phones, the solution here may
result in a portion of the call being routed over the Internet. In result in a portion of the call being routed over the Internet.
pint, the call is always routed only over the PSTN. This may In PINT, the call is always routed only over the PSTN. This may
result in better quality calls with the pint solution, depending result in better quality calls with the PINT solution, depending
on the codec in use and QoS capabilities of the network routing on the codec in use and QoS capabilities of the network routing
the Internet portion of the call. the Internet portion of the call.
o The PINT solution requires extensions to SIP (PINT is an extension o The PINT solution requires extensions to SIP (PINT is an extension
to SIP), whereas the solution described here is done with baseline to SIP), whereas the solution described here is done with baseline
SIP. SIP.
o The PINT solution allows the controller (acting as a PINT client) o The PINT solution allows the controller (acting as a PINT client)
to "step out" once the call is established. The solution described to "step out" once the call is established. The solution
here requires the controller to maintain call state for the entire described here requires the controller to maintain call state for
duration of the call. the entire duration of the call.
10.2 Mid-Call Announcement Capability 10.2. Mid-Call Announcement Capability
The third party call control mechanism described here can also be The third party call control mechanism described here can also be
used to enable mid-call announcements. Consider a service for used to enable mid-call announcements. Consider a service for pre-
pre-paid calling cards. Once the pre-paid call is established, the paid calling cards. Once the pre-paid call is established, the
system needs to set a timer to fire when they run out of minutes. system needs to set a timer to fire when they run out of minutes.
When this timer fires, we would like the user to hear an announcement When this timer fires, we would like the user to hear an announcement
which tells them to enter a credit card to continue. Once they enter which tells them to enter a credit card to continue. Once they enter
the credit card info, more money is added to the pre-paid card, and the credit card info, more money is added to the pre-paid card, and
the user is reconnected to the destination party. the user is reconnected to the destination party.
We consider here the usage of third party call control just for We consider here the usage of third party call control just for
playing the mid-call dialog to collect the credit card information. playing the mid-call dialog to collect the credit card information.
Pre-Paid User Controller Called Party Media Server Pre-Paid User Controller Called Party Media Server
skipping to change at page 24, line 35 skipping to change at page 24, line 49
| |------------------>| | | |------------------>| |
|(18) ACK | | | |(18) ACK | | |
|<------------------| | | |<------------------| | |
|(19) RTP | | | |(19) RTP | | |
|.......................................| | |.......................................| |
Figure 13 Figure 13
We assume the call is set up so that the controller is in the call as We assume the call is set up so that the controller is in the call as
a B2BUA. When the timer fires, we wish to connect the caller to a a B2BUA. When the timer fires, we wish to connect the caller to a
media server. The flow for this is shown in Figure 13. When the timer media server. The flow for this is shown in Figure 13. When the
expires, the controller places the called party with a connection timer expires, the controller places the called party with a
address of 0.0.0.0 (1). This effectively ``disconnects'' the called connection address of 0.0.0.0 (1). This effectively "disconnects"
party. The controller then sends an INVITE without SDP to the the the called party. The controller then sends an INVITE without SDP to
pre-paid caller (4). The offer returned from the caller (5) is used the pre-paid caller (4). The offer returned from the caller (5) is
in an INVITE to the media server which will be collecting digits (6). used in an INVITE to the media server which will be collecting digits
This is an instantiation of Flow I. This flow can only be used here (6). This is an instantiation of Flow I. This flow can only be used
because the media server is an automata, and will answer the INVITE here because the media server is an automata, and will answer the
immediately. If the controller was connecting the pre-paid user with INVITE immediately. If the controller was connecting the pre-paid
another end user, Flow III would need to be used. The media server user with another end user, Flow III would need to be used. The
returns an immediate 200 OK (7) with an answer, which is passed to media server returns an immediate 200 OK (7) with an answer, which is
the caller in an ACK (8). The result is that the media server and the passed to the caller in an ACK (8). The result is that the media
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
validated. The media server then passes the card number to the is validated. The media server then passes the card number to the
controller (using some means outside the scope of this controller (using some means outside the scope of this
specification), and then hangs up the call (11). specification), and then hangs up the call (11).
After hanging up with the media server, the controller reconnects the After hanging up with the media server, the controller reconnects the
user to the original called party. To do this, the controller sends user to the original called party. To do this, the controller sends
an INVITE without SDP to the called party (13). The 200 OK (14) an INVITE without SDP to the called party (13). The 200 OK (14)
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
the caller and called party are reconnected. point, the caller and called party are reconnected.
11. Implementation Recommendations 11. Implementation Recommendations
Most of the work involved in supporting third party call control is Most of the work involved in supporting third party call control is
within the controller. A standard SIP UA should be controllable using within the controller. A standard SIP UA should be controllable
the mechanisms described here. However, third party call control using the mechanisms described here. However, third party call
relies on a few features that might not be implemented. As such, we control relies on a few features that might not be implemented. As
RECOMMEND that implementors of user agent servers to support the such, we RECOMMEND that implementors of user agent servers support
following: the following:
o Offers and answers that contain a connection line with an address o Offers and answers that contain a connection line with an address
of 0.0.0.0. of 0.0.0.0.
o Re-invites that change the port to which media should be sent o Re-INVITE requests that change the port to which media should be
sent
o Re-invites that change the connection address
o Re-invites that add a media stream o Re-INVITEs that change the connection address
o Re-invites that remove a media stream (setting its port to zero) o Re-INVITEs that add a media stream
o Re-invites that add a codec amongst the set in a media stream o Re-INVITEs that remove a media stream (setting its port to zero)
o Re-INVITEs that add a codec amongst the set in a media stream
o SDP Connection address of zero o SDP Connection address of zero
o Initial invites with a connection address of zero o Initial INVITE requests with a connection address of zero
o Initial invites with no SDP o Initial INVITE requests with no SDP
o Initial invites with SDP but no media lines o Initial INVITE requests 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]. o Integration of resource management and SIP [2].
12. Security Considerations 12. Security Considerations
12.1 Authorization and Authentication 12.1. Authorization and Authentication
In most uses of SIP INVITE, whether or not a call is accepted is In most uses of SIP INVITE, whether or not a call is accepted is
based on a decision made by a human when presented information about based on a decision made by a human when presented information about
the call, such as the identity of the caller. In other cases, the call, such as the identity of the caller. In other cases,
automata answer the calls, and whether or not they do so may depend automata answer the calls, and whether or not they do so may depend
on the particular application to which SIP is applied. For example, on the particular application to which SIP is applied. For example,
if a caller makes a SIP call to a voice portal service, the call may if a caller makes a SIP call to a voice portal service, the call may
be rejected unless the caller has previously signed up (perhaps via a be rejected unless the caller has previously signed up (perhaps via a
web site). In other cases, call handling policies are made based on web site). In other cases, call handling policies are made based on
automated scripts, such as those desribed by the Call Processing automated scripts, such as those described by the Call Processing
Language [13]. Frequently, those decisions are also made based on the Language [11]. Frequently, those decisions are also made based on
identity of the caller. the identity of the caller.
These authorization mechanisms would be applied to normal first party These authorization mechanisms would be applied to normal first party
calls and third party calls, as these two are indistinguishable. As a calls and third party calls, as these two are indistinguishable. As
result, it is important for these authorization policies to continue a result, it is important for these authorization policies to
to operate correctly for third party calls. Of course, third party continue to operate correctly for third party calls. Of course,
calls introduce a new party - the one initiating the third party third party calls introduce a new party - the one initiating the
call. Do the authorization policies apply based on the identity of third party call. Do the authorization policies apply based on the
that third party, or do they apply based on the participants in the identity of that third party, or do they apply based on the
call? Ideally, the participants would be able to know the identities participants in the call? Ideally, the participants would be able to
of both other parties, and have authorization policies be based on know the identities of both other parties, and have authorization
those, as appropriate. However, this is not possible using existing policies be based on those, as appropriate. However, this is not
mechanisms. As a result, the next best thing is for the INVITE possible using existing mechanisms. As a result, the next best thing
requests to contain the identity of the third party. Ultimately, this is for the INVITE requests to contain the identity of the third
is the user who is requesting communication, and it makes sense for party. Ultimately, this is the user who is requesting communication,
call authorization policies to be based on that identity. and it makes sense for call authorization policies to be based on
that identity.
This requires, in turn, that the controller authenticate itself as This requires, in turn, that the controller authenticate itself as
that third party. This can be challenging, and the appropriate that third party. This can be challenging, and the appropriate
mechanism depends on the specific application scenario. mechanism depends on the specific application scenario.
In one common scenario, the controller is acting on behalf of one of 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, the participants in the call. A typical example is click-to-dial,
where the controller and the customer service representative are run where the controller and the customer service representative are run
by the same administrative domain. Indeed, for the purposes of by the same administrative domain. Indeed, for the purposes of
identification, the controller can legitimately claim to be the 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 (see RFC 3261 [1], Section 23) signed by the key of the using S/MIME (see RFC 3261 [1], Section 23) signed by the key of the
customer service rep (which is held by the controller) customer service rep (which is held by the controller).
This requires the controller to actually have credentials with which This requires the controller to actually have credentials with which
it can authenticate itself as the customer support representative. In it can authenticate itself as the customer support representative.
many other cases, the controller is representing one of the In many other cases, the controller is representing one of the
participants, but does not possess their credentials. Unfortunately, participants, but does not possess their credentials. Unfortunately,
there are currently no standardized mechanisms that allow a user to there are currently no standardized mechanisms that allow a user to
delegate credentials to the controller in a way that limits their delegate credentials to the controller in a way that limits their
usage to specific third party call control operations. In the absence usage to specific third party call control operations. In the
of such a mechanisms, the best that can be done is to use the display absence of such a mechanisms, the best that can be done is to use the
name in the From field to indicate the identity of the user on who's display name in the From field to indicate the identity of the user
behalf the call is being made. It is RECOMMENDED that the display on whose behalf the call is being made. It is RECOMMENDED that the
name be set to ``[controller] on behalf of [user]'', where user and display name be set to "[controller] on behalf of [user]", where user
controller are textual identities of the user and controller, and controller are textual identities of the user and controller,
respectively. In this case, the URI in the From field would identify respectively. In this case, the URI in the From field would identify
the controller. 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.
12.2 End-to-End Encryption and Integrity 12.2. End-to-End Encryption and Integrity
With third party call control, the controller is actually one of the With third party call control, the controller is actually one of the
participants as far as the SIP dialog is concerened. Therefore, participants as far as the SIP dialog is concerned. 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, integrity, authenticity and confidentiality of the media However, integrity, authenticity and confidentiality of the media
sessions can be provided through a controller. End-to-end media sessions can be provided through a controller. End-to-end media
security is based on the exchange of keying material within SDP [12]. security is based on the exchange of keying material within SDP [10].
The proper operation of these mechanisms with third party call
control depends on the controller behaving properly. So long as it is
not attempting to explicitly disable these mechanisms, the protocols
will properly operate between the participants, resulting in a secure
media session that even the controller cannot eavesdrop or modify.
Since third party call control is based on a model of trust between
the users and the controller, it is reasonable to assume it is
operating in a well-behaved manner. However, there is no
cryptographic means that can prevent the controller from interfering
with the initial exchanges of keying materials. As a result, it is
trivially possibly for the controller to insert itself as an
intermediary on the media exchange, if it should so desire.
13. IANA Considerations The proper operation of these mechanisms with third party call
There are no IANA considerations associated with this specification. control depends on the controller behaving properly. So long as it
is not attempting to explicitly disable these mechanisms, the
protocols will properly operate between the participants, resulting
in a secure media session that even the controller cannot eavesdrop
or modify. Since third party call control is based on a model of
trust between the users and the controller, it is reasonable to
assume it is operating in a well-behaved manner. However, there is
no cryptographic means that can prevent the controller from
interfering with the initial exchanges of keying materials. As a
result, it is trivially possibly for the controller to insert itself
as an intermediary on the media exchange, if it should so desire.
14. Acknowledgements 13. Acknowledgements
The authors would like to thank Paul Kyzivat, Rohan Mahy, Eric The authors would like to thank Paul Kyzivat, Rohan Mahy, Eric
Rescorla, Allison Mankin and Sriram Parameswar for their comments. Rescorla, Allison Mankin and Sriram Parameswar for their comments.
Normative References 14. References
14.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[2] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of [2] Camarillo, G., Ed., Marshall, W., Ed. and J. Rosenberg,
Resource Management and Session Initiation Protocol (SIP)", RFC "Integration of Resource Management and Session Initiation
3312, October 2002. Protocol (SIP)", RFC 3312, October 2002.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Schulzrinne, H., Oran, D. and G. Camarillo, "The Reason Header [5] Schulzrinne, H., Oran, D. and G. Camarillo, "The Reason Header
Field for the Session Initiation Protocol (SIP)", RFC 3326, Field for the Session Initiation Protocol (SIP)", RFC 3326,
December 2002. December 2002.
[6] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional [6] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262, June Responses in Session Initiation Protocol (SIP)", RFC 3262, June
2002. 2002.
[7] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE [7] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002. Method", RFC 3311, October 2002.
[8] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 14.2. Informative References
32, RFC 2606, June 1999.
Informative References
[9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, [8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC "RTP: A Transport Protocol for Real-Time Applications", RFC
3550, July 2003. 3550, July 2003.
[10] Petrack, S. and L. Conroy, "The PINT Service Protocol: [9] Petrack, S. and L. Conroy, "The PINT Service Protocol:
Extensions to SIP and SDP for IP Access to Telephone Call Extensions to SIP and SDP for IP Access to Telephone Call
Services", RFC 2848, June 2000. Services", RFC 2848, June 2000.
[11] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. [10] Andreasen, F., Baugher, M. and D. Wing, "SDP Security
Descriptions for Media Streams", Work in Progress, October 2003.
[12] Andreasen, F., Baugher, M. and D. Wing, "SDP Security
Descriptions for Media Streams",
draft-ietf-mmusic-sdescriptions-02 (work in progress), October
2003.
[13] Lennox, J., Wu, X. and H. Schulzrinne, "CPL: A Language for [11] Lennox, J., Wu, X. and H. Schulzrinne, "CPL: A Language for User
User Control of Internet Telephony Services", Control of Internet Telephony Services", Work in Progress,
draft-ietf-iptel-cpl-08 (work in progress), August 2003. August 2003.
Authors' Addresses 15. Authors' Addresses
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
Phone: +1 973 952-5000 Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
skipping to change at page 30, line 4 skipping to change at page 30, line 37
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
M/S 0401 M/S 0401
1214 Amsterdam Ave. 1214 Amsterdam Ave.
New York, NY 10027 New York, NY 10027
US US
EMail: schulzrinne@cs.columbia.edu EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs URI: http://www.cs.columbia.edu/~hgs
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Advanced Signalling Research Lab Ericsson
FIN-02420 Jorvas Hirsalantie 11
Jorvas 02420
Finland Finland
EMail: Gonzalo.Camarillo@ericsson.com EMail: Gonzalo.Camarillo@ericsson.com
Intellectual Property Statement 16. Full Copyright 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 Copyright (C) The Internet Society (2004). This document is subject
copyrights, patents or patent applications, or other proprietary to the rights, licenses and restrictions contained in BCP 78 and
rights which may cover technology that may be required to practice except as set forth therein, the authors retain all their rights.
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright (C) The Internet Society (2003). All Rights Reserved. Intellectual Property
This document and translations of it may be copied and furnished to The IETF takes no position regarding the validity or scope of any
others, and derivative works that comment on or otherwise explain it Intellectual Property Rights or other rights that might be claimed
or assist in its implementation may be prepared, copied, published to pertain to the implementation or use of the technology
and distributed, in whole or in part, without restriction of any described in this document or the extent to which any license
kind, provided that the above copyright notice and this paragraph are under such rights might or might not be available; nor does it
included on all such copies and derivative works. However, this represent that it has made any independent effort to identify any
document itself may not be modified in any way, such as by removing such rights. Information on the procedures with respect to
the copyright notice or references to the Internet Society or other rights in RFC documents can be found in BCP 78 and BCP 79.
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copies of IPR disclosures made to the IETF Secretariat and any
revoked by the Internet Society or its successors or assignees. assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
This document and the information contained herein is provided on an The IETF invites any interested party to bring to its attention
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING any copyrights, patents or patent applications, or other
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING proprietary rights that may cover technology that may be required
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION to implement this standard. Please address the information to the
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF IETF at ietf-ipr@ietf.org.
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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