draft-ietf-sipping-cc-framework-07.txt   draft-ietf-sipping-cc-framework-08.txt 
SIPPING WG R. Mahy SIPPING WG R. Mahy
Internet-Draft Plantronics Internet-Draft Plantronics
Intended status: Informational B. Campbell Intended status: Informational B. Campbell
Expires: September 5, 2007 R. Sparks Expires: May 31, 2008 R. Sparks
Estacado Systems Estacado Systems
J. Rosenberg J. Rosenberg
Cisco Systems Cisco Systems
D. Petrie D. Petrie
SIP EZ SIP EZ
A. Johnston, Ed. A. Johnston, Ed.
Avaya Avaya
March 4, 2007 November 28, 2007
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-07 draft-ietf-sipping-cc-framework-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 The list of current Internet-Drafts can be accessed at
http://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 September 5, 2007. This Internet-Draft will expire on May 31, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
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 that embody the spirit of This framework also describes other goals that 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. Motivation and Background . . . . . . . . . . . . . . . . . . 4 1. Motivation and Background . . . . . . . . . . . . . . . . . . 4
2. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. "Conversation Space" Model . . . . . . . . . . . . . . . . 6 2.1. "Conversation Space" Model . . . . . . . . . . . . . . . . 6
2.2. Comparison with Related Definitions . . . . . . . . . . . 7 2.2. Relationship Between Conversation Space, SIP Dialogs,
and SIP Sessions . . . . . . . . . . . . . . . . . . . . . 7
2.3. Signaling Models . . . . . . . . . . . . . . . . . . . . . 8 2.3. Signaling Models . . . . . . . . . . . . . . . . . . . . . 8
2.4. Mixing Models . . . . . . . . . . . . . . . . . . . . . . 9 2.4. Mixing Models . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1. Tightly Coupled . . . . . . . . . . . . . . . . . . . 9 2.4.1. Tightly Coupled . . . . . . . . . . . . . . . . . . . 10
2.4.2. Loosely Coupled . . . . . . . . . . . . . . . . . . . 11 2.4.2. Loosely Coupled . . . . . . . . . . . . . . . . . . . 11
2.5. Conveying Information and Events . . . . . . . . . . . . . 11 2.5. Conveying Information and Events . . . . . . . . . . . . . 12
2.6. Componentization and Decomposition . . . . . . . . . . . . 13 2.6. Componentization and Decomposition . . . . . . . . . . . . 14
2.6.1. Media Intermediaries . . . . . . . . . . . . . . . . . 14 2.6.1. Media Intermediaries . . . . . . . . . . . . . . . . . 14
2.6.2. Mixer . . . . . . . . . . . . . . . . . . . . . . . . 14 2.6.2. Mixer . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6.3. Transcoder . . . . . . . . . . . . . . . . . . . . . . 14 2.6.3. Transcoder . . . . . . . . . . . . . . . . . . . . . . 15
2.6.4. Media Relay . . . . . . . . . . . . . . . . . . . . . 14 2.6.4. Media Relay . . . . . . . . . . . . . . . . . . . . . 15
2.6.5. Queue Server . . . . . . . . . . . . . . . . . . . . . 14 2.6.5. Queue Server . . . . . . . . . . . . . . . . . . . . . 15
2.6.6. Parking Place . . . . . . . . . . . . . . . . . . . . 15 2.6.6. Parking Place . . . . . . . . . . . . . . . . . . . . 15
2.6.7. Announcements and Voice Dialogs . . . . . . . . . . . 15 2.6.7. Announcements and Voice Dialogs . . . . . . . . . . . 15
2.7. Use of URIs . . . . . . . . . . . . . . . . . . . . . . . 17 2.7. Use of URIs . . . . . . . . . . . . . . . . . . . . . . . 17
2.7.1. Naming Users in SIP . . . . . . . . . . . . . . . . . 17 2.7.1. Naming Users in SIP . . . . . . . . . . . . . . . . . 18
2.7.2. Naming Services with SIP URIs . . . . . . . . . . . . 19 2.7.2. Naming Services with SIP URIs . . . . . . . . . . . . 19
2.8. Invoker Independence . . . . . . . . . . . . . . . . . . . 20 2.8. Invoker Independence . . . . . . . . . . . . . . . . . . . 21
2.9. Billing issues . . . . . . . . . . . . . . . . . . . . . . 21 2.9. Billing issues . . . . . . . . . . . . . . . . . . . . . . 21
3. Catalog of call control actions and sample features . . . . . 21 3. Catalog of call control actions and sample features . . . . . 22
3.1. Early Dialog Actions . . . . . . . . . . . . . . . . . . . 22 3.1. Remote Call Control Actions on Early Dialogs . . . . . . . 22
3.1.1. Remote Answer . . . . . . . . . . . . . . . . . . . . 22 3.1.1. Remote Answer . . . . . . . . . . . . . . . . . . . . 22
3.1.2. Remote Forward or Put . . . . . . . . . . . . . . . . 22 3.1.2. Remote Forward or Put . . . . . . . . . . . . . . . . 23
3.1.3. Remote Busy or Error Out . . . . . . . . . . . . . . . 22 3.1.3. Remote Busy or Error Out . . . . . . . . . . . . . . . 23
3.2. Single Dialog Actions . . . . . . . . . . . . . . . . . . 22 3.2. Remote Call Control Actions on Single Dialogs . . . . . . 23
3.2.1. Remote Dial . . . . . . . . . . . . . . . . . . . . . 23 3.2.1. Remote Dial . . . . . . . . . . . . . . . . . . . . . 23
3.2.2. Remote On and Off Hold . . . . . . . . . . . . . . . . 23 3.2.2. Remote On and Off Hold . . . . . . . . . . . . . . . . 23
3.2.3. Remote Hangup . . . . . . . . . . . . . . . . . . . . 23 3.2.3. Remote Hangup . . . . . . . . . . . . . . . . . . . . 23
3.3. Multi-dialog actions . . . . . . . . . . . . . . . . . . . 23 3.3. Call Control Actions on Multiple Dialogs . . . . . . . . . 24
3.3.1. Transfer . . . . . . . . . . . . . . . . . . . . . . . 23 3.3.1. Transfer . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.2. Take . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3.2. Take . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.3. Add . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3.3. Add . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.4. Local Join . . . . . . . . . . . . . . . . . . . . . . 25 3.3.4. Local Join . . . . . . . . . . . . . . . . . . . . . . 26
3.3.5. Insert . . . . . . . . . . . . . . . . . . . . . . . . 25 3.3.5. Insert . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.6. Split . . . . . . . . . . . . . . . . . . . . . . . . 25 3.3.6. Split . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.7. Near-fork . . . . . . . . . . . . . . . . . . . . . . 25 3.3.7. Near-fork . . . . . . . . . . . . . . . . . . . . . . 28
3.3.8. Far fork . . . . . . . . . . . . . . . . . . . . . . . 26 3.3.8. Far fork . . . . . . . . . . . . . . . . . . . . . . . 28
4. Security Considerations . . . . . . . . . . . . . . . . . . . 26 4. Security Considerations . . . . . . . . . . . . . . . . . . . 29
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
6. Appendix A: Example Features . . . . . . . . . . . . . . . . . 27 6. Appendix A: Example Features . . . . . . . . . . . . . . . . . 30
6.1. Implementation of these features . . . . . . . . . . . . . 31 6.1. Implementation of these features . . . . . . . . . . . . . 33
6.1.1. Call Park . . . . . . . . . . . . . . . . . . . . . . 32 6.1.1. Barge-in . . . . . . . . . . . . . . . . . . . . . . . 34
6.1.2. Call Pickup . . . . . . . . . . . . . . . . . . . . . 32 6.1.2. Call Monitoring . . . . . . . . . . . . . . . . . . . 34
6.1.3. Music on Hold . . . . . . . . . . . . . . . . . . . . 32 6.1.3. Call Park . . . . . . . . . . . . . . . . . . . . . . 35
6.1.4. Call Monitoring . . . . . . . . . . . . . . . . . . . 33 6.1.4. Call Pickup . . . . . . . . . . . . . . . . . . . . . 35
6.1.5. Barge-in . . . . . . . . . . . . . . . . . . . . . . . 33 6.1.5. Click-to-dial . . . . . . . . . . . . . . . . . . . . 35
6.1.6. Intercom . . . . . . . . . . . . . . . . . . . . . . . 33 6.1.6. Distinctive ring . . . . . . . . . . . . . . . . . . . 36
6.1.7. Speakerphone paging . . . . . . . . . . . . . . . . . 33 6.1.7. Intercom . . . . . . . . . . . . . . . . . . . . . . . 36
6.1.8. Distinctive ring . . . . . . . . . . . . . . . . . . . 34 6.1.8. Music on Hold . . . . . . . . . . . . . . . . . . . . 36
6.1.9. Voice message screening . . . . . . . . . . . . . . . 34 6.1.9. Pre-paid calling . . . . . . . . . . . . . . . . . . . 36
6.1.10. Single Line Extension/Multiple Line Appearance . . . . 34 6.1.10. Single Line Extension/Multiple Line Appearance . . . . 37
6.1.11. Click-to-dial . . . . . . . . . . . . . . . . . . . . 34 6.1.11. Speakerphone paging . . . . . . . . . . . . . . . . . 37
6.1.12. Pre-paid calling . . . . . . . . . . . . . . . . . . . 34 6.1.12. Voice message screening . . . . . . . . . . . . . . . 37
6.1.13. Voice Portal . . . . . . . . . . . . . . . . . . . . . 35 6.1.13. Voice Portal . . . . . . . . . . . . . . . . . . . . . 38
7. Informative References . . . . . . . . . . . . . . . . . . . . 36 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 8. Informative References . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 43
1. Motivation and Background 1. Motivation and Background
The Session Initiation Protocol [1] (SIP) was defined for the The Session Initiation Protocol [1] (SIP) was defined for the
initiation, maintenance, and termination of sessions or calls between initiation, maintenance, and termination of sessions or calls between
one or more users. However, despite its origins as a large-scale one or more users. However, despite its origins as a large-scale
multiparty conferencing protocol, SIP is used today primarily for multiparty conferencing protocol, SIP is used today primarily for
point to point calls. This two-party configuration is the focus of point to point calls. This two-party configuration is the focus of
the SIP specification and most of its extensions. the SIP specification and most of its extensions.
This document defines a framework and requirements for multi-party This document defines a framework and requirements for multi-party
usage of SIP. Most multi-party operations manipulate SIP session usage of SIP. Most multi-party operations manipulate SIP dialogs
dialogs (also known as call legs) or SIP conference media policy to (also known as call legs) or SIP conference media policy to cause
cause participants in a conversation to perceive specific media participants in a conversation to perceive specific media
relationships. In other protocols that deal with the concept of relationships. In other protocols that deal with the concept of
calls, this manipulation is known as call control. In addition to calls, this manipulation is known as call control. In addition to
its dialog or policy manipulation aspect, "call control" also its dialog or policy manipulation aspect, "call control" also
includes communicating information and events related to manipulating includes communicating information and events related to manipulating
calls, including information and events dealing with session state calls, including information and events dealing with session state
and history, conference state, user state, and even message state. and history, conference state, user state, and even message state.
Based on input from the SIP community, the authors compiled the Based on input from the SIP community, the authors compiled the
following set of goals for SIP call control and multiparty following set of goals for SIP call control and multiparty
applications: applications:
o Define Primitives, Not Services. Allow for a handful of robust o Define Primitives, Not Services. Allow for a handful of robust
yet simple mechanisms that can be combined to deliver features and yet simple mechanisms that can be combined to deliver features and
services. Throughout this document we refer to these simple services. Throughout this document we refer to these simple
mechanisms as "primitives". Primitives should be sufficiently mechanisms as "primitives". Primitives should be sufficiently
robust that when they are combined they can be used to build lots robust so that when they are combined with eachother, they can be
of services. However, the goal is not to define a provably used to build lots of services. However, the goal is not to
complete set of primitives. Note that while the IETF will NOT define a provably complete set of primitives. Note that while the
standardize behavior or services, it may define example services IETF will NOT standardize behavior or services, it may define
for informational purposes, as in service examples [6]. example services for informational purposes, as in service
examples [6].
o Participant oriented. The primitives should be designed to o Participant oriented. The primitives should be designed to
provide services that are oriented around the experience of the provide services that are oriented around the experience of the
participants. The authors observe that end users of features and participants. The authors observe that end users of features and
services usually don't care how a media relationship is setup. services usually don't care how a media relationship is setup.
Their ultimate experience is based only on the resulting media and Their ultimate experience is based only on the resulting media and
other externally visible characteristics. other externally visible characteristics.
o Signaling Model independent: Support both a central control and a o Signaling Model independent: Support both a central control and a
peer-to-peer feature invocation model (and combinations of the peer-to-peer feature invocation model (and combinations of the
two). Baseline SIP already supports a centralized control model two). Baseline SIP already supports a centralized control model
described in 3pcc [7], and the SIP community has expressed a great described in 3pcc [7], and the SIP community has expressed a great
skipping to change at page 4, line 50 skipping to change at page 5, line 4
services usually don't care how a media relationship is setup. services usually don't care how a media relationship is setup.
Their ultimate experience is based only on the resulting media and Their ultimate experience is based only on the resulting media and
other externally visible characteristics. other externally visible characteristics.
o Signaling Model independent: Support both a central control and a o Signaling Model independent: Support both a central control and a
peer-to-peer feature invocation model (and combinations of the peer-to-peer feature invocation model (and combinations of the
two). Baseline SIP already supports a centralized control model two). Baseline SIP already supports a centralized control model
described in 3pcc [7], and the SIP community has expressed a great described in 3pcc [7], and the SIP community has expressed a great
deal of interest in peer-to-peer or distributed call control using deal of interest in peer-to-peer or distributed call control using
primitives such as those defined in REFER [8], Replaces [9], and primitives such as those defined in REFER [8], Replaces [9], and
Join [10]. Join [10].
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 of the same type in an appropriate,
This is consistent with model described in the SIP conferencing media-specific way. This is consistent with model described in
framework. the SIP conferencing 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 needs to know exactly which service is invoked or why. service needs to know exactly which service is invoked or why.
This is good because it allows new services to be created without This is 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 that can be extremely expressive and easily plentiful resource that 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 that need only be relevant to the owner of the namespace headers that 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 that translates into it references, a user may encounter a SIP URI that translates into
an email-style group alias, that plays a pre-recorded message, or an email-style group alias, that plays a pre-recorded message, or
runs some complex call-handling logic. Note that while this may runs some complex call-handling logic. Note that while this may
seem paradoxical to the previous goal, both goals can be satisfied seem paradoxical to the previous goal, both goals can be satisfied
by the same model. by the same model.
o Make use of SIP headers and SIP event packages to provide SIP o Make use of SIP headers and SIP event packages to provide SIP
entities with information about their environment. These should entities with information about their environment. These should
include information about the status / handling of dialogs on include information about the status / handling of dialogs on
other user agents, information about the history of other contacts other user agents, information about the history of other contacts
attempted prior to the current contact, the status of attempted prior to the current contact, the status of
participants, the status of conferences, user presence participants, the status of conferences, user presence
skipping to change at page 6, line 16 skipping to change at page 6, line 21
call control extensions/primitives must describe a graceful way to call control extensions/primitives must describe a graceful way to
fallback to baseline SIP behavior. Support for one primitive must fallback to baseline SIP behavior. Support for one primitive must
not imply support for another primitive. not imply support for another primitive.
o There is no desire or goal to reinvent traditional models, such as o There is no desire or goal to reinvent traditional models, such as
the model used the [H.450] family of protocols, [JTAPI], or the the model used the [H.450] family of protocols, [JTAPI], or the
[CSTA] call model, as these other models do not share the design [CSTA] call model, as these other models do not share the design
goals presented in this document. goals presented in this document.
2. Key Concepts 2. Key Concepts
This section introduces a number of key concepts which will be used
to describe and explain various call control operations and services
in the remainder of this document. This includes the conversation
space model, signaling and mixing models, common components, and the
use of URIs.
2.1. "Conversation Space" Model 2.1. "Conversation Space" Model
This document introduces the concept of an abstract "conversation This document introduces the concept of an abstract "conversation
space" (essentially as a set of participants who believe they are all space" as a set of participants who believe they are all
communicating among one another). Each conversation space contains communicating among one another. Each conversation space contains
one or more participants. one or more participants.
Participants are SIP User Agents that send original media to or Participants are SIP User Agents that send original media to or
terminate and receive media from other members of the conversation terminate and receive media from other members of the conversation
space. Logically, every participant in the conversation space has space. Logically, every participant in the conversation space has
access to all the media generated in that space (this is strictly access to all the media generated in that space (this is strictly
true if all participants share a common media type). A SIP User true if all participants share a common media type). A SIP User
Agent that does not contribute or consume any media is NOT a Agent that does not contribute or consume any media is NOT a
participant; nor is a user agent that merely forwards, transcoders, participant; nor is a user agent that merely forwards, transcoders,
mixes, or selects media originating elsewhere in the conversation mixes, or selects media originating elsewhere in the conversation
skipping to change at page 7, line 11 skipping to change at page 7, line 22
dialog system) may be active participants if they can leave the dialog system) may be active participants if they can leave the
conversation space when there is no human interaction. Other robots conversation space when there is no human interaction. Other robots
(for example our tone generating robot from the previous example) are (for example our tone generating robot from the previous example) are
passive participants. A human participant "on-hold" is passive. passive participants. A human participant "on-hold" is passive.
An example diagram of a conversation space can be shown as a "bubble" An example diagram of a conversation space can be shown as a "bubble"
or ovals, or as a "set" in curly or square brace notation. Each set, or ovals, or as a "set" in curly or square brace notation. Each set,
oval, or "bubble" represents a conversation space. Hidden oval, or "bubble" represents a conversation space. Hidden
participants are shown in lowercase letters. participants are shown in lowercase letters.
{ A , B } [ A , B ] Note that while the term "conversation" usually applies to oral
exchange of information, we apply the conversation space model to any
media exchange between participants.
{ A , B } [ A , b, C, D ]
.-. .---. .-. .---.
/ \ / \ / \ / \
/ A \ / A b \ / A \ / A b \
( ) ( ) ( ) ( )
\ B / \ C D / \ B / \ C D /
\ / \ / \ / \ /
'-' '---' '-' '---'
2.2. Comparison with Related Definitions 2.2. Relationship Between Conversation Space, SIP Dialogs, and SIP
Sessions
In SIP, a call is "an informal term that refers to some communication In SIP, a call is "an informal term that refers to some communication
between peers, generally set up for the purposes of a multimedia between peers, generally set up for the purposes of a multimedia
conversation." Obviously we cannot discuss normative behavior based conversation." Obviously we cannot discuss normative behavior based
on such an intentionally vague definition. The concept of a on such an intentionally vague definition. The concept of a
conversation space is needed because the SIP definition of call is conversation space is needed because the SIP definition of call is
not sufficiently precise for the purpose of describing the user not sufficiently precise for the purpose of describing the user
experience of multiparty features. experience of multiparty features.
Do any other definitions convey the correct meaning? SIP, and SDP Do any other definitions convey the correct meaning? SIP, and SDP
skipping to change at page 8, line 20 skipping to change at page 8, line 34
Obviously to make changes to a conversation space, you must be able Obviously to make changes to a conversation space, you must be able
to use SIP signaling to cause these changes. Specifically there must to use SIP signaling to cause these changes. Specifically there must
be a way to manipulate SIP dialogs (call legs) to move participants be a way to manipulate SIP dialogs (call legs) to move participants
into and out of conversation spaces. Although this is not as into and out of conversation spaces. Although this is not as
obvious, there also must be a way to manipulate SIP dialogs to obvious, there also must be a way to manipulate SIP dialogs to
include non-participant user agents that are otherwise involved in a include non-participant user agents that are otherwise involved in a
conversation space (ex: B2BUAs, 3pcc controllers, mixers, conversation space (ex: B2BUAs, 3pcc controllers, mixers,
transcoders, translators, or relays). transcoders, translators, or relays).
Implementations may setup the media relationships described in the Implementations may setup the media relationships described in the
conversation space model using the approach described in 3pcc [7]. conversation space model using a centralized control model. One
The 3pcc approach relies on only the following 3 primitive common way to implement this using SIP is known as 3rd Party Call
operations: Control (3pcc) and is described in 3pcc [7]. The 3pcc approach
relies on only the following 3 primitive operations:
o Create a new dialog (INVITE) o Create a new dialog (INVITE)
o Modify a dialog (reINVITE) o Modify a dialog (reINVITE)
o Destroy a dialog (BYE) o Destroy a dialog (BYE)
The main advantage of the 3pcc approach is that it only requires very The main advantage of the 3pcc approach is that it only requires very
basic SIP support from end systems to support call control features. basic SIP support from end systems to support call control features.
As such, third-party call control is a natural way to handle protocol As such, third-party call control is a natural way to handle protocol
conversion and mid-call features. It also has the advantage and conversion and mid-call features. It also has the advantage and
disadvantage that new features can/must be implemented in one place disadvantage that new features can/must be implemented in one place
only (the controller), and neither requires enhanced client only (the controller), and neither requires enhanced client
skipping to change at page 8, line 44 skipping to change at page 9, line 11
In addition, a peer-to-peer approach is discussed at length in this In addition, a peer-to-peer approach is discussed at length in this
draft. The primary drawback of the peer-to-peer model is additional draft. The primary drawback of the peer-to-peer model is additional
complexity in the end system and authentication and management complexity in the end system and authentication and management
models. The benefits of the peer-to-peer model include: models. The benefits of the peer-to-peer model include:
o state remains at the edges o state remains at the edges
o call signaling need only go through participants involved (there o call signaling need only go through participants involved (there
are no additional points of failure) are no additional points of failure)
o peers can take advantage of end-to-end message integrity or o peers can take advantage of end-to-end message integrity or
encryption encryption
o setup time is shorter (fewer messages and round trips are o setup time is shorter (fewer messages are required to be sent by
required) the initiator of the action)
The peer-to-peer approach relies on additional "primitive" The peer-to-peer approach relies on additional "primitive"
operations, some of which are identified here. operations, some of which are identified here.
o Replace an existing dialog o Replace an existing dialog
o Join a new dialog with an existing dialog o Join a new dialog with an existing dialog
o Support SIP conference policy control
o Locally perform media forking (multi-unicast) o Locally perform media forking (multi-unicast)
o Ask another UA to send a request on your behalf o Ask another UA to send a request on your behalf
The peer-to-peer approach also only results in a single SIP dialog,
directly between the two UAs. The 3pcc approach results in two SIP
dialogs, between each UA and the controller. As a result, the SIP
features and extensions that will be used during the dialog are
limited to the those understood by the controller. As a result, in a
situation where both the UAs support an advanced SIP feature but the
controller does not, the feature will not be able to be used.
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.
2.4. Mixing Models 2.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 [19]. 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
skipping to change at page 10, line 46 skipping to change at page 11, line 18
M --- A M --- A
/ \ / \
/ \ / \
D E D E
2.4.1.3. Centralized Signaling, Distributed Media 2.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. Participants
is when a user sends multiple packets (one for each recipient, perform their own mixing. Multi-unicast is when a user sends
addressed to that recipient). This is referred to as a multiple packets (one for each recipient, addressed to that
"Decentralized Multipoint Conference" in [H.323]. Full mesh media recipient). This is referred to as a "Decentralized Multipoint
with centralized mixing is another approach. Conference" in [H.323]. Full mesh media with centralized mixing is
another approach.
2.4.2. Loosely Coupled 2.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. sends their own media to every other participant.
2.4.2.1. Large-Scale Multicast Conferences 2.4.2.1. Large-Scale Multicast Conferences
Large-scale multicast conferences were the original motivation for Large-scale multicast conferences were the original motivation for
both the Session Description Protocol SDP [5] and SIP. In a large- both the Session Description Protocol SDP [5] and SIP. In a large-
scale multicast conference, one or more multicast addresses are scale multicast conference, one or more multicast addresses are
allocated to the conference. Each participant joins that multicast allocated to the conference. Each participant joins those multicast
groups, and sends their media to those groups. Signaling is not sent groups, and sends their media to those groups. Signaling is not sent
to the multicast groups. The sole purpose of the signaling is to to the multicast groups. The sole purpose of the signaling is to
inform participants of which multicast groups to join. Large-scale inform participants of which multicast groups to join. Large-scale
multicast conferences are usually pre-arranged, with specific start multicast conferences are usually pre-arranged, with specific start
and stop times. However, multicast conferences do not need to be and stop times. However, multicast conferences do not need to be
pre-arranged, so long as a mechanism exists to dynamically obtain a pre-arranged, so long as a mechanism exists to dynamically obtain a
multicast address. multicast address.
2.4.2.2. Full Distributed Unicast Conferencing 2.4.2.2. Full Distributed Unicast Conferencing
In this conferencing model, each participant has both a pairwise In this conferencing model, each participant has both a pairwise
media relationship and a pairwise SIP relationship with every other media relationship and a pairwise signaling relationship with every
participant (a full mesh). This model requires a mechanism to other participant (a full mesh). This model requires a mechanism to
maintain a consistent view of distributed state across the group. maintain a consistent view of distributed state across the group.
This is a classic hard problem in computer science. Also, this model This is a classic hard problem in computer science. Also, this model
does not scale well for large numbers of participants. because for does not scale well for large numbers of participants. because for
<n> participants the number of media and SIP relationships is <n> participants the number of media and signaling relationships is
approximately n-squared. As a result, this model is not generally approximately n-squared. As a result, this model is not generally
available in commercial implementations; to the contrary it is available in commercial implementations; to the contrary it is
primarily the topic of research or experimental implementations. primarily the topic of research or experimental implementations.
Note that this model assumes peer-to-peer signaling. Note that this model assumes peer-to-peer signaling.
2.5. Conveying Information and Events 2.5. Conveying Information and Events
Participants should have access to information about the other Participants should have access to information about the other
participants in a conversation space, so that this information can be participants in a conversation space, so that this information can be
rendered to a human user or processed by an automaton. Although some rendered to a human user or processed by an automaton. Although some
of this information may be available from the Request-URI or To, of this information may be available from the Request-URI or To,
From, Contact, or other SIP headers, another mechanism of reporting From, Contact, or other SIP headers, another mechanism of reporting
this information is necessary. this information is necessary.
Many applications are driven by knowledge about the progress of calls Many applications are driven by knowledge about the progress of calls
and conferences. In general these types of events allow for the and conferences. In general these types of events allow for the
construction of distributed applications, where the application construction of distributed applications, where the application
requires information on session dialog and conference state, but is requires information on dialog and conference state, but is not
not necessarily co-resident with an endpoint user agent or conference necessarily co-resident with an endpoint user agent or conference
server. For example, a focus involved in a conversation space may server. For example, a focus involved in a conversation space may
wish to provide URLs for conference status, and/or conference/floor wish to provide URIs for conference status, and/or conference/floor
control. control.
The SIP Events [4] architecture defines general mechanisms for The SIP Events [4] architecture defines general mechanisms for
subscription to and notification of events within SIP networks. It subscription to and notification of events within SIP networks. It
introduces the notion of a package that is a specific "instantiation" introduces the notion of a package that is a specific "instantiation"
of the events mechanism for a well-defined set of events. of the events mechanism for a well-defined set of events.
Event packages are needed to provide the status of a user's session Event packages are needed to provide the status of a user's dialogs,
dialogs, provide the status of conferences and its participants, provide the status of conferences and its participants, provide user
provide user presence information, provide the status of presence information, provide the status of registrations, and
registrations, and provide the status of user's messages. While this provide the status of user's messages. While this is not an
is not an exhaustive list, these are sufficient to enable the sample exhaustive list, these are sufficient to enable the sample features
features described in this document. described in this document.
The conference event package [12] allows users to subscribe to The conference event package [12] allows users to subscribe to
information about an entire tightly-coupled SIP conference. information about an entire tightly-coupled SIP conference.
Notifications convey information about the participants such as: the Notifications convey information about the participants such as: the
SIP URL identifying each user, their status in the space (active, SIP URI identifying each user, their status in the space (active,
declined, departed), URLs to invoke other features (such as sidebar declined, departed), URIs to invoke other features (such as sidebar
conversations), links to other relevant information (such as floor conversations), links to other relevant information (such as floor
control policies), and if floor control policies are in place, the control policies), and if floor control policies are in place, the
user's floor control status. For conversation spaces created from user's floor control status. For conversation spaces created from
cascaded conferences, conversation state can be gathered from cascaded conferences, conversation state can be gathered from
relevant foci and merged into a cohesive set of state. relevant foci and merged into a cohesive set of state.
The session dialog package [11] provides information about all the The dialog package [11] provides information about all the dialogs
dialogs the target user is maintaining, what conversations the user the target user is maintaining, what conversations the user in
in participating in, and how these are correlated. Likewise the participating in, and how these are correlated. Likewise the
registration package [13] provides notifications when contacts have registration package [13] provides notifications when contacts have
changed for a specific address-of-record. The combination of these changed for a specific address-of-record. The combination of these
allows a user agent to learn about all conversations occurring for allows a user agent to learn about all conversations occurring for
the entire registered contact set for an address-of-record. the entire registered contact set for an address-of-record.
Note that user presence in SIP [14] has a close relationship with Note that user presence in SIP [14] has a close relationship with
these later two event packages. It is fundamental to the presence these later two event packages. It is fundamental to the presence
model that the information used to obtain user presence is model that the information used to obtain user presence is
constructed from any number of different input sources. Examples of constructed from any number of different input sources. Examples of
other such sources include calendaring information and uploads of other such sources include calendaring information and uploads of
presence documents. These two packages can be considered another presence documents. These two packages can be considered another
mechanism that allows a presence agent to determine the presence mechanism that allows a presence agent to determine the presence
state of the user. Specifically, a user presence server can act as a state of the user. Specifically, a user presence server can act as a
subscriber for the session dialog and registration packages to obtain subscriber for the dialog and registration packages to obtain
additional information that can be used to construct a presence additional information that can be used to construct a presence
document. document.
The multi-party architecture may also need to provide a mechanism to The multi-party architecture may also need to provide a mechanism to
get information about the status /handling of a dialog (for example, get information about the status /handling of a dialog (for example,
information about the history of other contacts attempted prior to information about the history of other contacts attempted prior to
the current contact). Finally, the architecture should provide ample the current contact). Finally, the architecture should provide ample
opportunities to present informational URIs that relate to calls, opportunities to present informational URIs that relate to calls,
conversations, or dialogs in some way. For example, consider the SIP conversations, or dialogs in some way. For example, consider the SIP
Call-Info header, or Contact headers returned in a 300-class Call-Info header, or Contact headers returned in a 300-class
skipping to change at page 13, line 51 skipping to change at page 14, line 25
separate vendors, or even with separate providers, we achieve a separate vendors, or even with separate providers, we achieve a
separation of function that allows each piece to be developed in separation of function that allows each piece to be developed in
complete isolation. We can also reuse existing components for new complete isolation. We can also reuse existing components for new
applications. This allows rapid service creation, and the ability applications. This allows rapid service creation, and the ability
for services to be distributed across organizational domains anywhere for services to be distributed across organizational domains anywhere
in the Internet. in the Internet.
For many of these components it is also desirable to discover their For many of these components it is also desirable to discover their
capabilities, for example querying the ability of a mixer to host a capabilities, for example querying the ability of a mixer to host a
10 dialog conference, or to reserve resources for a specific time. 10 dialog conference, or to reserve resources for a specific time.
These actions could be provided in the form of URLs, provided there These actions could be provided in the form of URIs, provided there
is an a priori means of understanding their semantics. For example is an a priori means of understanding their semantics. For example
if there is a published dictionary of operations, a way to query the if there is a published dictionary of operations, a way to query the
service for the available operations and the associated URLs, the URL service for the available operations and the associated URIs, the URI
can be the interface for providing these service operations. This can be the interface for providing these service operations. This
concept is described in more detail in the context of dialog concept is described in more detail in the context of dialog
operations in section operations in Section 3.
2.6.1. Media Intermediaries 2.6.1. Media Intermediaries
Media Intermediaries are not participants in any conversation space, Media Intermediaries are not participants in any conversation space,
although an entity that is also a media translator may also have a although an entity that is also a media translator may also have a
co-located participant component (for example a mixer that also co-located participant component (for example a mixer that also
announces the arrival of a new participant; the announcement portion announces the arrival of a new participant; the announcement portion
is a participant, but the mixer itself is not). Media intermediaries is a participant, but the mixer itself is not). Media intermediaries
should be as transparent as possible to the end users--offering a should be as transparent as possible to the end users--offering a
useful, fundamental service; without getting in the way of new useful, fundamental service; without getting in the way of new
skipping to change at page 17, line 28 skipping to change at page 17, line 49
Throughout this draft we discuss call control primitive operations. Throughout this draft we discuss call control primitive operations.
One of the biggest problems is defining how these operations may be One of the biggest problems is defining how these operations may be
invoked. There are a number of ways to do this. One way is to invoked. There are a number of ways to do this. One way is to
define the primitives in the protocol itself such that SIP methods define the primitives in the protocol itself such that SIP methods
(for example REFER) or SIP headers (for example Replaces) indicate a (for example REFER) or SIP headers (for example Replaces) indicate a
specific call control action. Another way to invoke call control specific call control action. Another way to invoke call control
primitives is to define a specific Request-URI naming convention. primitives is to define a specific Request-URI naming convention.
Either these conventions must be shared between the client (the Either these conventions must be shared between the client (the
invoker) and the server, or published by or on behalf of the server. invoker) and the server, or published by or on behalf of the server.
The former involves defining URL construction techniques (e.g. URL The former involves defining URI construction techniques (e.g. URI
parameters and/or token conventions) as proposed in [24]. The latter parameters and/or token conventions) as proposed in [24]. The latter
technique usually involves discovering the URI via a SIP event technique usually involves discovering the URI via a SIP event
package, a web page, a business card, or an Instant Message. Yet package, a web page, a business card, or an Instant Message. Yet
another means to acquire the URLs is to define a dictionary of another means to acquire the URIs is to define a dictionary of
primitives with well-defined semantics and provide a means to query primitives with well-defined semantics and provide a means to query
the named primitives and corresponding URLs that may be invoked on the named primitives and corresponding URIs that may be invoked on
the service or dialogs. the service or dialogs.
2.7.1. Naming Users in SIP 2.7.1. Naming Users in SIP
An address-of-record, or public SIP address, is a SIP (or SIPS) URI An address-of-record, or public SIP address, is a SIP (or SIPS) URI
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
skipping to change at page 18, line 13 skipping to change at page 18, line 35
Callee Capabilities [20] 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
that indicates whether the UA is fixed or mobile. When a user agent that 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 [21], by including the Accept-Contact and Reject-Contact Preferences [21], by including the Accept-Contact, Request-
headers that request certain handling by the proxy in the target Disposition, and Reject-Contact headers that request certain handling
domain. These headers contain preferences that describe the set of by the proxy in the target domain. These headers contain preferences
desired URIs to which the caller would like their request routed. that describe the set of desired URIs to which the caller would like
The proxy in the target domain matches these preferences with the their request routed. The proxy in the target domain matches these
Contact characteristics originally registered by the target user. preferences with the Contact characteristics originally registered by
The target user can also choose to run arbitrarily complex "Find-me" the target user. The target user can also choose to run arbitrarily
feature logic on a proxy in the target domain. complex "Find-me" 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
active role by initiating the request, the callee takes a passive active role by initiating the request, the callee takes a passive
role in waiting for requests. This motivates the use of callee- role in waiting for requests. This motivates the use of callee-
supplied scripts and caller preferences included in the call request. supplied scripts and caller preferences included in the call request.
This asymmetry is also reflected in the appropriate relationship This asymmetry is also reflected in the appropriate relationship
between caller and callee preferences. A server for a callee should between caller and callee preferences. A server for a callee should
respect the wishes of the caller to avoid certain locations, while respect the wishes of the caller to avoid certain locations, while
the preferences among locations has to be the callee's choice, as it the preferences among locations has to be the callee's choice, as it
determines where, for example, the phone rings and whether the callee determines where, for example, the phone rings and whether the callee
incurs mobile telephone charges for incoming calls. incurs mobile telephone charges for incoming calls.
SIP User Agent implementations are encouraged to make intelligent SIP User Agent implementations are encouraged to make intelligent
decisions based on the type of participants (active/passive, hidden, decisions based on the type of participants (active/passive, hidden,
human/robot) in a conversation space. This information is conveyed human/robot) in a conversation space. This information is conveyed
via the session dialog package or in a SIP header parameter via the dialog package or in a SIP header parameter communicated
communicated using an appropriate SIP header. For example, a music using an appropriate SIP header. For example, a music on hold
on hold service may take the sensible approach that if there are two service may take the sensible approach that if there are two or more
or more unhidden participants, it should not provide hold music; or unhidden participants, it should not provide hold music; or that it
that it will not send hold music to robots. will not send hold music to robots.
Multiple participants in the same conversation space may represent Multiple participants in the same conversation space may represent
the same human user. For example, the user may use one participant the same human user. For example, the user may use one participant
for video, chat, and whiteboard media on a PC and another for audio for video, chat, and whiteboard media on a PC and another for audio
media on a SIP phone. In this case, the address-of-record is the media on a SIP phone. In this case, the address-of-record is the
same for both user agents, but the Contacts are different. In same for both user agents, but the Contacts are different. In
addition, human users may add robot participants that act on their addition, human users may add robot participants that act on their
behalf (for example a call recording service, or a calendar behalf (for example a call recording service, or a calendar
reminder). Call Control features in SIP should continue to function announcement reminder). Call Control features in SIP should continue
as expected in such an environment. to function as expected in such an environment.
2.7.2. Naming Services with SIP URIs 2.7.2. Naming Services with SIP URIs
A critical piece of defining a session level service that can be A critical piece of defining a session level service that can be
accessed by SIP is defining the naming of the resources within that accessed by SIP is defining the naming of the resources within that
service. This point cannot be overstated. service. This point cannot be overstated.
In the context of SIP control of application components, we take In the context of SIP control of application components, we take
advantage of the fact that the standard SIP URI has a user part. advantage of the fact that the left-hand-side of a standard SIP URI
Most services may be thought of as user automatons that participate is a user part. Most services may be thought of as user automatons
in SIP sessions. It naturally follows that the user address, or the that participate in SIP sessions. It naturally follows that the user
left-hand-side of the URI, should be utilized as a service indicator. part should be utilized as a service indicator.
For example, media servers commonly offer multiple services at a For example, media servers commonly offer multiple services at a
single host address. Use of the user part as a service indicator single host address. Use of the user part as a service indicator
enables service consumers to direct their requests without ambiguity. enables service consumers to direct their requests without ambiguity.
It has the added benefit of enabling media services to register their It has the added benefit of enabling media services to register their
availability with SIP Registrars just as any "real" SIP user would. availability with SIP Registrars just as any "real" SIP user would.
This maintains consistency and provides enhanced flexibility in the This maintains consistency and provides enhanced flexibility in the
deployment of media services in the network. deployment of media services in the network.
There has been much discussion about the potential for confusion if There has been much discussion about the potential for confusion if
skipping to change at page 19, line 39 skipping to change at page 20, line 13
development of private or experimental services. 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, infinite space. They are plentiful, and they are free. Secondly,
the primary function of SIP is call routing through manipulations of the primary function of SIP is call routing through manipulations of
the Request-URI. In the traditional SIP application, this URI the Request-URI. In the traditional SIP application, this URI
represents people. However, the URI can also represent services, as represents a person. However, the URI can also represent a service,
we propose here. This means we can apply the routing services SIP as we propose here. This means we can apply the routing services SIP
provides to routing of calls to services. The result - the problem provides to routing of calls to services. The result - the problem
of service invocation and service location becomes a routing problem, of service invocation and service location becomes a routing problem,
for which SIP provides a scalable and flexible solution. Since there for which SIP provides a scalable and flexible solution. Since there
is such a vast namespace of services, we can explicitly name each is such a vast namespace of services, we can explicitly name each
service in a finely granular way. This allows the distribution of service in a finely granular way. This allows the distribution of
services across the network. For further discussion about services services across the network. For further discussion about services
and SIP URIs, see RFC 3087 [22] and SIP URIs, see RFC 3087 [22]
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
skipping to change at page 20, line 27 skipping to change at page 20, line 50
In practical applications, it is important that an invoker does not In practical applications, it is important that an invoker does not
necessarily apply semantic rules to various URIs it did not create. necessarily apply semantic rules to various URIs it did not create.
Instead, it should allow any arbitrary string to be provisioned, and Instead, it should allow any arbitrary string to be provisioned, and
map the string to the desired behavior. The administrator of a map the string to the desired behavior. The administrator of a
service may choose to provision specific conventions or mnemonic service may choose to provision specific conventions or mnemonic
strings, but the application should not require it. In any large strings, but the application should not require it. In any large
installation, the system owner is likely to have pre-existing rules installation, the system owner is likely to have pre-existing rules
for mnemonic URIs, and any attempt by an application to define its for mnemonic URIs, and any attempt by an application to define its
own rules may create a conflict. Implementations should allow an own rules may create a conflict. Implementations should allow an
arbitrary mix of URLs from these schemes, or any other scheme that arbitrary mix of URIs from these schemes, or any other scheme that
renders valid SIP URIs to be provisioned, rather than enforce only renders valid SIP URIs to be provisioned, rather than enforce only
one particular scheme. one particular scheme.
As we have shown, SIP URIs represent an ideal, flexible mechanism for As we have shown, SIP URIs represent an ideal, flexible mechanism for
describing and naming service resources, be they queues, conferences, describing and naming service resources, regardless if the resources
voice dialogs, announcements, voicemail treatments, or phone are queues, conferences, voice dialogs, announcements, voicemail
features. treatments, or phone features.
2.8. Invoker Independence 2.8. Invoker Independence
With functional signaling, only the invoker of features in SIP need With functional signaling, only the invoker of features in SIP need
to know exactly which feature they are invoking. One of the primary to know exactly which feature they are invoking. One of the primary
benefits of this approach is that combinations of functional features benefits of this approach is that combinations of functional features
work in SIP call control without requiring complex feature work in SIP call control without requiring complex feature
interaction matrices. For example, let us examine the combination of interaction matrices. For example, let us examine the combination of
a "transfer" of a call that is "conferenced". a "transfer" of a call that is "conferenced".
skipping to change at page 21, line 47 skipping to change at page 22, line 20
Call control actions can be categorized by the dialogs upon which Call control actions can be categorized by the dialogs upon which
they operate. The actions may involve a single or multiple dialogs. they operate. The actions may involve a single or multiple dialogs.
These dialogs can be early or established. Multiple dialogs may be These dialogs can be early or established. Multiple dialogs may be
related in a conversation space to form a conference or other related in a conversation space to form a conference or other
interesting media topologies. interesting media topologies.
It should be noted that it is desirable to provide a means by which a It should be noted that it is desirable to provide a means by which a
party can discover the actions that may be performed on a dialog. party can discover the actions that may be performed on a dialog.
The interested party may be independent or related to the dialogs. The interested party may be independent or related to the dialogs.
One means of accomplishing this is through the ability to define and One means of accomplishing this is through the ability to define and
obtain URLs for these actions as described in section . obtain URIs for these actions as described in section .
Below are listed several call control "actions" that establish or Below are listed several call control "actions" that establish or
modify dialogs and relate the participants in a conversation space. modify dialogs and relate the participants in a conversation space.
The names of the actions listed are for descriptive purposes only The names of the actions listed are for descriptive purposes only
(they are not normative). This list of actions is not meant to be (they are not normative). This list of actions is not meant to be
exhaustive. exhaustive.
In the examples, all actions are initiated by the user "Alice" In the examples, all actions are initiated by the user "Alice"
represented by UA "A". represented by UA "A".
3.1. Early Dialog Actions 3.1. Remote Call Control Actions on Early Dialogs
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 that may be out of reach. All of these the early dialog of a UA that 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 establish an early dialog. These actions provide useful
functionality for PDA, PC and server based applications that desire functionality for PDA, PC and server based applications that desire
skipping to change at page 22, line 42 skipping to change at page 23, line 15
3.1.2. Remote Forward or Put 3.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
response to forward an early dialog to another UA. response to forward an early dialog to another UA.
3.1.3. Remote Busy or Error Out 3.1.3. Remote Busy or Error Out
It may be desirable to instruct the UA to send an error response such It may be desirable to instruct the UA to send an error response such
as 486 Busy Here. as 486 Busy Here.
3.2. Single Dialog Actions 3.2. Remote Call Control Actions on Single Dialogs
There is another useful set of actions that operate on a single There is another useful set of actions that 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 that sets up calls for a user For example a Customer Relationship Management (CRM) application that
eliminating the need for the user to actually enter an address. sets up calls for a user eliminating the need for the user to
These operations can also be thought of a remote control actions. A actually enter an address. These operations can also be thought of a
proposed mechanism for this type of functionality is described in remote control actions. A proposed mechanism for this type of
Remote Call Control [23]. functionality is described in Remote Call Control [23].
3.2.1. Remote Dial 3.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.
3.2.2. Remote On and Off Hold 3.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 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 on a per media stream basis.
3.2.3. Remote Hangup 3.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 and Target- dialog. A REFER request with the following Refer-To URI and Target-
Dialog header field [26] performs this action. Note: this example Dialog header field [26] performs this action. Note: this example
does not show the full set of header fields. does not show the full set of header fields.
REFER sip:carol@client.chicago.net SIP/2.0 REFER sip:carol@client.chicago.net SIP/2.0
Refer-To: sip:bob@babylon.biloxi.example.com;method=BYE Refer-To: sip:bob@babylon.biloxi.example.com;method=BYE
Target-Dialog: 13413098;local-tag=879738;remote-tag=023214 Target-Dialog: 13413098;local-tag=879738;remote-tag=023214
3.3. Multi-dialog actions 3.3. Call Control Actions on Multiple Dialogs
These actions apply to a set of related dialogs. These actions apply to a set of related dialogs.
3.3.1. Transfer 3.3.1. Transfer
This section describes how call transfer can be achieved using
centralized (3pcc) and peer-to-peer (REFER) approaches.
The conversation space changes as follows: The conversation space changes as follows:
before after before after
{ A , B } --> { C , B } { A , B } --> { C , B }
A replaces itself with C. A replaces itself with C.
To make this happen using the peer-to-peer approach, "A" would send To make this happen using the peer-to-peer approach, "A" would send
two SIP requests. A shorthand for those requests is shown below: two SIP requests. A shorthand for those requests is shown below:
REFER B Refer-To:C REFER B Refer-To:C
BYE B BYE B
To make this happen instead using the 3pcc approach, the controller To make this happen instead using the 3pcc approach, the controller
sends requests represented by the shorthand below: sends requests represented by the shorthand below:
INVITE C (w/SDP of B) INVITE C (w/SDP of B)
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:
central mixer (some type of conference or forking) - transfer to park
server (park) - transfer to music on hold or announcement server - - blind transfer
transfer to a "queue" - transfer to a service (such as Voice Dialogs - transfer to a central mixer (some type of conference or forking)
service) - transition from local mixer to central mixer - transfer to park server (park)
- transfer to music on hold or announcement server
- transfer to a "queue"
- transfer to a service (such as Voice Dialogs 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 [18]. transfer". It is described in more detail in cc-transfer [18].
Note that if a transfer requires URI hiding or privacy, then the 3pcc
approach can more easily implement this. For example, if the URI of
C needs to be hidden from B, then the use of 3pcc helps accomplish
this.
3.3.2. Take 3.3.2. Take
The conversation space changes as follows: { B , C } --> { B , A } A The conversation space changes as follows:
forcibly replaces C with itself. In most uses of this primitive, A
is just "un-replacing" itself. Using the peer-to-peer approach, "A"
sends: INVITE B Replaces: <dialog between B and C>
Using the 3pcc approach (all requests sent from controller) INVITE A { B , C } --> { B , A }
(w/SDP of B) reINVITE B (w/SDP of A) BYE C
Features enabled by this action: - transferee completes an attended A forcibly replaces C with itself. In most uses of this primitive, A
transfer - retrieve from central mixer (not recommended) - retrieve is just "un-replacing" itself.
from music on hold or park - retrieve from queue - call center take -
voice portal resuming ownership of a call it originated - answering- Using the peer-to-peer approach, "A" sends:
machine style screening (pickup) - pickup of a ringing call (i.e.
early dialog) INVITE B Replaces: <dialog between B and C>
Using the 3pcc approach (all requests sent from controller)
INVITE A (w/SDP of B)
reINVITE B (w/SDP of A)
BYE C
Features enabled by this action:
- transferee completes an attended transfer
- retrieve from central mixer (not recommended)
- retrieve from music on hold or park
- retrieve from queue
- call center take
- voice portal resuming ownership of a call it originated
- answering-machine style screening (pickup)
- pickup of a ringing call (i.e. early dialog)
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 [18]. This action is described in Replaces [9] and in cc-transfer [18].
3.3.3. Add 3.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
[19]. [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:
adds C to the conversation. Using the peer-to-peer approach, adding
a party using local mixing requires no signaling. To transition from { A , B } --> { A , B , C }
a 2-party call or a locally mixed conference to centrally mixing A
could send the following requests: REFER B Refer-To: conference-URI A adds C to the conversation.
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 Using the peer-to-peer approach, adding a party using local mixing
the 3pcc approach to transition to centrally mixed, the controller requires no signaling. To transition from a 2-party call or a
would send: INVITE mixer leg 1 (w/SDP of A) INVITE mixer leg 2 (w/SDP locally mixed conference to centrally mixing A could send the
of B) INVITE C (late SDP) reINVITE A (w/SDP of mixer leg 1) reINVITE following requests:
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 REFER B Refer-To: conference-URI
(w/SDP of C) Features enabled: - standard conference feature - call INVITE conference-URI
recording - answering-machine style screening (screening) BYE B
To add a party to a conference:
REFER C Refer-To: conference-URI
or
REFER conference-URI Refer-To: C
Using 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 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 party to a SIP conference:
INVITE C (late SDP)
INVITE conference-URI (w/SDP of C)
Features enabled:
- standard conference feature
- call recording
- answering-machine style screening (screening)
3.3.4. Local Join 3.3.4. Local Join
The conversation space changes like this: { A, B} , {A, C} --> {A, B, The conversation space changes like this:
C} or like this { A, B} , {C, D} --> {A, B, C, D} A takes two
conversation spaces and joins them together into a single space. { A , B } , { A , C } --> { A , B , C }
or like this
{ A , B } , { C , D } --> { A , B , C , D }
A takes two conversation spaces and joins them together into a single
space.
Using the peer-to-peer approach, A can mix locally, or REFER the Using the peer-to-peer approach, A can mix locally, or REFER the
participants of both conversation spaces to the same central mixer participants of both conversation spaces to the same central mixer
(as in 5.3) For the 3pcc approach, the call flows for inserting (as in 3.3.5).
participants, and joining and splitting conversation spaces are
tedious yet straightforward, so these are left as an exercise for the For the 3pcc approach, the call flows for inserting participants, and
reader. Features enabled: - standard conference feature - leaving a joining and splitting conversation spaces are tedious yet
sidebar to rejoin a larger conference straightforward, so these are left as an exercise for the reader.
Features enabled:
- standard conference feature
- leaving a sidebar to rejoin a larger conference
3.3.5. Insert 3.3.5. Insert
The conversation space changes like this: { B , C } --> {A, B, C } A The conversation space changes like this:
inserts itself into a conversation space. A proposed mechanism for
signaling this using the peer-to-peer approach is to send a new { B , C } --> { A , B , C }
header in an INVITE with "joining" semantics. For example: INVITE B
Join: <dialog id of B and C> If B accepted the INVITE, B would accept A inserts itself into a conversation space.
responsibility to setup the dialogs and mixing necessary (for
example: to mix locally or to transfer the participants to a central A proposed mechanism for signaling this using the peer-to-peer
mixer) Features enabled: - barge-in - call center monitoring - call approach is to send a new header in an INVITE with "joining" [10]
recording semantics. For example:
INVITE B Join: <dialog id of B and C>
If B accepted the INVITE, B would accept responsibility to setup the
dialogs and mixing necessary (for example: to mix locally or to
transfer the participants to a central mixer)
Features enabled:
- barge-in
- call center monitoring
- call recording
3.3.6. Split 3.3.6. Split
{ A, B, C, D } --> { A, B } , { C, D } If using a central conference { A , B , C , D } --> { A , B } , { C , D }
with peer-to-peer REFER C Refer-To: conference-URI (new URI) REFER D
Refer-To: conference-URI (new URI) BYE C BYE D Features enabled: - If using a central conference with peer-to-peer
sidebar conversations during a larger conference REFER C Refer-To: conference-URI (new URI)
REFER D Refer-To: conference-URI (new URI)
BYE C
BYE D
Features enabled:
- sidebar conversations during a larger conference
3.3.7. Near-fork 3.3.7. Near-fork
A participates in two conversation spaces simultaneously: { A, B } A participates in two conversation spaces simultaneously:
--> { B , A } & { A , C } A is a participant in two conversation
spaces such that A sends the same media to both spaces, and renders { A, B } --> { B , A } & { A , C }
media from both spaces, presumably by mixing or rendering the media
from both. We can define that A is the "anchor" point for both A is a participant in two conversation spaces such that A sends the
forks, each of which is a separate conversation space. This action same media to both spaces, and renders media from both spaces,
is purely local implementation (it requires no special signaling). presumably by mixing or rendering the media from both. We can define
Local features such as switching calls between the background and that A is the "anchor" point for both forks, each of which is a
foreground are possible using this media relationship. separate conversation space.
This action is purely local implementation (it requires no special
signaling). Local features such as switching calls between the
background and foreground are possible using this media relationship.
3.3.8. Far fork 3.3.8. Far fork
The conversation space diagram... { A, B } --> { A , B } & { B , C } The conversation space diagram...
A requests B to be the "anchor" of two conversation spaces. This is
easily setup by creating a conference with two sub-conferences and { A, B } --> { A , B } & { B , C }
setting the media policy appropriately such that B is a participant
in both. Media forking can also be setup using 3pcc as described in A requests B to be the "anchor" of two conversation spaces.
Section 5.1 of RFC3264 [3] (an offer/answer model for SDP). The
session descriptions for forking are quite complex. Controllers This is easily setup by creating a conference with two sub-
should verify that endpoints can handle forked-media, for example conferences and setting the media policy appropriately such that B is
using prior configuration. a participant 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 session descriptions for forking are quite complex.
Controllers should verify that endpoints can handle forked-media, for
example using prior configuration.
Features enabled: Features enabled:
o barge-in
o voice portal services - barge-in
o whisper - voice portal services
o hotword detection - whisper
o sending DTMF somewhere else - hotword detection
- sending DTMF somewhere else
4. Security Considerations 4. 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 that are possible using these tools include the The class of attacks that are possible using these tools include the
ability to eavesdrop on calls, disconnect calls, redirect calls, ability to eavesdrop on calls, disconnect calls, redirect calls,
skipping to change at page 28, line 7 skipping to change at page 30, line 25
to demonstrate a useful set of primitives. They are described here to demonstrate a useful set of primitives. They are described here
briefly. Note that the descriptions of these features are non- briefly. Note that the descriptions of these features are non-
normative. Some of these features are used as examples in section 6 normative. Some of these features are used as examples in section 6
to demonstrate how some features may require certain media to demonstrate how some features may require certain media
relationships. Note also that this document describes a mixture of relationships. Note also that this document describes a mixture of
both features originating in the world of telephones, and features both features originating in the world of telephones, and features
that are clearly Internet oriented. that are clearly Internet oriented.
Example Feature Definitions: Example Feature Definitions:
Call Waiting - Alice is in a call, then receives another call. Alice Attended Transfer - The transferring party establishes a session with
can place the first call on hold, and talk with the other caller. the transfer target before completing the transfer.
She can typically switch back and forth between the callers.
Auto Answer - Calls to a certain address or location answer
immediately via a speakerphone.
Automatic Callback: Alice calls Bob, but Bob is busy. Alice would
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. Bob answers and they talk.
Barge-in - Carol interrupts Alice who has a call in-progress call
with Bob. In some variations, Alice forcibly joins a new conversation
with Carol, in other variations, all three parties are placed in the
same conversation (basically a 3-way conference).
Blind Transfer - Alice is in a conversation with Bob. Alice asks Bob Blind Transfer - Alice is in a conversation with Bob. Alice asks Bob
to contact Carol, but makes no attempt to contact Carol to contact Carol, but makes no attempt to contact Carol
independently. In many implementations, Alice does not verify Bob's independently. In many implementations, Alice does not verify Bob's
success or failure in contacting Carol. success or failure in contacting Carol.
Attended Transfer - The transferring party establishes a session with Call Forwarding - Before a dialog is accepted it is redirected to
the transfer target before completing the transfer. another location, for example, because the originally intended
recipient is busy, does not answer, is disconnected from the network,
Consultative transfer - the transferring party establishes a session configured all requests to go somewhere else.
with the target and mixes both sessions together so that all three
parties can participate, then disconnects leaving the transferee and
transfer target with an active session.
Conference Call - Three or more active, visible participants in the Call Monitoring - A call center supervisor joins an in-progress call
same conversation space. for monitoring purposes.
Call Park - A call participant parks a call (essentially puts the Call Park - A call participant parks a call (essentially puts the
call on hold), and then retrieves it at a later time (typically from call on hold), and then retrieves it at a later time (typically from
another location). another location).
Call Pickup - A party picks up a call that was ringing at another Call Pickup - A party picks up a call that was ringing at another
location. One variation allows the caller to choose which location, location. One variation allows the caller to choose which location,
another variation just picks up any call in that user's "pickup another variation just picks up any call in that user's "pickup
group". group".
Music on Hold - When Alice places a call with Bob on hold, it Call Return - Alice calls Bob. Bob misses the call or is disconnected
replaces its audio with streaming content such as music, before he is finished talking to Alice. Bob invokes Call return that
announcements, or advertisements. calls Alice, even if Alice did not provide her real identity or
location to Bob.
Call Monitoring - A call center supervisor joins an in-progress call Call Waiting - Alice is in a call, then receives another call. Alice
for monitoring purposes. can place the first call on hold, and talk with the other caller.
She can typically switch back and forth between the callers.
Barge-in - Carol interrupts Alice who has a call in-progress call Click-to-dial - Alice looks in her company directory for Bob. When
with Bob. In some variations, Alice forcibly joins a new conversation she finds Bob, she clicks on a URI to call him. Her phone rings (or
with Carol, in other variations, all three parties are placed in the possibly answers automatically), and when she answers, Bob's phone
same conversation (basically a 3-way conference). rings.
Hotline - Alice picks up a phone and is immediately connected to the Conference Call - Three or more active, visible participants in the
technical support hotline, for example. same conversation space.
Auto Answer - Calls to a certain address or location answer Consultative transfer - the transferring party establishes a session
immediately via a speakerphone. with the target and mixes both sessions together so that all three
parties can participate, then disconnects leaving the transferee and
transfer target with an active session.
Intercom - Alice typically presses a button on a phone that Distinctive ring - Incoming calls have different ring cadences or
immediately connects to another user or phone and causes that phone sample sounds depending on the From party, the To party, or other
to play her voice over its speaker. Some variations immediately factors.
setup two-way communications, other variations require another button
to be pressed to enable a two-way conversation.
Speakerphone paging - Alice calls the paging address and speaks. Her Do Not Disturb - Alice selects the Do Not Disturb option. Calls to
voice is played on the speaker of every idle phone in a preconfigured her either ring briefly or not at all and are forwarded elsewhere.
group of phones. Some variations allow specially authorized callers to override this
feature and ring Alice anyway.
Speed dial - Alice dials an abbreviated number, or enters an alias, Find-Me - Alice sets up complicated rules for how she can be reached
or presses a special speed dial button representing Bob. Her action (possibly using CPL (Lennox, J., Wu, X., and H. Schulzrinne, "Call
is interpreted as if she specified the full address of Bob. Processing Language (CPL): A Language for User Control of Internet
Telephony Services," October 2004.) [27], presence (Rosenberg, J., "A
Presence Event Package for the Session Initiation Protocol (SIP),"
August 2004.) [14], or other factors). When Bob calls Alice, his
call is eventually routed to a temporary Contact where Alice happens
to be available.
Call Return - Alice calls Bob. Bob misses the call or is disconnected Hotline - Alice picks up a phone and is immediately connected to the
before he is finished talking to Alice. Bob invokes Call return that technical support hotline, for example.
calls Alice, even if Alice did not provide her real identity or
location to Bob. IM Conference Alerts: A user receives an notification as an Instant
Message whenever someone joins a conference they are also in.
Inbound Call Screening - Alice doesn't want to receive calls from Inbound Call Screening - Alice doesn't want to receive calls from
Matt. Inbound Screening prevents Matt from disturbing Alice. In Matt. Inbound Screening prevents Matt from disturbing Alice. In
some variations this works even if Matt hides his identity. some variations this works even if Matt hides his identity.
Outbound Call Screening - Alice is paged and unknowingly calls a PSTN Intercom - Alice typically presses a button on a phone that
pay-service telephone number in the Caribbean, but local policy immediately connects to another user or phone and causes that phone
blocks her call, and possibly informs her why. to play her voice over its speaker. Some variations immediately
setup two-way communications, other variations require another button
Call Forwarding - Before a dialog is accepted it is redirected to to be pressed to enable a two-way conversation.
another location, for example, because the originally intended
recipient is busy, does not answer, is disconnected from the network,
configured all requests to go somewhere else.
Message Waiting - Bob calls Alice when she steps away from her phone, Message Waiting - Bob calls Alice when she steps away from her phone,
when she returns a visible or audible indicator conveys that someone when she returns a visible or audible indicator conveys that someone
has left her a voicemail message. The message waiting indication may has left her a voicemail message. The message waiting indication may
also convey how many messages are waiting, from whom, what time, and also convey how many messages are waiting, from whom, what time, and
other useful pieces of information. other useful pieces of information.
Do Not Disturb - Alice selects the Do Not Disturb option. Calls to Music on Hold - When Alice places a call with Bob on hold, it
her either ring briefly or not at all and are forwarded elsewhere. replaces its audio with streaming content such as music,
Some variations allow specially authorized callers to override this announcements, or advertisements.
feature and ring Alice anyway.
Distinctive ring - Incoming calls have different ring cadences or
sample sounds depending on the From party, the To party, or other
factors.
Automatic Callback: Alice calls Bob, but Bob is busy. Alice would
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. Bob answers and they talk.
Find-Me - Alice sets up complicated rules for how she can be reached
(possibly using CPL [27], presence [14], or other factors). When Bob
calls Alice, his call is eventually routed to a temporary Contact
where Alice happens to be available.
Whispered call waiting - Alice is in a conversation with Bob. Carol Outbound Call Screening - Alice is paged and unknowingly calls a PSTN
calls Alice. Either Carol can "whisper" to Alice directly ("Can you pay-service telephone number in the Caribbean, but local policy
get lunch in 15 minutes?"), or an automaton whispers to Alice blocks her call, and possibly informs her why.
informing her that Carol is trying to reach her.
Voice message screening - Bob calls Alice. Alice is screening her Pre-paid calling - Alice pays for a certain currency or unit amount
calls, so Bob hears Alice's voicemail greeting. Alice can hear Bob of calling value. When she places a call, she provides her account
leave his message. If she decides to talk to Bob, she can take the number somehow. If her account runs out of calling value during a
call back from the voicemail system, otherwise she can let Bob leave call her call is disconnected or redirected to a service where she
a message. This emulates the behavior of a home telephone answering can purchase more calling value.
machine
Presence-Enabled Conferencing: Alice wants to set up a conference Presence-Enabled Conferencing: Alice wants to set up a conference
call with Bob and Cathy when they all happen to be available (rather call with Bob and Cathy when they all happen to be available (rather
than scheduling a predefined time). The server providing the than scheduling a predefined time). The server providing the
application monitors their status, and calls all three when they are application monitors their status, and calls all three when they are
all "online", not idle, and not in another call. all "online", not idle, and not in another call.
IM Conference Alerts: A user receives an notification as an Instant
Message whenever someone joins a conference they are also in.
Single Line Extension/Multiple Line Appearance -- A group of phones Single Line Extension/Multiple Line Appearance -- A group of phones
are all treated as "extensions" of a single line. A call for one are all treated as "extensions" of a single line. A call for one
rings them all. As soon as one answers, the others stop ringing. If rings them all. As soon as one answers, the others stop ringing. If
any extension is actively in a conversation, another extension can any extension is actively in a conversation, another extension can
"pick up" and immediately join the conversation. This emulates the "pick up" and immediately join the conversation. This emulates the
behavior of a home telephone line with multiple phones. behavior of a home telephone line with multiple phones.
Click-to-dial - Alice looks in her company directory for Bob. When Speakerphone paging - Alice calls the paging address and speaks. Her
she finds Bob, she clicks on a URL to call him. Her phone rings (or voice is played on the speaker of every idle phone in a preconfigured
possibly answers automatically), and when she answers, Bob's phone group of phones.
rings.
Pre-paid calling - Alice pays for a certain currency or unit amount Speed dial - Alice dials an abbreviated number, or enters an alias,
of calling value. When she places a call, she provides her account or presses a special speed dial button representing Bob. Her action
number somehow. If her account runs out of calling value during a is interpreted as if she specified the full address of Bob.
call her call is disconnected or redirected to a service where she
can purchase more calling value. Voice message screening - Bob calls Alice. Alice is screening her
calls, so Bob hears Alice's voicemail greeting. Alice can hear Bob
leave his message. If she decides to talk to Bob, she can take the
call back from the voicemail system, otherwise she can let Bob leave
a message. This emulates the behavior of a home telephone answering
machine
Voice Portal - A service that allows users to access a portal site Voice Portal - A service that allows users to access a portal site
using spoken dialog interaction. For example, Alice needs to using spoken dialog interaction. For example, Alice needs to
schedule a working dinner with her co-worker Carol. Alice uses a schedule a working dinner with her co-worker Carol. Alice uses a
voice portal to check Carol's flight schedule, find a restaurant near voice portal to check Carol's flight schedule, find a restaurant near
her hotel, make a reservation, get directions there, and page Carol her hotel, make a reservation, get directions there, and page Carol
with this information. with this information.
Whispered call waiting - Alice is in a conversation with Bob. Carol
calls Alice. Either Carol can "whisper" to Alice directly ("Can you
get lunch in 15 minutes?"), or an automaton whispers to Alice
informing her that Carol is trying to reach her.
6.1. Implementation of these features 6.1. Implementation of these features
Example Features: Example Features:
Call Hold [service-examples]
Attended Transfer [18]
Auto Answer [28]
Automatic Callback Two person presence-based conference
Barge-in Section 6.1.1
Blind Transfer [18]
Call Forwarding Proxy or Local implementation
Call Hold [6]
Call Monitoring Section 6.1.2
Call Park Section 6.1.3, [6]
Call Pickup Section 6.1.4, [6]
Call Return Proxy feature
Call Waiting Local Implementation Call Waiting Local Implementation
Blind Transfer [cc-transfer] Click-to-dial Section 6.1.5, [6]
Attended Transfer [cc-transfer] Conference Call [19]
Consultative transfer [cc-transfer] Presence-based
Conference Call [conf-models] Conferencing [19], [14]
Call Park [cc-framework]/[service-examples] Consultative transfer [18]
Call Pickup [cc-framework]/[service-examples] Distinctive ring Section 6.1.6, Proxy or Local implementation
Music on Hold [cc-framework]/[service-examples] Do Not Disturb [14]
Call Monitoring [cc-framework] Find-Me Proxy service based on presence
Barge-in [cc-framework]/[Insert or Far-Fork
Hotline Local Implementation Hotline Local Implementation
Auto Answer [sip-answermode] IM Conference Alerts Subscribe to conference status
Speed dial Local Implementation
Intercom [cc-framework]/[sip-answermode]
Speakerphone paging [cc-framework]/Speed dial + Auto Answer
Call Return Proxy feature
Inbound Call Screening Proxy or Local implementation Inbound Call Screening Proxy or Local implementation
Intercom Section 6.1.7, [28]
Message Waiting [29]
Multiple Appearances Section 6.1.10
Music on Hold Section 6.1.8, [6]
Outbound Call Screening Proxy feature Outbound Call Screening Proxy feature
Call Forwarding Proxy or Local implementation Pre-Paid Calling Section 6.1.9
Message Waiting [msg-waiting] Single Line Extension Section 6.1.10
Do Not Disturb [presence] Speakerphone paging Section 6.1.11, Speed dial + Auto Answer
Distinctive ring [cc-framework]/Proxy or Local implementation Speed dial Local Implementation
Automatic Callback two person presence-based conference Voice Message Screening Section 6.1.12
Find-Me Proxy service based on presence Voice Portal Section 6.1.13
Whispered call waiting Local implementation Whispered call waiting Local implementation
Voice Message Screening [cc-framework]
Presence-based
Conferencing call when presence = available
IM Conference Alerts subscribe to conference status
Single Line Extension [cc-framework]
Multiple Appearances [cc-framework]
Click-to-dial [service-examples]
Pre-Paid Calling [cc-framework]
Voice Portal [cc-framework]
6.1.1. Call Park 6.1.1. Barge-in
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
other parties can hear the stream from UA barging in.
6.1.2. Call Monitoring
Call monitoring is a Join operation. The monitoring UA sends a Join
to the dialog it wants to listen to. It is able to discover the
dialog via the dialog state on the monitored UA. The monitoring UA
sends SDP in the INVITE that indicates receive only media. As the UA
is monitoring only it does not matter whether the UA indicates it
wishes the send stream be mix or point to point.
6.1.3. Call Park
Call park requires the ability to: put a dialog some place, advertise Call park requires the ability to: put a dialog some place, advertise
it to users in a pickup group and to uniquely identify it in a means it to users in a pickup group and to uniquely identify it in a means
that can be communicated (including human voice). The dialog can be that can be communicated (including human voice). The dialog can be
held locally on the UA parking the dialog or alternatively held locally on the UA parking the dialog or alternatively
transferred to the park service for the pickup group. The parked transferred to the park service for the pickup group. The parked
dialog then needs to be labeled (e.g. orbit 12) in a way that can be dialog then needs to be labeled (e.g. orbit 12) in a way that can be
communicated to the party that is to pick up the call. The UAs in communicated to the party that is to pick up the call. The UAs in
the pick up group discovers the parked dialog(s) via the dialog the pick up group discovers the parked dialog(s) via the dialog
package from the park service. If the dialog is parked locally the package from the park service. If the dialog is parked locally the
park service merely aggregates the parked call states from the set of park service merely aggregates the parked call states from the set of
UAs in the pickup up group. UAs in the pickup up group.
6.1.2. Call Pickup 6.1.4. Call Pickup
There are two different features that are called call pickup. The There are two different features that are called call pickup. The
first is the pickup of a parked dialog. The UA from which the dialog first is the pickup of a parked dialog. The UA from which the dialog
is to be picked up subscribes to the session dialog state of the park is to be picked up subscribes to the dialog state of the park service
service or the UA that has locally parked the dialog. Dialogs that or the UA that has locally parked the dialog. Dialogs that are
are parked should be labeled with an identifier. The labels are used parked should be labeled with an identifier. The labels are used by
by the UA to allow the user to indicate which dialog is to be picked the UA to allow the user to indicate which dialog is to be picked up.
up. The UA picking up the call invoked the URL in the call state The UA picking up the call invoked the URI in the call state that is
that is labeled as replace-remote. labeled as replace-remote.
The other call pickup feature involves picking up an early dialog The other call pickup feature involves picking up an early dialog
(typically ringing). This feature uses some of the same primitives (typically ringing). This feature uses some of the same primitives
as the pick up of a parked call. The call state of the UA ringing as the pick up of a parked call. The call state of the UA ringing
phone is advertised using the dialog package. The UA that is to phone is advertised using the dialog package. The UA that is to
pickup the early dialog subscribes either directly to the ringing UA pickup the early dialog subscribes either directly to the ringing UA
or to a service aggregating the states for UAs in the pickup group. or to a service aggregating the states for UAs in the pickup group.
The call state identifies early dialogs. The UA uses the call The call state identifies early dialogs. The UA uses the call
state(s) to help the user choose which early dialog that is to be state(s) to help the user choose which early dialog that is to be
picked up. The UA then invokes the URL in the call state labeled as picked up. The UA then invokes the URI in the call state labeled as
replace-remote. replace-remote.
6.1.3. Music on Hold 6.1.5. Click-to-dial
The application or server that hosts the click-to-dial application
captures the URI to be dialed and can setup the call using 3pcc or
can send a REFER request to the UA that is to dial the address. As
users sometimes change their mind or wish to give up listing to a
ringing or voicemail answered phone, this application illustrates the
need to also have the ability to remotely hangup a call.
6.1.6. Distinctive ring
The target UA either makes a local decision based on information in
an incoming INVITE (To, From, Contact, Request-URI) or trusts an
Alert-Info header provided by the caller or inserted by a trusted
proxy. In the latter case, the UA fetches the content described in
the URI (typically via http) and renders it to the user.
6.1.7. Intercom
The UA initiates a dialog using INVITE and the Answer-Mode: Auto
header field as described in [28]. The called UA accepts the INVITE
with a 200 OK and automatically enables the speakerphone.
Alternatively this can be a local decision for the UA to answer based
upon called party identification.
6.1.8. Music on Hold
Music on hold can be implemented a number of ways. One way is to Music on hold can be implemented a number of ways. One way is to
transfer the held call to a holding service. When the UA wishes to transfer the held call to a holding service. When the UA wishes to
take the call off hold it basically performs a take on the call from take the call off hold it basically performs a take on the call from
the holding service. This involves subscribing to call state on the the holding service. This involves subscribing to call state on the
holding service and then invoking the URL in the call state labeled holding service and then invoking the URI in the call state labeled
as replace-remote. as replace-remote.
Alternatively music on hold can be performed as a local mixing Alternatively music on hold can be performed as a local mixing
operation. The UA holding the call can mix in the music from the operation. The UA holding the call can mix in the music from the
music service via RTP (i.e. an additional dialog) or RTSP or other music service via RTP (i.e. an additional dialog) or RTSP or other
streaming media source. This approach is simpler (i.e. the held streaming media source. This approach is simpler (i.e. the held
dialog does not move so there is less chance of loosing them) from a dialog does not move so there is less chance of loosing them) from a
protocol perspective, however it does use more LAN bandwidth and protocol perspective, however it does use more LAN bandwidth and
resources on the UA. resources on the UA.
6.1.4. Call Monitoring 6.1.9. Pre-paid calling
Call monitoring is a Join operation. The monitoring UA sends a Join
to the dialog it wants to listen to. It is able to discover the
dialog via the dialog state on the monitored UA. The monitoring UA
sends SDP in the INVITE that indicates receive only media. As the UA
is monitoring only it does not matter whether the UA indicates it
wishes the send stream be mix or point to point.
6.1.5. Barge-in For prepaid calling, the user's media always passes through a device
that is trusted by the pre-paid provider. This may be the other
endpoint (for example a PSTN gateway). In either case, an
intermediary proxy or B2BUA can periodically verify the amount of
time available on the pre-paid account, and use the session-timer
extension to cause the trusted endpoint (gateway) or intermediary
(media relay) to send a reINVITE before that time runs out. During
the reINVITE, the SIP intermediary can re-verify the account and
insert another session-timer header.
Barge-in works the same as call monitoring except that it must Note that while most pre-paid systems on the PSTN use an IVR to
indicate that the send media stream to be mixed so that all of the collect the account number and destination, this isn't strictly
other parties can hear the stream from UA barging in. necessary for a SIP-originated prepaid call. SIP requests and SIP
URIs are sufficiently expressive to convey the final destination, the
provider of the prepaid service, the location from which the user is
calling, and the prepaid account they want to use. If a pre-paid IVR
is used, the mechanism described below (Voice Portals) can be
combined as well.
6.1.6. Intercom 6.1.10. Single Line Extension/Multiple Line Appearance
The UA initiates a dialog using INVITE and the Answer-Mode: Auto Incoming calls ring all the extensions through basic parallel
header field as described in [28]. The called UA accepts the INVITE forking. Each extension subscribes to dialog events from each other
with a 200 OK and automatically enables the speakerphone. extension. While one user has an active call, any other UA extension
can insert itself into that conversation (it already knows the dialog
information) in the same way as barge-in.
Alternatively this can be a local decision for the UA to answer based Standardization work to allow line appearance numbers to be
upon called party identification. coordinated across a group of UAs is currently underway.
6.1.7. Speakerphone paging 6.1.11. 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
speakerphone is a locally configured decision on the paged UAs. The speakerphone is a locally configured decision on the paged UAs. The
paging UA sends RTP via the multicast address indicated in the SDP. paging UA sends RTP via the multicast address indicated in the SDP.
The multipoint solution is accomplished by sending an INVITE to the The multipoint solution is accomplished by sending an INVITE to the
multipoint mixer. The mixer is configured to automatically answer multipoint mixer. The mixer is configured to automatically answer
skipping to change at page 34, line 8 skipping to change at page 37, line 45
a single REFER that is parallel forked by the proxy server). The UAs a single REFER that is parallel forked by the proxy server). The UAs
performing as paging speakers are configured to automatically answer performing as paging speakers are configured to automatically answer
based upon caller identification (e.g. To field, URI or Referred-To based upon caller identification (e.g. To field, URI or Referred-To
headers). headers).
Finally as a third option, the user agent can send a mass-invitation Finally as a third option, the user agent can send a mass-invitation
request to a conference server, which would create a conference and request to a conference server, which would create a conference and
send INVITEs containing the Answer-Mode: Auto header field to all send INVITEs containing the Answer-Mode: Auto header field to all
user agents in the paging group. user agents in the paging group.
6.1.8. Distinctive ring 6.1.12. Voice message screening
The target UA either makes a local decision based on information in
an incoming INVITE (To, From, Contact, Request-URI) or trusts an
Alert-Info header provided by the caller or inserted by a trusted
proxy. In the latter case, the UA fetches the content described in
the URI (typically via http) and renders it to the user.
6.1.9. Voice message screening
At first, this is the same as call monitoring. In this case the At first, this is the same as call monitoring. In this case the
voicemail service is one of the UAs. The UA screening the message voicemail service is one of the UAs. The UA screening the message
monitors the call on the voicemail service, and also subscribes to monitors the call on the voicemail service, and also subscribes to
dialog information. If the user screening their messages decides to dialog information. If the user screening their messages decides to
answer, they perform a Take from the voicemail system (for example, answer, they perform a Take from the voicemail system (for example,
send an INVITE with Replaces to the UA leaving the message) send an INVITE with Replaces to the UA leaving the message)
6.1.10. Single Line Extension/Multiple Line Appearance
Incoming calls ring all the extensions through basic parallel
forking. Each extension subscribes to dialog events from each other
extension. While one user has an active call, any other UA extension
can insert itself into that conversation (it already knows the dialog
information) in the same way as barge-in.
Standardization work to allow line appearance numbers to be
coordinated across a group of UAs is currently underway.
6.1.11. Click-to-dial
The application or server that hosts the click-to-dial application
captures the URL to be dialed and can setup the call using 3pcc or
can send a REFER request to the UA that is to dial the address. As
users sometimes change their mind or wish to give up listing to a
ringing or voicemail answered phone, this application illustrates the
need to also have the ability to remotely hangup a call.
6.1.12. Pre-paid calling
For prepaid calling, the user's media always passes through a device
that is trusted by the pre-paid provider. This may be the other
endpoint (for example a PSTN gateway). In either case, an
intermediary proxy or B2BUA can periodically verify the amount of
time available on the pre-paid account, and use the session-timer
extension to cause the trusted endpoint (gateway) or intermediary
(media relay) to send a reINVITE before that time runs out. During
the reINVITE, the SIP intermediary can re-verify the account and
insert another session-timer header.
Note that while most pre-paid systems on the PSTN use an IVR to
collect the account number and destination, this isn't strictly
necessary for a SIP-originated prepaid call. SIP requests and SIP
URIs are sufficiently expressive to convey the final destination, the
provider of the prepaid service, the location from which the user is
calling, and the prepaid account they want to use. If a pre-paid IVR
is used, the mechanism described below (Voice Portals) can be
combined as well.
6.1.13. Voice Portal 6.1.13. Voice Portal
A voice portal is essentially a complex collection of voice dialogs A voice portal is essentially a complex collection of voice dialogs
used to access interesting content. One of the most desirable call used to access interesting content. One of the most desirable call
control features of a Voice Portal is the ability to start a new control features of a Voice Portal is the ability to start a new
outgoing call from within the context of the Portal (to make a outgoing call from within the context of the Portal (to make a
restaurant reservation, or return a voicemail message for example). restaurant reservation, or return a voicemail message for example).
Once the new call is over, the user should be able to return to the Once the new call is over, the user should be able to return to the
Portal by pressing a special key, using some DTMF sequence (ex: a Portal by pressing a special key, using some DTMF sequence (ex: a
very long pound or hash tone), or by speaking a hotword (ex: "Main very long pound or hash tone), or by speaking a hotword (ex: "Main
skipping to change at page 35, line 43 skipping to change at page 38, line 31
{ User , Voice Portal } { User , Voice Portal }
The user then asks to make an outgoing call. The Voice Portal asks The user then asks to make an outgoing call. The Voice Portal asks
the User to perform a Far-Fork. In other words the Voice Portal the User to perform a Far-Fork. In other words the Voice Portal
wants the following media relationship: wants the following media relationship:
{ Target , User } & { User , Voice Portal } { Target , User } & { User , Voice Portal }
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 that presents them with the appropriate menu again. DTMF sequence that presents them with the appropriate menu again.
7. Informative References 7. Acknowledgements
Thanks to AC Mahendran, John Elwell, and Xavier Marjou for their
detailed Working Group review of the document.
8. Informative 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., Jacobson, V., and C. Perkins, "SDP: Session [5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[6] Johnston, A., "Session Initiation Protocol Service Examples", [6] Johnston, A., "Session Initiation Protocol Service Examples",
draft-ietf-sipping-service-examples-12 (work in progress), draft-ietf-sipping-service-examples-13 (work in progress),
January 2007. July 2007.
[7] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, [7] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in "Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, the Session Initiation Protocol (SIP)", BCP 85, RFC 3725,
April 2004. April 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] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation [9] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
skipping to change at page 37, line 20 skipping to change at page 40, line 13
Session Initiation Protocol (SIP)", Session Initiation Protocol (SIP)",
draft-ietf-sipping-app-interaction-framework-05 (work in draft-ietf-sipping-app-interaction-framework-05 (work in
progress), July 2005. progress), July 2005.
[17] Camarillo, G., "Framework for Transcoding with the Session [17] Camarillo, G., "Framework for Transcoding with the Session
Initiation Protocol (SIP)", Initiation Protocol (SIP)",
draft-ietf-sipping-transc-framework-05 (work in progress), draft-ietf-sipping-transc-framework-05 (work in progress),
December 2006. December 2006.
[18] Sparks, R., "Session Initiation Protocol Call Control - [18] Sparks, R., "Session Initiation Protocol Call Control -
Transfer", draft-ietf-sipping-cc-transfer-07 (work in Transfer", draft-ietf-sipping-cc-transfer-08 (work in
progress), October 2006. progress), July 2007.
[19] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) [19] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP)
Call Control - Conferencing for User Agents", BCP 119, Call Control - Conferencing for User Agents", BCP 119,
RFC 4579, August 2006. RFC 4579, August 2006.
[20] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating [20] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
User Agent Capabilities in the Session Initiation Protocol User Agent Capabilities in the Session Initiation Protocol
(SIP)", RFC 3840, August 2004. (SIP)", RFC 3840, August 2004.
[21] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller [21] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)", Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004. RFC 3841, August 2004.
[22] 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.
[23] Jennings, C. and R. Mahy, "Remote Call Control in the Session [23] Jennings, C. and R. Mahy, "Remote Call Control in the Session
Initiation Protocol (SIP) using the REFER method and the Initiation Protocol (SIP) using the REFER method and the
session-oriented dialog package", draft-mahy-sip-remote-cc-04 session-oriented dialog package", draft-mahy-sip-remote-cc-05
(work in progress), October 2006. (work in progress), March 2007.
[24] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media [24] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media
Services with SIP", RFC 4240, December 2005. Services with SIP", RFC 4240, December 2005.
[25] Jennings, C., Audet, F., and J. Elwell, "Session Initiation [25] Jennings, C., Audet, F., and J. Elwell, "Session Initiation
Protocol (SIP) URIs for Applications such as Voicemail and Protocol (SIP) URIs for Applications such as Voicemail and
Interactive Voice Response (IVR)", RFC 4458, April 2006. Interactive Voice Response (IVR)", RFC 4458, April 2006.
[26] Rosenberg, J., "Request Authorization through Dialog [26] Rosenberg, J., "Request Authorization through Dialog
Identification in the Session Initiation Protocol (SIP)", Identification in the Session Initiation Protocol (SIP)",
RFC 4538, June 2006. RFC 4538, June 2006.
[27] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing [27] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing
Language (CPL): A Language for User Control of Internet Language (CPL): A Language for User Control of Internet
Telephony Services", RFC 3880, October 2004. Telephony Services", RFC 3880, October 2004.
[28] Willis, D. and A. Allen, "Requesting Answering Modes for the [28] Willis, D. and A. Allen, "Requesting Answering Modes for the
Session Initiation Protocol (SIP)", Session Initiation Protocol (SIP)",
draft-ietf-sip-answermode-01 (work in progress), May 2006. draft-ietf-sip-answermode-06 (work in progress),
September 2007.
[29] Mahy, R., "A Message Summary and Message Waiting Indication
Event Package for the Session Initiation Protocol (SIP)",
RFC 3842, August 2004.
Authors' Addresses Authors' Addresses
Rohan Mahy Rohan Mahy
Plantronics Plantronics
345 Encincal Street 345 Encincal Street
Santa Cruz, CA Santa Cruz, CA
USA USA
Email: rohan@ekabal.com Email: rohan@ekabal.com
 End of changes. 118 change blocks. 
418 lines changed or deleted 548 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/