draft-ietf-sipping-cc-framework-09.txt   draft-ietf-sipping-cc-framework-10.txt 
SIPPING WG R. Mahy SIPPING WG R. Mahy
Internet-Draft Plantronics Internet-Draft Plantronics
Intended status: Informational R. Sparks Intended status: Informational R. Sparks
Expires: May 31, 2008 Estacado Systems Expires: October 18, 2008 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
November 28, 2007 April 16, 2008
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-09 draft-ietf-sipping-cc-framework-10
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 42 skipping to change at page 1, line 42
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 May 31, 2008. This Internet-Draft will expire on October 18, 2008.
Copyright Notice
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 call control
usage of SIP. To enable discussion of multi-party features and and multi-party usage of SIP. To enable discussion of multi-party
applications we define an abstract call model for describing the features and applications we define an abstract call model for
media relationships required by many of these. The model and actions describing the media relationships required by many of these. The
described here are specifically chosen to be independent of the SIP model and actions described here are specifically chosen to be
signaling and/or mixing approach chosen to actually setup the media independent of the SIP signaling and/or mixing approach chosen to
relationships. In addition to its dialog manipulation aspect, this actually setup the media relationships. In addition to its dialog
framework includes requirements for communicating related information manipulation aspect, this framework includes requirements for
and events such as conference and session state, and session history. communicating related information and events such as conference and
This framework also describes other goals that embody the spirit of session state, and session history. This framework also describes
SIP applications as used on the Internet. other goals that embody the spirit of 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. Relationship Between Conversation Space, SIP Dialogs, 2.2. Relationship Between Conversation Space, SIP Dialogs,
and SIP Sessions . . . . . . . . . . . . . . . . . . . . . 7 and SIP Sessions . . . . . . . . . . . . . . . . . . . . . 7
2.3. Signaling Models . . . . . . . . . . . . . . . . . . . . . 8 2.3. Signaling Models . . . . . . . . . . . . . . . . . . . . . 8
2.4. Mixing Models . . . . . . . . . . . . . . . . . . . . . . 9 2.4. Mixing Models . . . . . . . . . . . . . . . . . . . . . . 9
skipping to change at page 2, line 46 skipping to change at page 2, line 40
2.6.5. Queue Server . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . 21 2.8. Invoker Independence . . . . . . . . . . . . . . . . . . . 21
2.9. Billing issues . . . . . . . . . . . . . . . . . . . . . . 21 2.9. Billing issues . . . . . . . . . . . . . . . . . . . . . . 21
3. Catalog of call control actions and sample features . . . . . 22 3. Catalog of call control actions and sample features . . . . . 22
3.1. Remote Call Control Actions on Early Dialogs . . . . . . . 22 3.1. Remote Call Control Actions on Early Dialogs . . . . . . . 22
3.1.1. Remote Answer . . . . . . . . . . . . . . . . . . . . 22 3.1.1. Remote Answer . . . . . . . . . . . . . . . . . . . . 23
3.1.2. Remote Forward or Put . . . . . . . . . . . . . . . . 23 3.1.2. Remote Forward or Put . . . . . . . . . . . . . . . . 23
3.1.3. Remote Busy or Error Out . . . . . . . . . . . . . . . 23 3.1.3. Remote Busy or Error Out . . . . . . . . . . . . . . . 23
3.2. Remote Call Control Actions on Single Dialogs . . . . . . 23 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. Call Control Actions on Multiple Dialogs . . . . . . . . . 24 3.3. Call Control Actions on Multiple Dialogs . . . . . . . . . 24
3.3.1. Transfer . . . . . . . . . . . . . . . . . . . . . . . 24 3.3.1. Transfer . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.2. Take . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.3.2. Take . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.3. Add . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.3.3. Add . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.4. Local Join . . . . . . . . . . . . . . . . . . . . . . 26 3.3.4. Local Join . . . . . . . . . . . . . . . . . . . . . . 27
3.3.5. Insert . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3.5. Insert . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.6. Split . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3.6. Split . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.7. Near-fork . . . . . . . . . . . . . . . . . . . . . . 28 3.3.7. Near-fork . . . . . . . . . . . . . . . . . . . . . . 28
3.3.8. Far fork . . . . . . . . . . . . . . . . . . . . . . . 28 3.3.8. Far fork . . . . . . . . . . . . . . . . . . . . . . . 28
4. Security Considerations . . . . . . . . . . . . . . . . . . . 29 4. Security Considerations . . . . . . . . . . . . . . . . . . . 29
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
6. Appendix A: Example Features . . . . . . . . . . . . . . . . . 30 6. Appendix A: Example Features . . . . . . . . . . . . . . . . . 30
6.1. Implementation of these features . . . . . . . . . . . . . 33 6.1. Implementation of these features . . . . . . . . . . . . . 33
6.1.1. Barge-in . . . . . . . . . . . . . . . . . . . . . . . 34 6.1.1. Barge-in . . . . . . . . . . . . . . . . . . . . . . . 34
6.1.2. Call Monitoring . . . . . . . . . . . . . . . . . . . 34 6.1.2. Call Monitoring . . . . . . . . . . . . . . . . . . . 34
6.1.3. Call Park . . . . . . . . . . . . . . . . . . . . . . 35 6.1.3. Call Park . . . . . . . . . . . . . . . . . . . . . . 35
6.1.4. Call Pickup . . . . . . . . . . . . . . . . . . . . . 35 6.1.4. Call Pickup . . . . . . . . . . . . . . . . . . . . . 35
skipping to change at page 3, line 34 skipping to change at page 3, line 29
6.1.7. Intercom . . . . . . . . . . . . . . . . . . . . . . . 36 6.1.7. Intercom . . . . . . . . . . . . . . . . . . . . . . . 36
6.1.8. Music on Hold . . . . . . . . . . . . . . . . . . . . 36 6.1.8. Music on Hold . . . . . . . . . . . . . . . . . . . . 36
6.1.9. Pre-paid calling . . . . . . . . . . . . . . . . . . . 36 6.1.9. Pre-paid calling . . . . . . . . . . . . . . . . . . . 36
6.1.10. Single Line Extension/Multiple Line Appearance . . . . 37 6.1.10. Single Line Extension/Multiple Line Appearance . . . . 37
6.1.11. Speakerphone paging . . . . . . . . . . . . . . . . . 37 6.1.11. Speakerphone paging . . . . . . . . . . . . . . . . . 37
6.1.12. Voice message screening . . . . . . . . . . . . . . . 37 6.1.12. Voice message screening . . . . . . . . . . . . . . . 37
6.1.13. Voice Portal . . . . . . . . . . . . . . . . . . . . . 38 6.1.13. Voice Portal . . . . . . . . . . . . . . . . . . . . . 38
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
8. Informative References . . . . . . . . . . . . . . . . . . . . 38 8. Informative References . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 42 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 [RFC3261] (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 call control
usage of SIP. Most multi-party operations manipulate SIP dialogs and multi-party usage of SIP. Most multi-party operations manipulate
(also known as call legs) or SIP conference media policy to cause SIP dialogs (also known as call legs) or SIP conference media policy
participants in a conversation to perceive specific media to cause 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 so that when they are combined with eachother, they can be robust so that when they are combined with eachother, they can be
used to build lots of services. However, the goal is not to used to build lots of services. However, the goal is not to
define a provably complete set of primitives. Note that while the define a provably complete set of primitives. Note that while the
IETF will NOT standardize behavior or services, it may define IETF will NOT standardize behavior or services, it may define
example services for informational purposes, as in service example services for informational purposes, as in service
examples [6]. examples [I-D.ietf-sipping-service-examples].
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 [RFC3725], and the SIP community has expressed a
deal of interest in peer-to-peer or distributed call control using great deal of interest in peer-to-peer or distributed call control
primitives such as those defined in REFER [8], Replaces [9], and using primitives such as those defined in REFER [RFC3515],
Join [10]. Replaces [RFC3891], and Join [RFC3911].
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 of the same type in an appropriate, refers to combining media of the same type in an appropriate,
media-specific way. This is consistent with model described in media-specific way. This is consistent with model described in
skipping to change at page 6, line 15 skipping to change at page 6, line 15
o Include authentication, authorization, policy, logging, and o Include authentication, authorization, policy, logging, and
accounting mechanisms to allow these primitives to be used safely accounting mechanisms to allow these primitives to be used safely
among mutually untrusted participants. Some of these mechanisms among mutually untrusted participants. Some of these mechanisms
may be used to assist in billing, but no specific billing system may be used to assist in billing, but no specific billing system
will be endorsed. will be endorsed.
o Permit graceful fallback to baseline SIP. Definitions for new SIP o Permit graceful fallback to baseline SIP. Definitions for new SIP
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
[CSTA] call model, as these other models do not share the design call model, as these other models do not share the design goals
goals presented in this document. presented in this document.
2. Key Concepts 2. Key Concepts
This section introduces a number of key concepts which will be used This section introduces a number of key concepts which will be used
to describe and explain various call control operations and services to describe and explain various call control operations and services
in the remainder of this document. This includes the conversation in the remainder of this document. This includes the conversation
space model, signaling and mixing models, common components, and the space model, signaling and mixing models, common components, and the
use of URIs. use of URIs.
2.1. "Conversation Space" Model 2.1. "Conversation Space" Model
skipping to change at page 7, line 48 skipping to change at page 7, line 48
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
[5] both define a conference as "a multimedia session identified by a [RFC4566] both define a conference as "a multimedia session
common session description." A session is defined as "a set of identified by a common session description." A session is defined as
multimedia senders and receivers and the data streams flowing from "a set of multimedia senders and receivers and the data streams
senders to receivers." Both of these definitions are heavily flowing from senders to receivers." Both of these definitions are
oriented toward multicast sessions with little differentiation among heavily oriented toward multicast sessions with little
participants. As such, neither is particularly useful for our differentiation among participants. As such, neither is particularly
purposes. In fact, the definition of "call" in some call models is useful for our purposes. In fact, the definition of "call" in some
more similar to our definition of a conversation space. call models is more similar to our definition of a conversation
space.
Some examples of the relationship between conversation spaces, SIP Some examples of the relationship between conversation spaces, SIP
dialogs, and SIP sessions are listed below. In each example, a human dialogs, and SIP sessions are listed below. In each example, a human
user will perceive that there is a single call. user will perceive that there is a single call.
o A simple two-party call is a single conversation space, a single o A simple two-party call is a single conversation space, a single
session, and a single dialog. session, and a single dialog.
o A locally mixed three-way call is two sessions and two dialogs. o A locally mixed three-way call is two sessions and two dialogs.
It is also a single conversation space. It is also a single conversation space.
o A simple dial-in audio conference is a single conversation space, o A simple dial-in audio conference is a single conversation space,
but is represented by as many dialogs and sessions as there are but is represented by as many dialogs and sessions as there are
skipping to change at page 8, line 36 skipping to change at page 8, line 37
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 a centralized control model. One conversation space model using a centralized control model. One
common way to implement this using SIP is known as 3rd Party Call common way to implement this using SIP is known as 3rd Party Call
Control (3pcc) and is described in 3pcc [7]. The 3pcc approach Control (3pcc) and is described in 3pcc [RFC3725]. The 3pcc approach
relies on only the following 3 primitive operations: 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
skipping to change at page 9, line 11 skipping to change at page 9, line 12
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 are required to be sent by
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 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, 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 directly between the two UAs. The 3pcc approach results in two SIP
skipping to change at page 9, line 37 skipping to change at page 9, line 36
controller does not, the feature will not be able to be used. 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 [RFC4353] and cc-conferencing [RFC4579]. SIP
both tightly-coupled and loosely-coupled conferencing, although more supports both tightly-coupled and loosely-coupled conferencing,
sophisticated behavior is available in tightly-coupled conferences. although more sophisticated behavior is available in tightly-coupled
In a tightly-coupled conference, a single SIP user agent (called the conferences. In a tightly-coupled conference, a single SIP user
focus) has a direct dialog relationship with each participant (and agent (called the focus) has a direct dialog relationship with each
may control non participant user agents as well). In a loosely- participant (and may control non participant user agents as well).
coupled conference there is no coordinated signaling relationships In a loosely-coupled conference there is no coordinated signaling
among the participants. relationships among the participants.
For brevity, only the two most popular conferencing models are For brevity, only the two most popular conferencing models are
significantly discussed in this document (local and centralized significantly discussed in this document (local and centralized
mixing). Applications of the conversation spaces model to loosely- mixing). Applications of the conversation spaces model to loosely-
coupled multicast and distributed full unicast mesh conferences are coupled multicast and distributed full unicast mesh conferences are
left as an exercise for the reader. Note that a distributed full left as an exercise for the reader. Note that a distributed full
mesh conference can be used for basic conferences, but does not mesh conference can be used for basic conferences, but does not
easily allow for more complex conferencing actions like splitting, easily allow for more complex conferencing actions like splitting,
merging, and sidebars. merging, and sidebars.
skipping to change at page 10, line 19 skipping to change at page 10, line 18
call, or drop all the participants (for example if only two call, or drop all the participants (for example if only two
automatons are communicating). The actual heuristics used to release automatons are communicating). The actual heuristics used to release
calls are beyond the scope of this document, but may depend on calls are beyond the scope of this document, but may depend on
properties in the conversation space, such as the number of active, properties in the conversation space, such as the number of active,
passive, or hidden participants; and the send-only, receive-only, or passive, or hidden participants; and the send-only, receive-only, or
send-and-receive orientation of various participants. send-and-receive orientation of various participants.
2.4.1. Tightly Coupled 2.4.1. Tightly Coupled
Tightly coupled conferences utilize a central point for signaling and Tightly coupled conferences utilize a central point for signaling and
authentication known as a focus [15]. The actual media can be authentication known as a focus [RFC4353]. The actual media can be
centrally mixed or distributed. centrally mixed or distributed.
2.4.1.1. (Single) End System Mixing 2.4.1.1. (Single) End System Mixing
The first model we call "end system mixing". In this model, user A The first model we call "end system mixing". In this model, user A
calls user B, and they have a conversation. At some point later, A calls user B, and they have a conversation. At some point later, A
decides to conference in user C. To do this, A calls C, using a decides to conference in user C. To do this, A calls C, using a
completely separate SIP call. This call uses a different Call-ID, completely separate SIP call. This call uses a different Call-ID,
different tags, etc. There is no call set up directly between B and different tags, etc. There is no call set up directly between B and
C. No SIP extension or external signaling is needed. A merely C. No SIP extension or external signaling is needed. A merely
skipping to change at page 11, line 36 skipping to change at page 11, line 36
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 [RFC4566] and SIP. In a
scale multicast conference, one or more multicast addresses are large- scale multicast conference, one or more multicast addresses
allocated to the conference. Each participant joins those multicast are allocated to the conference. Each participant joins those
groups, and sends their media to those groups. Signaling is not sent multicast groups, and sends their media to those groups. Signaling
to the multicast groups. The sole purpose of the signaling is to is not sent to the multicast groups. The sole purpose of the
inform participants of which multicast groups to join. Large-scale signaling is to inform participants of which multicast groups to
multicast conferences are usually pre-arranged, with specific start join. Large-scale multicast conferences are usually pre-arranged,
and stop times. However, multicast conferences do not need to be with specific start and stop times. However, multicast conferences
pre-arranged, so long as a mechanism exists to dynamically obtain a do not need to be pre-arranged, so long as a mechanism exists to
multicast address. dynamically obtain a 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 signaling relationship with every media relationship and a pairwise signaling relationship with every
other 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 signaling relationships is <n> participants the number of media and signaling relationships is
skipping to change at page 12, line 31 skipping to change at page 12, line 31
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 dialog and conference state, but is not requires information on dialog and conference state, but is 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 URIs 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 [RFC3265] 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 dialogs, Event packages are needed to provide the status of a user's dialogs,
provide the status of conferences and its participants, provide user provide the status of conferences and its participants, provide user
presence information, provide the status of registrations, and presence information, provide the status of registrations, and
provide the status of user's messages. While this is not an provide the status of user's messages. While this is not an
exhaustive list, these are sufficient to enable the sample features exhaustive list, these are sufficient to enable the sample features
described in this document. described in this document.
The conference event package [12] allows users to subscribe to The conference event package [RFC4575] 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 URI identifying each user, their status in the space (active, SIP URI identifying each user, their status in the space (active,
declined, departed), URIs 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 dialog package [11] provides information about all the dialogs The dialog package [RFC4235] provides information about all the
the target user is maintaining, what conversations the user in dialogs the target user is maintaining, what conversations the user
participating in, and how these are correlated. Likewise the in participating in, and how these are correlated. Likewise the
registration package [13] provides notifications when contacts have registration package [RFC3680] provides notifications when contacts
changed for a specific address-of-record. The combination of these have changed for a specific address-of-record. The combination of
allows a user agent to learn about all conversations occurring for these allows a user agent to learn about all conversations occurring
the entire registered contact set for an address-of-record. for 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 [RFC3856] has a close relationship
these later two event packages. It is fundamental to the presence with these later two event packages. It is fundamental to the
model that the information used to obtain user presence is presence 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 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
skipping to change at page 13, line 43 skipping to change at page 13, line 43
response. Frequently additional information about a call or dialog response. Frequently additional information about a call or dialog
can be fetched via non-SIP URIs. For example, consider a web page can be fetched via non-SIP URIs. For example, consider a web page
for package tracking when calling a delivery company, or a web page for package tracking when calling a delivery company, or a web page
with related documentation when joining a dial-in conference. The with related documentation when joining a dial-in conference. The
use of URIs in the multiparty framework is discussed in more detail use of URIs in the multiparty framework is discussed in more detail
in Section 3.7. in Section 3.7.
Finally the interaction of SIP with stimulus-signaling-based Finally the interaction of SIP with stimulus-signaling-based
applications, that allow a user agent to interact with an application applications, that allow a user agent to interact with an application
without knowledge of the semantics of that application, is discussed without knowledge of the semantics of that application, is discussed
in the SIP application interaction framework [16]. Stimulus in the SIP application interaction framework
signaling can occur to a user interface running locally with the [I-D.ietf-sipping-app-interaction-framework]. Stimulus signaling can
client, or to a remote user interface, through media streams. occur to a user interface running locally with the client, or to a
Stimulus signaling encompasses a wide range of mechanisms, ranging remote user interface, through media streams. Stimulus signaling
from clicking on hyperlinks, to pressing buttons, to traditional Dual encompasses a wide range of mechanisms, ranging from clicking on
Tone Multi Frequency (DTMF) input. In all cases, stimulus signaling hyperlinks, to pressing buttons, to traditional Dual Tone Multi
is supported through the use of markup languages, which play a key Frequency (DTMF) input. In all cases, stimulus signaling is
role in that framework. supported through the use of markup languages, which play a key role
in that framework.
2.6. Componentization and Decomposition 2.6. Componentization and Decomposition
This framework proposes a decomposed component architecture with a This framework proposes a decomposed component architecture with a
very loose coupling of services and components. This means that a very loose coupling of services and components. This means that a
service (such as a conferencing server or an auto-attendant) need not service (such as a conferencing server or an auto-attendant) need not
be implemented as an actual server. Rather, these services can be be implemented as an actual server. Rather, these services can be
built by combining a few basic components in straightforward or built by combining a few basic components in straightforward or
arbitrarily complex ways. arbitrarily complex ways.
skipping to change at page 15, line 11 skipping to change at page 15, line 11
configuration, while a text mixer might interleave text messages on a configuration, while a text mixer might interleave text messages on a
per-line basis. More details about how to manipulate the media per-line basis. More details about how to manipulate the media
policy used by mixers is being discussed in the XCON Working Group. policy used by mixers is being discussed in the XCON Working Group.
2.6.3. Transcoder 2.6.3. Transcoder
A transcoder translates media from one encoding or format to another A transcoder translates media from one encoding or format to another
(for example, GSM voice to G.711, MPEG2 to H.261, or text/html to (for example, GSM voice to G.711, MPEG2 to H.261, or text/html to
text/plain), or from one media type to another (for example text to text/plain), or from one media type to another (for example text to
speech). A more thorough discussion of transcoding is described in speech). A more thorough discussion of transcoding is described in
SIP transcoding services invocation [17]. SIP transcoding services invocation
[I-D.ietf-sipping-transc-framework].
2.6.4. Media Relay 2.6.4. Media Relay
A media relay terminates media and simply forwards it to a new A media relay terminates media and simply forwards it to a new
destination without changing the content in any way. Sometimes media destination without changing the content in any way. Sometimes media
relays are used to provide source IP address anonymity, to facilitate relays are used to provide source IP address anonymity, to facilitate
middlebox traversal, or to provide a trusted entity where media can middlebox traversal, or to provide a trusted entity where media can
be forcefully disconnected. be forcefully disconnected.
2.6.5. Queue Server 2.6.5. Queue Server
skipping to change at page 15, line 50 skipping to change at page 15, line 51
advertisements. Such a service could be further decomposed such that advertisements. Such a service could be further decomposed such that
announcements or music are handled by a separate component. announcements or music are handled by a separate component.
2.6.7. Announcements and Voice Dialogs 2.6.7. Announcements and Voice Dialogs
An announcement server is a server that can play digitized media An announcement server is a server that can play digitized media
(frequently audio), such as music or recorded speech. These servers (frequently audio), such as music or recorded speech. These servers
are typically accessible via SIP, HTTP, or RTSP. An analogous are typically accessible via SIP, HTTP, or RTSP. An analogous
service is a recording service that stores digitized media. A service is a recording service that stores digitized media. A
convention for specifying announcements in SIP URIs is described in convention for specifying announcements in SIP URIs is described in
[24]. Likewise the same server could easily provide a service that [RFC4240]. Likewise the same server could easily provide a service
records digitized media. that records digitized media.
A "voice dialog" is a model of spoken interactive behavior between a A "voice dialog" is a model of spoken interactive behavior between a
human and an automaton that can include synthesized speech, digitized human and an automaton that can include synthesized speech, digitized
audio, recognition of spoken and DTMF key input, recording of spoken audio, recognition of spoken and DTMF key input, recording of spoken
input, and interaction with call control. Voice dialogs frequently input, and interaction with call control. Voice dialogs frequently
consist of forms or menus. Forms present information and gather consist of forms or menus. Forms present information and gather
input; menus offer choices of what to do next. input; menus offer choices of what to do next.
Spoken dialogs are a basic building block of applications that use Spoken dialogs are a basic building block of applications that use
voice. Consider for example that a voice mail system, the voice. Consider for example that a voice mail system, the
skipping to change at page 16, line 32 skipping to change at page 16, line 32
when separated as a component, it provides greater opportunity for when separated as a component, it provides greater opportunity for
broad reuse. Automatic Speech Recognition (ASR) is a service that broad reuse. Automatic Speech Recognition (ASR) is a service that
attempts to decipher digitized speech based on a proposed grammar. attempts to decipher digitized speech based on a proposed grammar.
Like TTS, ASR services can be embedded, or exposed so that many Like TTS, ASR services can be embedded, or exposed so that many
applications can take advantage of such services. A standardized applications can take advantage of such services. A standardized
(decomposed) interface to access standalone TTS and ASR services is (decomposed) interface to access standalone TTS and ASR services is
currently being developed in the SPEECHSC Working Group. currently being developed in the SPEECHSC Working Group.
2.6.7.2. VoiceXML 2.6.7.2. VoiceXML
[VoiceXML] is a W3C recommendation that was designed to give authors VoiceXML is a W3C recommendation that was designed to give authors
control over the spoken dialog between users and applications. The control over the spoken dialog between users and applications. The
application and user take turns speaking: the application prompts the application and user take turns speaking: the application prompts the
user, and the user in turn responds. Its major goal is to bring the user, and the user in turn responds. Its major goal is to bring the
advantages of web-based development and content delivery to advantages of web-based development and content delivery to
interactive voice response applications. We believe that VoiceXML interactive voice response applications. We believe that VoiceXML
represents the ideal partner for SIP in the development of represents the ideal partner for SIP in the development of
distributed IVR servers. VoiceXML is an XML based scripting language distributed IVR servers. VoiceXML is an XML based scripting language
for describing IVR services at an abstract level. VoiceXML supports for describing IVR services at an abstract level. VoiceXML supports
DTMF recognition, speech recognition, text-to-speech, and playing out DTMF recognition, speech recognition, text-to-speech, and playing out
of recorded media files. The results of the data collected from the of recorded media files. The results of the data collected from the
skipping to change at page 18, line 4 skipping to change at page 18, line 4
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 URI construction techniques (e.g. URI 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 [RFC4240]. The
technique usually involves discovering the URI via a SIP event latter 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 URIs 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 URIs 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
sip:bob@biloxi.example.com -> sip:bob@babylon.biloxi.example.com:5060 sip:bob@biloxi.example.com -> sip:bob@babylon.biloxi.example.com:5060
sip:bbrown@mailbox.provider.example.net sip:bbrown@mailbox.provider.example.net
sip:+1.408.555.6789@mobile.example.net sip:+1.408.555.6789@mobile.example.net
Callee Capabilities [20] defines a set of additional parameters to Callee Capabilities [RFC3840] defines a set of additional parameters
the Contact header that define the characteristics of the user agent to the Contact header that define the characteristics of the user
at the specified URI. For example, there is a mobility parameter agent at the specified URI. For example, there is a mobility
that indicates whether the UA is fixed or mobile. When a user agent parameter that indicates whether the UA is fixed or mobile. When a
registers, it places these parameters in the Contact headers to user agent registers, it places these parameters in the Contact
characterize the URIs it is registering. This allows a proxy for headers to characterize the URIs it is registering. This allows a
that domain to have information about the contact addresses for that proxy for that domain to have information about the contact addresses
user. for that 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, Request- Preferences [RFC3841], by including the Accept-Contact, Request-
Disposition, and Reject-Contact headers that request certain handling Disposition, and Reject-Contact headers that request certain handling
by the proxy in the target domain. These headers contain preferences by the proxy in the target domain. These headers contain preferences
that describe the set of desired URIs to which the caller would like that describe the set of desired URIs to which the caller would like
their request routed. The proxy in the target domain matches these their request routed. The proxy in the target domain matches these
preferences with the Contact characteristics originally registered by preferences with the Contact characteristics originally registered by
the target user. The target user can also choose to run arbitrarily the target user. The target user can also choose to run arbitrarily
complex "Find-me" 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
skipping to change at page 20, line 21 skipping to change at page 20, line 21
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 a person. However, the URI can also represent a service, represents a person. However, the URI can also represent a service,
as 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 [RFC3087]
Consider a conferencing service, where we have separated the names of Consider a conferencing service, where we have separated the names of
ad-hoc conferences from scheduled conferences, we can program proxies ad-hoc conferences from scheduled conferences, we can program proxies
to route calls for ad-hoc conferences to one set of servers, and to route calls for ad-hoc conferences to one set of servers, and
calls for scheduled ones to another, possibly even in a different calls for scheduled ones to another, possibly even in a different
provider. In fact, since each conference itself is given a URI, we provider. In fact, since each conference itself is given a URI, we
can distribute conferences across servers, and easily guarantee that can distribute conferences across servers, and easily guarantee that
calls for the same conference always get routed to the same server. calls for the same conference always get routed to the same server.
This is in stark contrast to conferences in the telephone network, This is in stark contrast to conferences in the telephone network,
where the equivalent of the URI - the phone number - is scarce. An where the equivalent of the URI - the phone number - is scarce. An
entire conferencing provider generally has one or two numbers. entire conferencing provider generally has one or two numbers.
Conference IDs must be obtained through IVR interactions with the Conference IDs must be obtained through IVR interactions with the
caller, or through a human attendant. This makes it difficult to caller, or through a human attendant. This makes it difficult to
distribute conferences across servers all over the network, since the distribute conferences across servers all over the network, since the
PSTN routing only knows about the dialed number. PSTN routing only knows about the dialed number.
For more examples, consider the URI conventions of RFC 4240 [24] for For more examples, consider the URI conventions of RFC 4240 [RFC4240]
media servers and RFC 4458 [25] for voicemail and IVR systems. for media servers and RFC 4458 [RFC4458] for voicemail and IVR
systems.
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
skipping to change at page 22, line 43 skipping to change at page 22, line 45
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
the ability to control a UA. A proposed mechanism for this type of the ability to control a UA. A proposed mechanism for this type of
functionality is described in Remote Call Control [23]. functionality is described in Remote Call Control
[I-D.mahy-sip-remote-cc].
3.1.1. Remote Answer 3.1.1. Remote Answer
A dialog is in some early dialog state such as 180 Ringing. It may A dialog is in some early dialog state such as 180 Ringing. It may
be desirable to tell the UA to answer the dialog. That is tell it to be desirable to tell the UA to answer the dialog. That is tell it to
send a 200 Ok response to establish the dialog. send a 200 Ok response to establish the dialog.
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
skipping to change at page 23, line 24 skipping to change at page 23, line 30
3.2. Remote Call Control Actions on Single Dialogs 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 Customer Relationship Management (CRM) application that For example a Customer Relationship Management (CRM) application that
sets up calls for a user eliminating the need for the user to sets up calls for a user eliminating the need for the user to
actually enter an address. These operations can also be thought of a actually enter an address. These operations can also be thought of a
remote control actions. A proposed mechanism for this type of remote control actions. A proposed mechanism for this type of
functionality is described in Remote Call Control [23]. functionality is described in Remote Call Control
[I-D.mahy-sip-remote-cc].
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 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 on a per media stream basis. 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 [RFC4538] performs this action. Note: this
does not show the full set of header fields. example 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. Call Control Actions on Multiple Dialogs 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
skipping to change at page 24, line 45 skipping to change at page 24, line 49
- blind transfer - blind transfer
- transfer to a central mixer (some type of conference or forking) - transfer to a central mixer (some type of conference or forking)
- transfer to park server (park) - transfer to park server (park)
- transfer to music on hold or announcement server - transfer to music on hold or announcement server
- transfer to a "queue" - transfer to a "queue"
- transfer to a service (such as Voice Dialogs service) - transfer to a service (such as Voice Dialogs service)
- transition from local mixer to central mixer - 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
[I-D.ietf-sipping-cc-transfer].
Note that if a transfer requires URI hiding or privacy, then the 3pcc 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 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 C needs to be hidden from B, then the use of 3pcc helps accomplish
this. this.
3.3.2. Take 3.3.2. Take
The conversation space changes as follows: The conversation space changes as follows:
skipping to change at page 25, line 44 skipping to change at page 25, line 47
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 [RFC3891] and in cc-transfer
[I-D.ietf-sipping-cc-transfer].
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]. [RFC4579].
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: conversation space changes as follows:
{ A , B } --> { A , B , C } { A , B } --> { A , B , C }
A adds C to the conversation. A adds C to the conversation.
Using the peer-to-peer approach, adding a party using local mixing Using the peer-to-peer approach, adding a party using local mixing
requires no signaling. To transition from a 2-party call or a requires no signaling. To transition from a 2-party call or a
skipping to change at page 27, line 31 skipping to change at page 27, line 40
3.3.5. Insert 3.3.5. Insert
The conversation space changes like this: The conversation space changes like this:
{ B , C } --> { A , B , C } { B , C } --> { A , B , C }
A inserts itself into a conversation space. A inserts itself into a conversation space.
A proposed mechanism for signaling this using the peer-to-peer A proposed mechanism for signaling this using the peer-to-peer
approach is to send a new header in an INVITE with "joining" [10] approach is to send a new header in an INVITE with "joining"
semantics. For example: [RFC3911] semantics. For example:
INVITE B Join: <dialog id of B and C> INVITE B Join: <dialog id of B and C>
If B accepted the INVITE, B would accept responsibility to setup the If B accepted the INVITE, B would accept responsibility to setup the
dialogs and mixing necessary (for example: to mix locally or to dialogs and mixing necessary (for example: to mix locally or to
transfer the participants to a central mixer) transfer the participants to a central mixer)
Features enabled: Features enabled:
- barge-in - barge-in
skipping to change at page 28, line 40 skipping to change at page 28, line 51
The conversation space diagram... The conversation space diagram...
{ A, B } --> { A , B } & { B , C } { A, B } --> { A , B } & { B , C }
A requests B to be the "anchor" of two conversation spaces. A requests B to be the "anchor" of two conversation spaces.
This is easily setup by creating a conference with two sub- This is easily setup by creating a conference with two sub-
conferences and setting the media policy appropriately such that B is conferences and setting the media policy appropriately such that B is
a participant in both. Media forking can also be setup using 3pcc as 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 described in Section 5.1 of RFC3264 [RFC3264] (an offer/answer model
SDP). The session descriptions for forking are quite complex. for SDP). The session descriptions for forking are quite complex.
Controllers should verify that endpoints can handle forked-media, for Controllers should verify that endpoints can handle forked-media, for
example using prior configuration. example using prior configuration.
Features enabled: Features enabled:
- barge-in - barge-in
- voice portal services - voice portal services
- whisper - whisper
- hotword detection - hotword detection
- sending DTMF somewhere else - sending DTMF somewhere else
skipping to change at page 31, line 49 skipping to change at page 32, line 13
Distinctive ring - Incoming calls have different ring cadences or Distinctive ring - Incoming calls have different ring cadences or
sample sounds depending on the From party, the To party, or other sample sounds depending on the From party, the To party, or other
factors. factors.
Do Not Disturb - Alice selects the Do Not Disturb option. Calls to Do Not Disturb - Alice selects the Do Not Disturb option. Calls to
her either ring briefly or not at all and are forwarded elsewhere. her either ring briefly or not at all and are forwarded elsewhere.
Some variations allow specially authorized callers to override this Some variations allow specially authorized callers to override this
feature and ring Alice anyway. feature and ring Alice anyway.
Find-Me - Alice sets up complicated rules for how she can be reached Find-Me - Alice sets up complicated rules for how she can be reached
(possibly using CPL (Lennox, J., Wu, X., and H. Schulzrinne, "Call (possibly using CPL (Call Processing Language) [RFC3880], presence
Processing Language (CPL): A Language for User Control of Internet RFC3856 [RFC3264], or other factors). When Bob calls Alice, his call
Telephony Services," October 2004.) [27], presence (Rosenberg, J., "A is eventually routed to a temporary Contact where Alice happens to be
Presence Event Package for the Session Initiation Protocol (SIP)," available.
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.
Hotline - Alice picks up a phone and is immediately connected to the Hotline - Alice picks up a phone and is immediately connected to the
technical support hotline, for example. technical support hotline, for example.
IM Conference Alerts: A user receives an notification as an Instant IM Conference Alerts: A user receives an notification as an Instant
Message whenever someone joins a conference they are also in. 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.
skipping to change at page 34, line 5 skipping to change at page 34, line 5
Whispered call waiting - Alice is in a conversation with Bob. Carol Whispered call waiting - Alice is in a conversation with Bob. Carol
calls Alice. Either Carol can "whisper" to Alice directly ("Can you calls Alice. Either Carol can "whisper" to Alice directly ("Can you
get lunch in 15 minutes?"), or an automaton whispers to Alice get lunch in 15 minutes?"), or an automaton whispers to Alice
informing her that Carol is trying to reach her. informing her that Carol is trying to reach her.
6.1. Implementation of these features 6.1. Implementation of these features
Example Features: Example Features:
Attended Transfer [18] Attended Transfer [I-D.ietf-sipping-cc-transfer]
Auto Answer [28] Auto Answer [I-D.ietf-sip-answermode]
Automatic Callback Two person presence-based conference Automatic Callback Two person presence-based conference
Barge-in Section 6.1.1 Barge-in Section 6.1.1
Blind Transfer [18] Blind Transfer [I-D.ietf-sipping-cc-transfer]
Call Forwarding Proxy or Local implementation Call Forwarding Proxy or Local implementation
Call Hold [6] Call Hold [I-D.ietf-sipping-service-examples]
Call Monitoring Section 6.1.2 Call Monitoring Section 6.1.2
Call Park Section 6.1.3, [6] Call Park Sec 6.1.3, [I-D.ietf-sipping-service-examples]
Call Pickup Section 6.1.4, [6] Call Pickup Sec 6.1.4, [I-D.ietf-sipping-service-examples]
Call Return Proxy feature Call Return Proxy feature
Call Waiting Local Implementation Call Waiting Local Implementation
Click-to-dial Section 6.1.5, [6] Click-to-dial Sec 6.1.5, [I-D.ietf-sipping-service-examples]
Conference Call [19] Conference Call [RFC4579]
Presence-based Presence-based
Conferencing [19], [14] Conferencing [RFC4579], [RFC3856]
Consultative transfer [18] Consultative transfer [I-D.ietf-sipping-cc-transfer]
Distinctive ring Section 6.1.6, Proxy or Local implementation Distinctive ring Section 6.1.6, Proxy or Local implementation
Do Not Disturb [14] Do Not Disturb [RFC3856]
Find-Me Proxy service based on presence Find-Me Proxy service based on presence
Hotline Local Implementation Hotline Local Implementation
IM Conference Alerts Subscribe to conference status IM Conference Alerts Subscribe to conference status
Inbound Call Screening Proxy or Local implementation Inbound Call Screening Proxy or Local implementation
Intercom Section 6.1.7, [28] Intercom Section 6.1.7, [I-D.ietf-sip-answermode]
Message Waiting [29] Message Waiting [RFC3842]
Multiple Appearances Section 6.1.10 Multiple Appearances Section 6.1.10
Music on Hold Section 6.1.8, [6] Music on Hold Sec 6.1.8, [I-D.ietf-sipping-service-examples]
Outbound Call Screening Proxy feature Outbound Call Screening Proxy feature
Pre-Paid Calling Section 6.1.9 Pre-Paid Calling Section 6.1.9
Single Line Extension Section 6.1.10 Single Line Extension Section 6.1.10
Speakerphone paging Section 6.1.11, Speed dial + Auto Answer Speakerphone paging Section 6.1.11, Speed dial + Auto Answer
Speed dial Local Implementation Speed dial Local Implementation
Voice Message Screening Section 6.1.12 Voice Message Screening Section 6.1.12
Voice Portal Section 6.1.13 Voice Portal Section 6.1.13
Whispered call waiting Local implementation Whispered call waiting Local implementation
6.1.1. Barge-in 6.1.1. Barge-in
skipping to change at page 36, line 16 skipping to change at page 36, line 16
The target UA either makes a local decision based on information in The target UA either makes a local decision based on information in
an incoming INVITE (To, From, Contact, Request-URI) or trusts an an incoming INVITE (To, From, Contact, Request-URI) or trusts an
Alert-Info header provided by the caller or inserted by a trusted Alert-Info header provided by the caller or inserted by a trusted
proxy. In the latter case, the UA fetches the content described in proxy. In the latter case, the UA fetches the content described in
the URI (typically via http) and renders it to the user. the URI (typically via http) and renders it to the user.
6.1.7. Intercom 6.1.7. Intercom
The UA initiates a dialog using INVITE and the Answer-Mode: Auto The UA initiates a dialog using INVITE and the Answer-Mode: Auto
header field as described in [28]. The called UA accepts the INVITE header field as described in [I-D.ietf-sip-answermode]. The called
with a 200 OK and automatically enables the speakerphone. 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 Alternatively this can be a local decision for the UA to answer based
upon called party identification. upon called party identification.
6.1.8. Music on Hold 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
skipping to change at page 38, line 47 skipping to change at page 38, line 48
7. Acknowledgements 7. Acknowledgements
The authors would like to acknowledge Ben Campbell for his The authors would like to acknowledge Ben Campbell for his
contributions to the document and thank AC Mahendran, John Elwell, contributions to the document and thank AC Mahendran, John Elwell,
and Xavier Marjou for their detailed Working Group review of the and Xavier Marjou for their detailed Working Group review of the
document. document.
8. Informative References 8. Informative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: A., Peterson, J., Sparks, R., Handley, M., and E.
Session Initiation Protocol", RFC 3261, June 2002.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Schooler, "SIP: Session Initiation Protocol", RFC 3261,
Levels", BCP 14, RFC 2119, March 1997. June 2002.
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
Session Description Protocol (SDP)", RFC 3264, June 2002. with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Notification", RFC 3265, June 2002. Event Notification", RFC 3265, June 2002.
[5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] 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", [I-D.ietf-sipping-service-examples]
draft-ietf-sipping-service-examples-13 (work in progress), Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
July 2007. K. Summers, "Session Initiation Protocol Service
Examples", draft-ietf-sipping-service-examples-14 (work in
progress), February 2008.
[7] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
"Best Current Practices for Third Party Call Control (3pcc) in Camarillo, "Best Current Practices for Third Party Call
the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, Control (3pcc) in the Session Initiation Protocol (SIP)",
April 2004. BCP 85, RFC 3725, April 2004.
[8] Sparks, R., "The Session Initiation Protocol (SIP) Refer [RFC3515] 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 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. Protocol (SIP) "Replaces" Header", RFC 3891,
September 2004.
[10] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol
"Join" Header", RFC 3911, October 2004. (SIP) "Join" Header", RFC 3911, October 2004.
[11] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005. Protocol (SIP)", RFC 4235, November 2005.
[12] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference State", Initiation Protocol (SIP) Event Package for Conference
RFC 4575, August 2006. State", RFC 4575, August 2006.
[13] Rosenberg, J., "A Session Initiation Protocol (SIP) Event [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004. Package for Registrations", RFC 3680, March 2004.
[14] Rosenberg, J., "A Presence Event Package for the Session [RFC3856] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004. Initiation Protocol (SIP)", RFC 3856, August 2004.
[15] Rosenberg, J., "A Framework for Conferencing with the Session [RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Initiation Protocol (SIP)", RFC 4353, February 2006. Session Initiation Protocol (SIP)", RFC 4353,
February 2006.
[16] Rosenberg, J., "A Framework for Application Interaction in the [I-D.ietf-sipping-app-interaction-framework]
Session Initiation Protocol (SIP)", Rosenberg, J., "A Framework for Application Interaction in
the 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 [I-D.ietf-sipping-transc-framework]
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 - [I-D.ietf-sipping-cc-transfer]
Transfer", draft-ietf-sipping-cc-transfer-08 (work in Sparks, R., "Session Initiation Protocol Call Control -
progress), July 2007. Transfer", draft-ietf-sipping-cc-transfer-09 (work in
progress), December 2007.
[19] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
Call Control - Conferencing for User Agents", BCP 119, (SIP) Call Control - Conferencing for User Agents",
RFC 4579, August 2006. BCP 119, RFC 4579, August 2006.
[20] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
User Agent Capabilities in the Session Initiation Protocol "Indicating User Agent Capabilities in the Session
(SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
[21] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller [RFC3841] 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 [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context
SIP Request-URI", RFC 3087, April 2001. using SIP Request-URI", RFC 3087, April 2001.
[23] Jennings, C. and R. Mahy, "Remote Call Control in the Session [I-D.mahy-sip-remote-cc]
Initiation Protocol (SIP) using the REFER method and the Jennings, C. and R. Mahy, "Remote Call Control in the
session-oriented dialog package", draft-mahy-sip-remote-cc-05 Session Initiation Protocol (SIP) using the REFER method
(work in progress), March 2007. and the session-oriented dialog package",
draft-mahy-sip-remote-cc-05 (work in progress),
March 2007.
[24] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
Services with SIP", RFC 4240, December 2005. Media Services with SIP", RFC 4240, December 2005.
[25] Jennings, C., Audet, F., and J. Elwell, "Session Initiation [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session
Protocol (SIP) URIs for Applications such as Voicemail and Initiation Protocol (SIP) URIs for Applications such as
Interactive Voice Response (IVR)", RFC 4458, April 2006. Voicemail and Interactive Voice Response (IVR)", RFC 4458,
April 2006.
[26] Rosenberg, J., "Request Authorization through Dialog [RFC4538] 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 [RFC3880] 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 [I-D.ietf-sip-answermode]
Session Initiation Protocol (SIP)", Willis, D. and A. Allen, "Requesting Answering Modes for
the Session Initiation Protocol (SIP)",
draft-ietf-sip-answermode-06 (work in progress), draft-ietf-sip-answermode-06 (work in progress),
September 2007. September 2007.
[29] Mahy, R., "A Message Summary and Message Waiting Indication [RFC3842] Mahy, R., "A Message Summary and Message Waiting
Event Package for the Session Initiation Protocol (SIP)", Indication Event Package for the Session Initiation
RFC 3842, August 2004. 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
skipping to change at page 42, line 7 skipping to change at page 43, line 7
Email: dpetrie@sipez.com Email: dpetrie@sipez.com
Alan Johnston (editor) Alan Johnston (editor)
Avaya Avaya
Email: alan@sipstation.com Email: alan@sipstation.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 42, line 44 skipping to change at line 1969
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 83 change blocks. 
201 lines changed or deleted 214 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/