draft-ietf-sipping-cc-framework-03.txt   draft-ietf-sipping-cc-framework-04.txt 
SIPPING WG R. Mahy SIPPING WG R. Mahy
Internet-Draft Cisco Systems Internet-Draft Airespace
Expires: April 26, 2004 B. Campbell Expires: August 2, 2005 B. Campbell
Estacado Systems
R. Sparks R. Sparks
XTen
J. Rosenberg J. Rosenberg
dynamicsoft Cisco Systems
D. Petrie D. Petrie
Pingtel Pingtel
A. Johnston A. Johnston
WorldCom MCI
October 27, 2003 Feb 2005
A Call Control and Multi-party usage framework for the Session A Call Control and Multi-party usage framework for the Session
Initiation Protocol (SIP) Initiation Protocol (SIP)
draft-ietf-sipping-cc-framework-03.txt draft-ietf-sipping-cc-framework-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2004. This Internet-Draft will expire on August 2, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005).
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document defines a framework and requirements for multi-party This document defines a framework and requirements for multi-party
usage of SIP. To enable discussion of multi-party features and usage of SIP. To enable discussion of multi-party features and
applications we define an abstract call model for describing the applications we define an abstract call model for describing the
media relationships required by many of these. The model and actions media relationships required by many of these. The model and actions
described here are specifically chosen to be independent of the SIP described here are specifically chosen to be independent of the SIP
signaling and/or mixing approach chosen to actually setup the media signaling and/or mixing approach chosen to actually setup the media
relationships. In addition to its dialog manipulation aspect, this relationships. In addition to its dialog manipulation aspect, this
framework includes requirements for communicating related information framework includes requirements for communicating related information
and events such as conference and session state, and session history. and events such as conference and session state, and session history.
This framework also describes other goals which embody the spirit of This framework also describes other goals which embody the spirit of
SIP applications as used on the Internet. SIP applications as used on the Internet.
Table of Contents Table of Contents
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation and Background . . . . . . . . . . . . . . . . 4 2. Motivation and Background . . . . . . . . . . . . . . . . . 4
3. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . 6 3. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 "Conversation Space" Model . . . . . . . . . . . . . . . . 6 3.1 "Conversation Space" Model . . . . . . . . . . . . . . . . 6
3.2 Comparison with Related Definitions . . . . . . . . . . . 7 3.2 Comparison with Related Definitions . . . . . . . . . . . 7
3.3 Signaling Models . . . . . . . . . . . . . . . . . . . . . 8 3.3 Signaling Models . . . . . . . . . . . . . . . . . . . . . 8
3.4 Mixing Models . . . . . . . . . . . . . . . . . . . . . . 9 3.4 Mixing Models . . . . . . . . . . . . . . . . . . . . . . 9
3.4.1 Tightly Coupled . . . . . . . . . . . . . . . . . . . . . 10 3.4.1 Tightly Coupled . . . . . . . . . . . . . . . . . . . 9
3.4.2 Loosely Coupled . . . . . . . . . . . . . . . . . . . . . 11 3.4.2 Loosely Coupled . . . . . . . . . . . . . . . . . . . 10
3.5 Conveying Information and Events . . . . . . . . . . . . . 12 3.5 Conveying Information and Events . . . . . . . . . . . . . 11
3.6 Componentization and Decomposition . . . . . . . . . . . . 13 3.6 Componentization and Decomposition . . . . . . . . . . . . 13
3.6.1 Media Intermediaries . . . . . . . . . . . . . . . . . . . 14 3.6.1 Media Intermediaries . . . . . . . . . . . . . . . . . 13
3.6.2 Mixer . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.6.2 Mixer . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6.3 Transcoder . . . . . . . . . . . . . . . . . . . . . . . . 14 3.6.3 Transcoder . . . . . . . . . . . . . . . . . . . . . . 14
3.6.4 Media Relay . . . . . . . . . . . . . . . . . . . . . . . 15 3.6.4 Media Relay . . . . . . . . . . . . . . . . . . . . . 14
3.6.5 Queue Server . . . . . . . . . . . . . . . . . . . . . . . 15 3.6.5 Queue Server . . . . . . . . . . . . . . . . . . . . . 14
3.6.6 Parking Place . . . . . . . . . . . . . . . . . . . . . . 15 3.6.6 Parking Place . . . . . . . . . . . . . . . . . . . . 14
3.6.7 Announcements and Voice Dialogs . . . . . . . . . . . . . 15 3.6.7 Announcements and Voice Dialogs . . . . . . . . . . . 15
3.7 Use of URIs . . . . . . . . . . . . . . . . . . . . . . . 17 3.7 Use of URIs . . . . . . . . . . . . . . . . . . . . . . . 16
3.7.1 Naming Users in SIP . . . . . . . . . . . . . . . . . . . 18 3.7.1 Naming Users in SIP . . . . . . . . . . . . . . . . . 17
3.7.2 Naming Services with SIP URIs . . . . . . . . . . . . . . 19 3.7.2 Naming Services with SIP URIs . . . . . . . . . . . . 18
3.8 Invoker Independence . . . . . . . . . . . . . . . . . . . 22 3.8 Invoker Independence . . . . . . . . . . . . . . . . . . . 22
3.9 Billing issues . . . . . . . . . . . . . . . . . . . . . . 23 3.9 Billing issues . . . . . . . . . . . . . . . . . . . . . . 23
4. Catalog of call control actions and sample features . . . 23 4. Catalog of call control actions and sample features . . . . 23
4.1 Early Dialog Actions . . . . . . . . . . . . . . . . . . . 24 4.1 Early Dialog Actions . . . . . . . . . . . . . . . . . . . 24
4.1.1 Remote Answer . . . . . . . . . . . . . . . . . . . . . . 24 4.1.1 Remote Answer . . . . . . . . . . . . . . . . . . . . 24
4.1.2 Remote Forward or Put . . . . . . . . . . . . . . . . . . 24 4.1.2 Remote Forward or Put . . . . . . . . . . . . . . . . 24
4.1.3 Remote Busy or Error Out . . . . . . . . . . . . . . . . . 24 4.1.3 Remote Busy or Error Out . . . . . . . . . . . . . . . 24
4.2 Single Dialog Actions . . . . . . . . . . . . . . . . . . 24 4.2 Single Dialog Actions . . . . . . . . . . . . . . . . . . 24
4.2.1 Remote Dial . . . . . . . . . . . . . . . . . . . . . . . 25 4.2.1 Remote Dial . . . . . . . . . . . . . . . . . . . . . 24
4.2.2 Remote On and Off Hold . . . . . . . . . . . . . . . . . . 25 4.2.2 Remote On and Off Hold . . . . . . . . . . . . . . . . 25
4.2.3 Remote Hangup . . . . . . . . . . . . . . . . . . . . . . 25 4.2.3 Remote Hangup . . . . . . . . . . . . . . . . . . . . 25
4.3 Multi-dialog actions . . . . . . . . . . . . . . . . . . . 25 4.3 Multi-dialog actions . . . . . . . . . . . . . . . . . . . 25
4.3.1 Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.3.1 Transfer . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.2 Take . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.3.2 Take . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.3 Add . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3.3 Add . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.4 Local Join . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3.4 Local Join . . . . . . . . . . . . . . . . . . . . . . 27
4.3.5 Insert . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3.5 Insert . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.6 Split . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3.6 Split . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.7 Near-fork . . . . . . . . . . . . . . . . . . . . . . . . 28 4.3.7 Near-fork . . . . . . . . . . . . . . . . . . . . . . 27
4.3.8 Far fork . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.3.8 Far fork . . . . . . . . . . . . . . . . . . . . . . . 28
5. Security Considerations . . . . . . . . . . . . . . . . . 28 5. Security Considerations . . . . . . . . . . . . . . . . . . 28
6. Appendix A: Example Features . . . . . . . . . . . . . . . 29 6. Appendix A: Example Features . . . . . . . . . . . . . . . . 29
6.1 Implementation of these features . . . . . . . . . . . . . 33 6.1 Implementation of these features . . . . . . . . . . . . . 33
6.1.1 Call Park . . . . . . . . . . . . . . . . . . . . . . . . 34 6.1.1 Call Park . . . . . . . . . . . . . . . . . . . . . . 33
6.1.2 Call Pickup . . . . . . . . . . . . . . . . . . . . . . . 34 6.1.2 Call Pickup . . . . . . . . . . . . . . . . . . . . . 34
6.1.3 Music on Hold . . . . . . . . . . . . . . . . . . . . . . 34 6.1.3 Music on Hold . . . . . . . . . . . . . . . . . . . . 34
6.1.4 Call Monitoring . . . . . . . . . . . . . . . . . . . . . 35 6.1.4 Call Monitoring . . . . . . . . . . . . . . . . . . . 34
6.1.5 Barge-in . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.1.5 Barge-in . . . . . . . . . . . . . . . . . . . . . . . 35
6.1.6 Intercom . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.1.6 Intercom . . . . . . . . . . . . . . . . . . . . . . . 35
6.1.7 Speakerphone paging . . . . . . . . . . . . . . . . . . . 35 6.1.7 Speakerphone paging . . . . . . . . . . . . . . . . . 35
6.1.8 Distinctive ring . . . . . . . . . . . . . . . . . . . . . 36 6.1.8 Distinctive ring . . . . . . . . . . . . . . . . . . . 35
6.1.9 Voice message screening . . . . . . . . . . . . . . . . . 36 6.1.9 Voice message screening . . . . . . . . . . . . . . . 36
6.1.10 Single Line Extension . . . . . . . . . . . . . . . . . . 36 6.1.10 Single Line Extension . . . . . . . . . . . . . . . 36
6.1.11 Click-to-dial . . . . . . . . . . . . . . . . . . . . . . 36 6.1.11 Click-to-dial . . . . . . . . . . . . . . . . . . . 36
6.1.12 Pre-paid calling . . . . . . . . . . . . . . . . . . . . . 37 6.1.12 Pre-paid calling . . . . . . . . . . . . . . . . . . 36
6.1.13 Voice Portal . . . . . . . . . . . . . . . . . . . . . . . 37 6.1.13 Voice Portal . . . . . . . . . . . . . . . . . . . . 37
Normative References . . . . . . . . . . . . . . . . . . . 38 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
Informational References . . . . . . . . . . . . . . . . . 40 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 40 7.2 Informational References . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . 41
1. Conventions 1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [2]. document are to be interpreted as described in RFC-2119 [2].
2. Motivation and Background 2. Motivation and Background
The Session Initiation Protocol [1] (SIP) was defined for the The Session Initiation Protocol [1] (SIP) was defined for the
skipping to change at page 5, line 21 skipping to change at page 5, line 17
o Mixing Model independent: The bulk of interesting multiparty o Mixing Model independent: The bulk of interesting multiparty
applications involve mixing or combining media from multiple applications involve mixing or combining media from multiple
participants. This mixing can be performed by one or more of the participants. This mixing can be performed by one or more of the
participants, or by a centralized mixing resource. The experience participants, or by a centralized mixing resource. The experience
of the participants should not depend on the mixing model used. of the participants should not depend on the mixing model used.
While most examples in this document refer to audio mixing, the While most examples in this document refer to audio mixing, the
framework applies to any media type. In this context a "mixer" framework applies to any media type. In this context a "mixer"
refers to combining media in an appropriate, media-specific way. refers to combining media in an appropriate, media-specific way.
This is consistent with model described in the SIP conferencing This is consistent with model described in the SIP conferencing
framework. framework.
o Invoker oriented. Only the user who invokes a feature or a
o Invoker oriented. Only the user who invokes a feature or a service service needs to know exactly which service is invoked or why.
needs to know exactly which service is invoked or why. This is This is good because it allows new services to be created without
good because it allows new services to be created without
requiring new primitives from all the participants; and it allows requiring new primitives from all the participants; and it allows
for much simpler feature authorization policies, for example, when for much simpler feature authorization policies, for example, when
participation spans organizational boundaries. As discussed in participation spans organizational boundaries. As discussed in
section 3.8, this also avoids exponential state explosion when section 3.8, this also avoids exponential state explosion when
combining features. The invoker only has to manage a user combining features. The invoker only has to manage a user
interface or API to prevent local feature interactions. All the interface or API to prevent local feature interactions. All the
other participants simply need to manage the feature interactions other participants simply need to manage the feature interactions
of a much smaller number of primitives. of a much smaller number of primitives.
o Primitives make full use of URIs. URIs are a very powerful o Primitives make full use of URIs. URIs are a very powerful
mechanism for describing users and services. They represent a mechanism for describing users and services. They represent a
plentiful resource which can be extremely expressive and easily plentiful resource which can be extremely expressive and easily
routed, translated, and manipulated--even across organizational routed, translated, and manipulated--even across organizational
boundaries. URIs can contain special parameters and informational boundaries. URIs can contain special parameters and informational
headers which need only be relevant to the owner of the namespace headers which need only be relevant to the owner of the namespace
(domain) of the URI. Just as a user who selects an http: URL need (domain) of the URI. Just as a user who selects an http: URL need
not understand the significance and organization of the web site not understand the significance and organization of the web site
it references, a user may encounter a SIP URL which translates it references, a user may encounter a SIP URL which translates
into an email-style group alias, which plays a pre-recorded into an email-style group alias, which plays a pre-recorded
skipping to change at page 9, line 48 skipping to change at page 9, line 19
o Ask another UA to send a request on your behalf o Ask another UA to send a request on your behalf
Many of the features, primitives, and actions described in this Many of the features, primitives, and actions described in this
document also require some type of media mixing, combining, or document also require some type of media mixing, combining, or
selection as described in the next section. selection as described in the next section.
3.4 Mixing Models 3.4 Mixing Models
SIP permits a variety of mixing models, which are discussed here SIP permits a variety of mixing models, which are discussed here
briefly. This topic is discussed more thoroughly in the SIP briefly. This topic is discussed more thoroughly in the SIP
conferencing framework [15] and cc-conferencing [20]. SIP supports conferencing framework [15] and cc-conferencing [19]. SIP supports
both tightly-coupled and loosely-coupled conferencing, although more both tightly-coupled and loosely-coupled conferencing, although more
sophisticated behavior is available in tightly-coupled conferences. sophisticated behavior is available in tightly-coupled conferences.
In a tightly-coupled conference, a single SIP user agent (called the In a tightly-coupled conference, a single SIP user agent (called the
focus) has a direct dialog relationship with each participant (and focus) has a direct dialog relationship with each participant (and
may control non participant user agents as well). In a may control non participant user agents as well). In a
loosely-coupled conference there is no coordinated signaling loosely-coupled conference there is no coordinated signaling
relationships among the participants. relationships among the participants.
For brevity, only the two most popular conferencing models are For brevity, only the two most popular conferencing models are
significantly discussed in this document (local and centralized significantly discussed in this document (local and centralized
skipping to change at page 10, line 44 skipping to change at page 10, line 15
completely separate SIP call. This call uses a different Call-ID, completely separate SIP call. This call uses a different Call-ID,
different tags, etc. There is no call set up directly between B and different tags, etc. There is no call set up directly between B and
C. No SIP extension or external signaling is needed. A merely C. No SIP extension or external signaling is needed. A merely
decides to locally join two call-legs. decides to locally join two call-legs.
B C B C
\ / \ /
\ / \ /
A A
A receives media streams from both B and C, and mixes them. A sends a A receives media streams from both B and C, and mixes them. A sends
stream containing A's and C's streams to B, and a stream containing a stream containing A's and C's streams to B, and a stream containing
A's and B's streams to C. Basically, user A handles both signaling A's and B's streams to C. Basically, user A handles both signaling
and media mixing. and media mixing.
3.4.1.2 Centralized Mixing 3.4.1.2 Centralized Mixing
In a centralized mixing model, all participants have a pairwise SIP In a centralized mixing model, all participants have a pairwise SIP
and media relationship with the mixer. Common applications of and media relationship with the mixer. Common applications of
centralized mixing include ad-hoc conferences and scheduled dial-in centralized mixing include ad-hoc conferences and scheduled dial-in
or dial-out conferences. [need diagram] or dial-out conferences. [need diagram]
3.4.1.3 Centralized Signaling, Distributed Media 3.4.1.3 Centralized Signaling, Distributed Media
In this conferencing model, there is a centralized controller, as in In this conferencing model, there is a centralized controller, as in
the dial-in and dial-out cases. However, the centralized server the dial-in and dial-out cases. However, the centralized server
handles signaling only. The media is still sent directly between handles signaling only. The media is still sent directly between
participants, using either multicast or multi-unicast. Multi-unicast participants, using either multicast or multi-unicast. Multi-unicast
is when a user sends multiple packets (one for each recipient, is when a user sends multiple packets (one for each recipient,
addressed to that recipient). This is referred to as a "Decentralized addressed to that recipient). This is referred to as a
Multipoint Conference" in [H.323]. "Decentralized Multipoint Conference" in [H.323].
3.4.2 Loosely Coupled 3.4.2 Loosely Coupled
In these models, there is no point of central control of SIP In these models, there is no point of central control of SIP
signaling. As in the "Centralized Signaling, Distributed Media" case signaling. As in the "Centralized Signaling, Distributed Media" case
above, all endpoints send media to all other endpoints. Consequently above, all endpoints send media to all other endpoints. Consequently
every endpoint mixes their own media from all the other sources, and every endpoint mixes their own media from all the other sources, and
sends their own media to every other participant. [add diagrams] sends their own media to every other participant. [add diagrams]
3.4.2.1 Large-Scale Multicast Conferences 3.4.2.1 Large-Scale Multicast Conferences
skipping to change at page 14, line 44 skipping to change at page 14, line 14
useful, fundamental service; without getting in the way of new useful, fundamental service; without getting in the way of new
features implemented by participants. Some common media features implemented by participants. Some common media
intermediaries are desribed below. intermediaries are desribed below.
3.6.2 Mixer 3.6.2 Mixer
A SIP mixer is a component that combines media from all dialogs in A SIP mixer is a component that combines media from all dialogs in
the same conversation in a media specific way. For example, the the same conversation in a media specific way. For example, the
default combining for an audio conference might be an N-1 default combining for an audio conference might be an N-1
configuration, while a text mixer might interleave text messages on a configuration, while a text mixer might interleave text messages on a
per-line basis. More details about the media policy used by mixers per-line basis. More details about how to manipulate the media
is described in media policy manipulation in the conference policy policy used by mixers is being discussed in the XCON Working Group.
control protocol [17].
3.6.3 Transcoder 3.6.3 Transcoder
A transcoder translates media from one encoding or format to another A transcoder translates media from one encoding or format to another
(for example, GSM voice to G.711, MPEG2 to H.261, or text/html to (for example, GSM voice to G.711, MPEG2 to H.261, or text/html to
text/plain), or from one media type to another (for example text to text/plain), or from one media type to another (for example text to
speech). A more thorough discussion of transcoding is described in speech). A more thorough discussion of transcoding is described in
SIP transcoding services invocation [18]. SIP transcoding services invocation [17].
3.6.4 Media Relay 3.6.4 Media Relay
A media relay terminates media and simply forwards it to a new A media relay terminates media and simply forwards it to a new
destination without changing the content in any way. Sometimes media destination without changing the content in any way. Sometimes media
relays are used to provide source IP address anonymity, to facilitate relays are used to provide source IP address anonymity, to facilitate
middlebox traversal, or to provide a trusted entity where media can middlebox traversal, or to provide a trusted entity where media can
be forcefully disconnected. be forcefully disconnected.
3.6.5 Queue Server 3.6.5 Queue Server
skipping to change at page 16, line 23 skipping to change at page 15, line 40
3.6.7.1 Text-to-Speech and Automatic Speech Recognition 3.6.7.1 Text-to-Speech and Automatic Speech Recognition
Text-to-Speech (TTS) is a service which converts text into digitized Text-to-Speech (TTS) is a service which converts text into digitized
audio. TTS is frequently integrated into other applications, but audio. TTS is frequently integrated into other applications, but
when separated as a component, it provides greater opportunity for when separated as a component, it provides greater opportunity for
broad reuse. Automatic Speech Recognition (ASR) is a service which broad reuse. Automatic Speech Recognition (ASR) is a service which
attempts to decipher digitized speech based on a proposed grammar. attempts to decipher digitized speech based on a proposed grammar.
Like TTS, ASR services can be embedded, or exposed so that many Like TTS, ASR services can be embedded, or exposed so that many
applications can take advantage of such services. A standardized applications can take advantage of such services. A standardized
(decomposed) interface to access standalone TTS and ASR services is (decomposed) interface to access standalone TTS and ASR services is
currently being developed in the SPEECHSC Workin Group. currently being developed in the SPEECHSC Working Group.
3.6.7.2 VoiceXML 3.6.7.2 VoiceXML
[VoiceXML] is a W3C recommendation that was designed to give authors [VoiceXML] is a W3C recommendation that was designed to give authors
control over the spoken dialog between users and applications. The control over the spoken dialog between users and applications. The
application and user take turns speaking: the application prompts the application and user take turns speaking: the application prompts the
user, and the user in turn responds. Its major goal is to bring the user, and the user in turn responds. Its major goal is to bring the
advantages of web-based development and content delivery to advantages of web-based development and content delivery to
interactive voice response applications. We believe that VoiceXML interactive voice response applications. We believe that VoiceXML
represents the ideal partner for SIP in the development of represents the ideal partner for SIP in the development of
skipping to change at page 18, line 25 skipping to change at page 17, line 43
that points to a domain with a location server that can map the URI that points to a domain with a location server that can map the URI
to set of Contact URIs where the user might be available. Typically to set of Contact URIs where the user might be available. Typically
the Contact URIs are populated via registration. the Contact URIs are populated via registration.
Address of Record Contacts Address of Record Contacts
sip:bob@biloxi.com -> sip:bob@babylon.biloxi.com:5060 sip:bob@biloxi.com -> sip:bob@babylon.biloxi.com:5060
sip:bbrown@mailbox.provider.net sip:bbrown@mailbox.provider.net
sip:+1.408.555.6789@mobile.net sip:+1.408.555.6789@mobile.net
Callee Capabilities [21] defines a set of additional parameters to Callee Capabilities [20] defines a set of additional parameters to
the Contact header that define the characteristics of the user agent the Contact header that define the characteristics of the user agent
at the specified URI. For example, there is a mobility parameter at the specified URI. For example, there is a mobility parameter
which indicates whether the UA is fixed or mobile. When a user agent which indicates whether the UA is fixed or mobile. When a user agent
registers, it places these parameters in the Contact headers to registers, it places these parameters in the Contact headers to
characterize the URIs it is registering. This allows a proxy for characterize the URIs it is registering. This allows a proxy for
that domain to have information about the contact addresses for that that domain to have information about the contact addresses for that
user. user.
When a caller sends a request, it can optionally request Caller When a caller sends a request, it can optionally request Caller
Preferences [22], by including the Accept-Contact and Reject-Contact Preferences [21], by including the Accept-Contact and Reject-Contact
headers which request certain handling by the proxy in the target headers which request certain handling by the proxy in the target
domain. These headers contain preferences that describe the set of domain. These headers contain preferences that describe the set of
desired URIs to which the caller would like their request routed. desired URIs to which the caller would like their request routed.
The proxy in the target domain matches these preferences with the The proxy in the target domain matches these preferences with the
Contact characteristics originally registered by the target user. Contact characteristics originally registered by the target user.
The target user can also choose to run arbitrarily complex "Find-me" The target user can also choose to run arbitrarily complex "Find-me"
feature logic on a proxy in the target domain. feature logic on a proxy in the target domain.
There is a strong asymmetry in how preferences for callers and There is a strong asymmetry in how preferences for callers and
callees can be presented to the network. While a caller takes an callees can be presented to the network. While a caller takes an
skipping to change at page 20, line 13 skipping to change at page 19, line 30
media services URIs are not readily distinguishable from other types media services URIs are not readily distinguishable from other types
of SIP UA's. The use of a service namespace provides a mechanism to of SIP UA's. The use of a service namespace provides a mechanism to
unambiguously identify standard interfaces while not constraining unambiguously identify standard interfaces while not constraining
the development of private or experimental services. the development of private or experimental services.
In SIP, the request-URI identifies the user or service that the call In SIP, the request-URI identifies the user or service that the call
is destined for. The great advantage of using URIs (specifically, is destined for. The great advantage of using URIs (specifically,
the SIP request URI) as a service identifier comes because of the the SIP request URI) as a service identifier comes because of the
combination of two facts. First, unlike in the PSTN, where the combination of two facts. First, unlike in the PSTN, where the
namespace (dialable telephone numbers) are limited, URIs come from an namespace (dialable telephone numbers) are limited, URIs come from an
infinite space. They are plentiful, and they are free. Secondly, the infinite space. They are plentiful, and they are free. Secondly,
primary function of SIP is call routing through manipulations of the the primary function of SIP is call routing through manipulations of
request URI. In the traditional SIP application, this URI represents the request URI. In the traditional SIP application, this URI
people. However, the URI can also represent services, as we propose represents people. However, the URI can also represent services, as
here. This means we can apply the routing services SIP provides to we propose here. This means we can apply the routing services SIP
routing of calls to services. The result - the problem of service provides to routing of calls to services. The result - the problem
invocation and service location becomes a routing problem, for which of service invocation and service location becomes a routing problem,
SIP provides a scalable and flexible solution. Since there is such a for which SIP provides a scalable and flexible solution. Since there
vast namespace of services, we can explicitly name each service in a is such a vast namespace of services, we can explicitly name each
finely granular way. This allows the distribution of services across service in a finely granular way. This allows the distribution of
the network. services across the network.
Consider a conferencing service, where we have separated the names of Consider a conferencing service, where we have separated the names of
ad-hoc conferences from scheduled conferences, we can program proxies ad-hoc conferences from scheduled conferences, we can program proxies
to route calls for ad-hoc conferences to one set of servers, and to route calls for ad-hoc conferences to one set of servers, and
calls for scheduled ones to another, possibly even in a different calls for scheduled ones to another, possibly even in a different
provider. In fact, since each conference itself is given a URI, we provider. In fact, since each conference itself is given a URI, we
can distribute conferences across servers, and easily guarantee that can distribute conferences across servers, and easily guarantee that
calls for the same conference always get routed to the same server. calls for the same conference always get routed to the same server.
This is in stark contrast to conferences in the telephone network, This is in stark contrast to conferences in the telephone network,
where the equivalent of the URI - the phone number - is scarce. An where the equivalent of the URI - the phone number - is scarce. An
skipping to change at page 20, line 45 skipping to change at page 20, line 13
Conference IDs must be obtained through IVR interactions with the Conference IDs must be obtained through IVR interactions with the
caller, or through a human attendant. This makes it difficult to caller, or through a human attendant. This makes it difficult to
distribute conferences across servers all over the network, since the distribute conferences across servers all over the network, since the
PSTN routing only knows about the dialed number. PSTN routing only knows about the dialed number.
In the case of a dialog server, the voice dialog itself is the target In the case of a dialog server, the voice dialog itself is the target
for the call. As such, the request URI should contain the identifier for the call. As such, the request URI should contain the identifier
for this spoken dialog. This is consistent with the Request-URI for this spoken dialog. This is consistent with the Request-URI
service invocation model of RFC 3087. This URL can be in one of two service invocation model of RFC 3087. This URL can be in one of two
formats. In the first, the VoiceXML script is identified directly by formats. In the first, the VoiceXML script is identified directly by
an HTTP URL. In the second, the script is not specified. Rather, the an HTTP URL. In the second, the script is not specified. Rather,
dialog server uses its configuration to map the incoming request to a the dialog server uses its configuration to map the incoming request
specific script. to a specific script.
Since the request URI could indicate a request for a variety of Since the request URI could indicate a request for a variety of
different services, of which a dialog server is only one type, this different services, of which a dialog server is only one type, this
example request URI first begins with a service identifier, that example request URI first begins with a service identifier, that
indicates the basic service required. For VoiceXML scripts, this indicates the basic service required. For VoiceXML scripts, this
identification information is a URL-encoded version of the URL which identification information is a URL-encoded version of the URL which
references the script to execute, or if not present, the dialog references the script to execute, or if not present, the dialog
server uses server-specific configuration to determine which script server uses server-specific configuration to determine which script
to execute. to execute.
skipping to change at page 24, line 29 skipping to change at page 24, line 17
4.1 Early Dialog Actions 4.1 Early Dialog Actions
The following are a set of actions that may be performed on a single The following are a set of actions that may be performed on a single
early dialog. These actions can be thought of as a set of remote early dialog. These actions can be thought of as a set of remote
control operations. For example an automaton might perform the control operations. For example an automaton might perform the
operation on behalf of a user. Alternatively a user might use the operation on behalf of a user. Alternatively a user might use the
remote control in the form of an application to perform the action on remote control in the form of an application to perform the action on
the early dialog of a UA which may be out of reach. All of these the early dialog of a UA which may be out of reach. All of these
actions correspond to telling the UA how to respond to a request to actions correspond to telling the UA how to respond to a request to
establish an early dialog. These actions provide useful functionality establish an early dialog. These actions provide useful
for PDA, PC and server based applications which desire the ability to functionality for PDA, PC and server based applications which desire
control a UA. A proposed mechanism for this type of functionality is the ability to control a UA. A proposed mechanism for this type of
described in Remote Call Control [24]. functionality is described in Remote Call Control [23].
4.1.1 Remote Answer 4.1.1 Remote Answer
A dialog is in some early dialog state such as 180 Ringing. It may A dialog is in some early dialog state such as 180 Ringing. It may
be desirable to tell the UA to answer the dialog. That is tell it to be desirable to tell the UA to answer the dialog. That is tell it to
send a 200 Ok response to establish the dialog. send a 200 Ok response to establish the dialog.
4.1.2 Remote Forward or Put 4.1.2 Remote Forward or Put
It may be desirable to tell the UA to respond with a 3xx class It may be desirable to tell the UA to respond with a 3xx class
skipping to change at page 25, line 10 skipping to change at page 24, line 47
4.2 Single Dialog Actions 4.2 Single Dialog Actions
There is another useful set of actions which operate on a single There is another useful set of actions which operate on a single
established dialog. These operations are useful in building established dialog. These operations are useful in building
productivity applications for aiding users to control their phone. productivity applications for aiding users to control their phone.
For example a CRM application which sets up calls for a user For example a CRM application which sets up calls for a user
eliminating the need for the user to actually enter an address. eliminating the need for the user to actually enter an address.
These operations can also be thought of a remote control actions. A These operations can also be thought of a remote control actions. A
proposed mechanism for this type of functionality is described in proposed mechanism for this type of functionality is described in
Remote Call Control [24]. Remote Call Control [23].
4.2.1 Remote Dial 4.2.1 Remote Dial
This action instructs the UA to initiate a dialog. This action can This action instructs the UA to initiate a dialog. This action can
be performed using the REFER method. be performed using the REFER method.
4.2.2 Remote On and Off Hold 4.2.2 Remote On and Off Hold
This action instructs the UA to put an established dialog on hold. This action instructs the UA to put an established dialog on hold.
Though this operation can be conceptually be performed with the REFER Though this operation can be conceptually be performed with the REFER
method, there is no semantics defined as to what the referred party method, there is no semantics defined as to what the referred party
should do with the SDP. There is no way to distinguish between the should do with the SDP. There is no way to distinguish between the
desire to go on or off hold. desire to go on or off hold.
4.2.3 Remote Hangup 4.2.3 Remote Hangup
This action instructs the UA to terminate an early or established This action instructs the UA to terminate an early or established
dialog. A REFER request with the following Refer-To URI performs this dialog. A REFER request with the following Refer-To URI performs
action. Note: this URL is not properly escaped. this action. Note: this URL is not properly escaped.
sip:bob@babylon.biloxi.example.com;method=BYE?Call-ID=13413098 sip:bob@babylon.biloxi.example.com;method=BYE?Call-ID=13413098
&To=<sip:bob@biloxi.com>;tag=879738 &To=<sip:bob@biloxi.com>;tag=879738
&From=<sip:alice@atlanta.example.com>;tag=023214 &From=<sip:alice@atlanta.example.com>;tag=023214
4.3 Multi-dialog actions 4.3 Multi-dialog actions
These actions apply to a set of related dialogs. These actions apply to a set of related dialogs.
4.3.1 Transfer 4.3.1 Transfer
skipping to change at page 26, line 22 skipping to change at page 26, line 8
reINVITE B (w/SDP of C) reINVITE B (w/SDP of C)
BYE A BYE A
Features enabled by this action: - blind transfer - transfer to a Features enabled by this action: - blind transfer - transfer to a
central mixer (some type of conference or forking) - transfer to park central mixer (some type of conference or forking) - transfer to park
server (park) - transfer to music on hold or announcement server - server (park) - transfer to music on hold or announcement server -
transfer to a "queue" - transfer to a service (such as Voice Dialogs transfer to a "queue" - transfer to a service (such as Voice Dialogs
service) - transition from local mixer to central mixer service) - transition from local mixer to central mixer
This action is frequently referred to as "completing an attended This action is frequently referred to as "completing an attended
transfer". It is described in more detail in cc-transfer [19]. transfer". It is described in more detail in cc-transfer [18].
4.3.2 Take 4.3.2 Take
The conversation space changes as follows: { B , C } --> { B , A } The conversation space changes as follows: { B , C } --> { B , A }
A forcibly replaces C with itself. In most uses of this primitive, A A forcibly replaces C with itself. In most uses of this primitive, A
is just "un-replacing" itself. Using the peer-to-peer approach, "A" is just "un-replacing" itself. Using the peer-to-peer approach, "A"
sends: INVITE B Replaces: <call leg between B and C> sends: INVITE B Replaces: <call leg between B and C>
Using the 3pcc approach (all requests sent from controller) INVITE A Using the 3pcc approach (all requests sent from controller) INVITE A
(w/SDP of B) reINVITE B (w/SDP of A) BYE C (w/SDP of B) reINVITE B (w/SDP of A) BYE C
skipping to change at page 26, line 50 skipping to change at page 26, line 36
Note: that pick up of a ringing call has perhaps some interesting Note: that pick up of a ringing call has perhaps some interesting
additional requirements. First of all it is an early dialog as additional requirements. First of all it is an early dialog as
opposed to an established dialog. Secondly the party which is to opposed to an established dialog. Secondly the party which is to
pickup the call may only wish to do so only while it is an early pickup the call may only wish to do so only while it is an early
dialog. That is in the race condition where the ringing UA accepts dialog. That is in the race condition where the ringing UA accepts
just before it receives signaling from the party wishing to take the just before it receives signaling from the party wishing to take the
call, the taking party wishes to yield or cancel the take. The goal call, the taking party wishes to yield or cancel the take. The goal
is to avoid yanking an answered call from the called party. is to avoid yanking an answered call from the called party.
This action is described in Replaces [9] and in cc-transfer [19]. This action is described in Replaces [9] and in cc-transfer [18].
4.3.3 Add 4.3.3 Add
Note that the following 4 actions are described in cc-conferencing Note that the following 4 actions are described in cc-conferencing
[20]. [19].
This is merely adding a participant to a SIP conference. The This is merely adding a participant to a SIP conference. The
conversation space changes as follows: { A , B } --> { A, B, C } A conversation space changes as follows: { A , B } --> { A, B, C } A
adds C to the conversation. Using the peer-to-peer approach, adding a adds C to the conversation. Using the peer-to-peer approach, adding
party using local mixing requires no signaling. To transition from a a party using local mixing requires no signaling. To transition from
2-party call or a locally mixed conference to centrally mixing A a 2-party call or a locally mixed conference to centrally mixing A
could send the following requests: REFER B Refer-To: conference-URI could send the following requests: REFER B Refer-To: conference-URI
INVITE conference-URI BYE B To add a party to a conference: REFER C INVITE conference-URI BYE B To add a party to a conference: REFER C
Refer-To: conference-URI or REFER conference-URI Refer-To: C Using Refer-To: conference-URI or REFER conference-URI Refer-To: C Using
the 3pcc approach to transition to centrally mixed, the controller the 3pcc approach to transition to centrally mixed, the controller
would send: INVITE mixer leg 1 (w/SDP of A) INVITE mixer leg 2 (w/SDP would send: INVITE mixer leg 1 (w/SDP of A) INVITE mixer leg 2 (w/SDP
of B) INVITE C (late SDP) reINVITE A (w/SDP of mixer leg 1) reINVITE of B) INVITE C (late SDP) reINVITE A (w/SDP of mixer leg 1) reINVITE
B (w/SDP of mixer leg 2) INVITE mixer leg3 (w/SDP of C) To add a B (w/SDP of mixer leg 2) INVITE mixer leg3 (w/SDP of C) To add a
party to a SIP conference: INVITE C (late SDP) INVITE conference-URI party to a SIP conference: INVITE C (late SDP) INVITE conference-URI
(w/SDP of C) Features enabled: - standard conference feature - call (w/SDP of C) Features enabled: - standard conference feature - call
recording - answering-machine style screening (screening) recording - answering-machine style screening (screening)
skipping to change at page 28, line 16 skipping to change at page 27, line 50
Refer-To: conference-URI (new URI) BYE C BYE D Features enabled: - Refer-To: conference-URI (new URI) BYE C BYE D Features enabled: -
sidebar conversations during a larger conference sidebar conversations during a larger conference
4.3.7 Near-fork 4.3.7 Near-fork
A participates in two conversation spaces simultaneously: { A, B } A participates in two conversation spaces simultaneously: { A, B }
--> { B , A } & { A , C } A is a participant in two conversation --> { B , A } & { A , C } A is a participant in two conversation
spaces such that A sends the same media to both spaces, and renders spaces such that A sends the same media to both spaces, and renders
media from both spaces, presumably by mixing or rendering the media media from both spaces, presumably by mixing or rendering the media
from both. We can define that A is the "anchor" point for both from both. We can define that A is the "anchor" point for both
forks, each of which is a separate conversation space. This action is forks, each of which is a separate conversation space. This action
purely local implementation (it requires no special signaling). is purely local implementation (it requires no special signaling).
Local features such as switching calls between the background and Local features such as switching calls between the background and
foreground are possible using this media relationship. foreground are possible using this media relationship.
4.3.8 Far fork 4.3.8 Far fork
The conversation space diagram... { A, B } --> { A , B } & { B , C } The conversation space diagram... { A, B } --> { A , B } & { B , C
A requests B to be the "anchor" of two conversation spaces. This is } A requests B to be the "anchor" of two conversation spaces. This
easily setup by creating a conference with two subconferences and is easily setup by creating a conference with two subconferences and
setting the media policy appopriately such that B is a participant in setting the media policy appopriately such that B is a participant in
both. Media forking can also be setup using 3pcc as described in both. Media forking can also be setup using 3pcc as described in
Section 5.1 of RFC3264 [3] (an offer/answer model for SDP). The Section 5.1 of RFC3264 [3] (an offer/answer model for SDP). The
session descriptions for forking are quite complex. Controllers session descriptions for forking are quite complex. Controllers
should verify that endpoints can handle forked-media, for example should verify that endpoints can handle forked-media, for example
using prior configuration. using prior configuration.
Features enabled: Features enabled:
o barge-in o barge-in
o voice portal services o voice portal services
o whisper o whisper
o hotword detection o hotword detection
o sending DTMF somewhere else o sending DTMF somewhere else
5. Security Considerations 5. Security Considerations
Call Control primitives provide a powerful set of features that can Call Control primitives provide a powerful set of features that can
be dangerous in the hands of an attacker. To complicate matters, be dangerous in the hands of an attacker. To complicate matters,
call control primitives are likely to be automatically authorized call control primitives are likely to be automatically authorized
without direct human oversight. without direct human oversight.
The class of attacks which are possible using these tools include the The class of attacks which are possible using these tools include the
skipping to change at page 32, line 16 skipping to change at page 31, line 44
her either ring briefly or not at all and are forwarded elsewhere. her either ring briefly or not at all and are forwarded elsewhere.
Some variations allow specially authorized callers to override this Some variations allow specially authorized callers to override this
feature and ring Alice anyway. feature and ring Alice anyway.
Distinctive ring - Incoming calls have different ring cadences or Distinctive ring - Incoming calls have different ring cadences or
sample sounds depending on the From party, the To party, or other sample sounds depending on the From party, the To party, or other
factors. factors.
Automatic Callback: Alice calls Bob, but Bob is busy. Alice would Automatic Callback: Alice calls Bob, but Bob is busy. Alice would
like Bob to call her automatically when he is available. When Bob like Bob to call her automatically when he is available. When Bob
hangs up, alice's phone rings. When Alice answers, Bob's phone rings. hangs up, alice's phone rings. When Alice answers, Bob's phone
Bob answers and they talk. rings. Bob answers and they talk.
Find-Me - Alice sets up complicated rules for how she can be reached Find-Me - Alice sets up complicated rules for how she can be reached
(possibly using [CPL], [presence] or other factors). When Bob calls (possibly using [CPL], [presence] or other factors). When Bob calls
Alice, his call is eventually routed to a temporary Contact where Alice, his call is eventually routed to a temporary Contact where
Alice happens to be available. Alice happens to be available.
Whispered call waiting - Alice is in a conversation with Bob. Carol Whispered call waiting - Alice is in a conversation with Bob. Carol
calls Alice. Either Carol can "whisper" to Alice directly ("Can you calls Alice. Either Carol can "whisper" to Alice directly ("Can you
get lunch in 15 minutes?"), or an automaton whispers to Alice get lunch in 15 minutes?"), or an automaton whispers to Alice
informing her that Carol is trying to reach her. informing her that Carol is trying to reach her.
skipping to change at page 35, line 36 skipping to change at page 35, line 19
Barge-in works the same as call monitoring except that it must Barge-in works the same as call monitoring except that it must
indicate that the send media stream to be mixed so that all of the indicate that the send media stream to be mixed so that all of the
other parties can hear the stream from UA barging in. other parties can hear the stream from UA barging in.
6.1.6 Intercom 6.1.6 Intercom
The UA initiates a dialog using INVITE in the ordinary way. The The UA initiates a dialog using INVITE in the ordinary way. The
calling UA then signals the paged UA to answer the call. The calling calling UA then signals the paged UA to answer the call. The calling
UA may discover the URL to answer the call via the session dialog UA may discover the URL to answer the call via the session dialog
package of the called UA. The called UA accepts the INVITE with a 200 package of the called UA. The called UA accepts the INVITE with a
Ok and automatically enables the speakerphone. 200 Ok and automatically enables the speakerphone.
Alternatively this can be a local decision for the UA to answer based Alternatively this can be a local decision for the UA to answer based
upon called party identification. upon called party identification.
6.1.7 Speakerphone paging 6.1.7 Speakerphone paging
Speakerphone paging can be implemented using either multicast or Speakerphone paging can be implemented using either multicast or
through a simple multipoint mixer. In the multicast solution the through a simple multipoint mixer. In the multicast solution the
paging UA sends a multicast INVITE with send only media in the SDP paging UA sends a multicast INVITE with send only media in the SDP
(see also RFC3264). The automatic answer and enabling of the (see also RFC3264). The automatic answer and enabling of the
skipping to change at page 38, line 9 skipping to change at page 37, line 39
The Voice Portal is now just listening for a hotword or the The Voice Portal is now just listening for a hotword or the
appropriate DTMF. As soon as the user indicates they are done, the appropriate DTMF. As soon as the user indicates they are done, the
Voice Portal Takes the call from the old Target, and we are back to Voice Portal Takes the call from the old Target, and we are back to
the original media relationship. the original media relationship.
This feature can also be used by the account number and phone number This feature can also be used by the account number and phone number
collection menu in a pre-paid calling service. A user can press a collection menu in a pre-paid calling service. A user can press a
DTMF sequence which presents them with the appropriate menu again. DTMF sequence which presents them with the appropriate menu again.
Normative References 7. References
7.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] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] 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.
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [3] 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.
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002. Notification", RFC 3265, June 2002.
[5] Handley, M. and V. Jacobson, "SDP: Session Description [5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[6] Johnston, A. and S. Donovan, "Session Initiation Protocol [6] Johnston, A. and R. Sparks, "Session Initiation Protocol
Service Examples", draft-ietf-sipping-service-examples-04 (work Service Examples", draft-ietf-sipping-service-examples-07 (work
in progress), March 2003. in progress), July 2004.
[7] Rosenberg, J., Schulzrinne, H., Camarillo, G. and J. Peterson, [7] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo,
"Best Current Practices for Third Party Call Control in the "Best Current Practices for Third Party Call Control (3pcc) in
Session Initiation Protocol", draft-ietf-sipping-3pcc-03 (work the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April
in progress), March 2003. 2004.
[8] Sparks, R., "The Session Initiation Protocol (SIP) Refer [8] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[9] Dean, R., Biggs, B. and R. Mahy, "The Session Inititation [9] Mahy, R., Biggs, B. and R. Dean, "The Session Initiation
Protocol (SIP) 'Replaces' Header", draft-ietf-sip-replaces-03 Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
(work in progress), March 2003.
[10] Mahy, R. and D. Petrie, "The Session Inititation Protocol (SIP) [10] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP)
'Join' Header", draft-ietf-sip-join-01 (work in progress), "Join" Header", RFC 3911, October 2004.
March 2003.
[11] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog [11] Rosenberg, J., "An INVITE Inititiated Dialog Event Package for
Event Package for the Session Initiation Protocol (SIP", the Session Initiation Protocol (SIP)",
draft-ietf-sipping-dialog-package-01 (work in progress), March draft-ietf-sipping-dialog-package-05 (work in progress),
2003. November 2004.
[12] Rosenberg, J. and H. Schulzrinne, "A Session Initiation [12] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Protocol (SIP) Event Package for Conference State", Package for Conference State",
draft-ietf-sipping-conference-package-00 (work in progress), draft-ietf-sipping-conference-package-08 (work in progress),
June 2002. December 2004.
[13] Rosenberg, J., "A Session Initiation Protocol (SIP) Event [13] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", draft-ietf-sipping-reg-event-00 Package for Registrations", RFC 3680, March 2004.
(work in progress), October 2002.
[14] Rosenberg, J., "A Presence Event Package for the Session [14] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work Initiation Protocol (SIP)", RFC 3856, August 2004.
in progress), January 2003.
[15] Rosenberg, J., "A Framework for Conferencing with the Session [15] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol", Initiation Protocol",
draft-ietf-sipping-conferencing-framework-00 (work in draft-ietf-sipping-conferencing-framework-03 (work in
progress), May 2003. progress), October 2004.
[16] Rosenberg, J., "A Framework for Application Interaction in the [16] Rosenberg, J., "A Framework for Application Interaction in the
Session Initiation Protocol (SIP)", Session Initiation Protocol (SIP)",
draft-ietf-sipping-app-interaction-framework-00 (work in draft-ietf-sipping-app-interaction-framework-03 (work in
progress), October 2003. progress), October 2004.
[17] Mahy, R. and N. Ismail, "Media Policy Manipulation in the
Conference Policy Control Protocol",
draft-mahy-xcon-media-policy-control-00 (work in progress),
June 2003.
[18] Camarillo, G., "Transcoding Services Invocation in the Session [17] Camarillo, G., "Framework for Transcoding with the Session
Initiation Protocol", draft-camarillo-sip-deaf-02 (work in Initiation Protocol", draft-ietf-sipping-transc-framework-00
progress), February 2003. (work in progress), February 2004.
[19] Sparks, R. and A. Johnston, "Session Initiation Protocol Call [18] Sparks, R. and A. Johnston, "Session Initiation Protocol Call
Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in Control - Transfer", draft-ietf-sipping-cc-transfer-03 (work in
progress), February 2003. progress), October 2004.
[20] Johnston, A. and O. Levin, "Session Initiation Protocol Call [19] Johnston, A. and O. Levin, "Session Initiation Protocol Call
Control - Conferencing for User Agents", Control - Conferencing for User Agents",
draft-ietf-sipping-cc-conferencing-00 (work in progress), April draft-ietf-sipping-cc-conferencing-06 (work in progress),
2003. November 2004.
[21] Rosenberg, J., "Indicating User Agent Capabilities in the [20] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Indicating User
Session Initiation Protocol (SIP)", Agent Capabilities in the Session Initiation Protocol (SIP)",
draft-ietf-sip-callee-caps-00 (work in progress), June 2003. RFC 3840, August 2004.
[22] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller [21] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller
Preferences and Callee Capabilities for the Session Initiation Preferences for the Session Initiation Protocol (SIP)", RFC
Protocol (SIP)", draft-ietf-sip-callerprefs-08 (work in 3841, August 2004.
progress), March 2003.
Informational References 7.2 Informational References
[23] Campbell, B. and R. Sparks, "Control of Service Context using [22] Campbell, B. and R. Sparks, "Control of Service Context using
SIP Request-URI", RFC 3087, April 2001. SIP Request-URI", RFC 3087, April 2001.
[24] Mahy, R., "Remote Call Control in SIP using the REFER method [23] Mahy, R., "Remote Call Control in SIP using the REFER method
and the session-oriented dialog package", and the session-oriented dialog package",
draft-mahy-sip-remote-cc-00 (work in progress), October 2003. draft-mahy-sip-remote-cc-01 (work in progress), February 2004.
[25] Burger, E., Dyke, J. and A. Spitzer, "Basic Network Media [24] Burger, E., "Basic Network Media Services with SIP",
Services with SIP", draft-burger-sipping-netann-05 (work in draft-burger-sipping-netann-10 (work in progress), October
progress), March 2003. 2004.
Authors' Addresses Authors' Addresses
Rohan Mahy Rohan Mahy
Cisco Systems Airespace
EMail: rohan@cisco.com
EMail: rohan@ekabal.com
Ben Campbell Ben Campbell
dynamicsoft Estacado Systems
EMail: bcampbell@dynamicsoft.com EMail: ben@nostrum.com
Robert Sparks Robert Sparks
dynamicsoft XTen
EMail: rsparks@dynamicsoft.com EMail: rjs@xten.com
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft Cisco Systems
EMail: jdrosen@dynamicsoft.com EMail: jdrosen@cisco.com
Dan Petrie Dan Petrie
Pingtel Pingtel
EMail: dpetrie@pingtel.com EMail: dpetrie@pingtel.com
Alan Johnston Alan Johnston
WorldCom MCI
EMail: alan.johnston@wcom.com EMail: alan.johnston@mci.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. 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.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
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 Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2005). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
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.
Acknowledgement Acknowledgment
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.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/