draft-ietf-sipping-cc-framework-04.txt   draft-ietf-sipping-cc-framework-05.txt 
SIPPING WG R. Mahy SIPPING WG R. Mahy
Internet-Draft Airespace Internet-Draft SIP Edge LLC
Expires: August 2, 2005 B. Campbell Expires: April 4, 2006 B. Campbell
Estacado Systems
R. Sparks R. Sparks
XTen Estacado Systems
J. Rosenberg J. Rosenberg
Cisco Systems Cisco Systems
D. Petrie D. Petrie
Pingtel SIP EZ
A. Johnston A. Johnston
MCI MCI
Feb 2005 Oct 2005
A Call Control and Multi-party usage framework for the Session A Call Control and Multi-party usage framework for the Session
Initiation Protocol (SIP) Initiation Protocol (SIP)
draft-ietf-sipping-cc-framework-04.txt draft-ietf-sipping-cc-framework-05.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at 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 August 2, 2005. This Internet-Draft will expire on April 4, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document defines a framework and requirements for multi-party This document defines a framework and requirements for multi-party
usage of SIP. To enable discussion of multi-party features and usage of SIP. To enable discussion of multi-party features and
applications we define an abstract call model for describing the applications we define an abstract call model for describing the
media relationships required by many of these. The model and actions media relationships required by many of these. The model and actions
described here are specifically chosen to be independent of the SIP described here are specifically chosen to be independent of the SIP
signaling and/or mixing approach chosen to actually setup the media signaling and/or mixing approach chosen to actually setup the media
relationships. In addition to its dialog manipulation aspect, this relationships. In addition to its dialog manipulation aspect, this
framework includes requirements for communicating related information framework includes requirements for communicating related information
and events such as conference and session state, and session history. and events such as conference and session state, and session history.
This framework also describes other goals which embody the spirit of This framework also describes other goals which embody the spirit of
skipping to change at page 2, line 29 skipping to change at page 2, line 25
Table of Contents Table of Contents
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation and Background . . . . . . . . . . . . . . . . . 4 2. Motivation and Background . . . . . . . . . . . . . . . . . 4
3. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 "Conversation Space" Model . . . . . . . . . . . . . . . . 6 3.1 "Conversation Space" Model . . . . . . . . . . . . . . . . 6
3.2 Comparison with Related Definitions . . . . . . . . . . . 7 3.2 Comparison with Related Definitions . . . . . . . . . . . 7
3.3 Signaling Models . . . . . . . . . . . . . . . . . . . . . 8 3.3 Signaling Models . . . . . . . . . . . . . . . . . . . . . 8
3.4 Mixing Models . . . . . . . . . . . . . . . . . . . . . . 9 3.4 Mixing Models . . . . . . . . . . . . . . . . . . . . . . 9
3.4.1 Tightly Coupled . . . . . . . . . . . . . . . . . . . 9 3.4.1 Tightly Coupled . . . . . . . . . . . . . . . . . . . 10
3.4.2 Loosely Coupled . . . . . . . . . . . . . . . . . . . 10 3.4.2 Loosely Coupled . . . . . . . . . . . . . . . . . . . 10
3.5 Conveying Information and Events . . . . . . . . . . . . . 11 3.5 Conveying Information and Events . . . . . . . . . . . . . 11
3.6 Componentization and Decomposition . . . . . . . . . . . . 13 3.6 Componentization and Decomposition . . . . . . . . . . . . 13
3.6.1 Media Intermediaries . . . . . . . . . . . . . . . . . 13 3.6.1 Media Intermediaries . . . . . . . . . . . . . . . . . 14
3.6.2 Mixer . . . . . . . . . . . . . . . . . . . . . . . . 14 3.6.2 Mixer . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6.3 Transcoder . . . . . . . . . . . . . . . . . . . . . . 14 3.6.3 Transcoder . . . . . . . . . . . . . . . . . . . . . . 14
3.6.4 Media Relay . . . . . . . . . . . . . . . . . . . . . 14 3.6.4 Media Relay . . . . . . . . . . . . . . . . . . . . . 14
3.6.5 Queue Server . . . . . . . . . . . . . . . . . . . . . 14 3.6.5 Queue Server . . . . . . . . . . . . . . . . . . . . . 14
3.6.6 Parking Place . . . . . . . . . . . . . . . . . . . . 14 3.6.6 Parking Place . . . . . . . . . . . . . . . . . . . . 15
3.6.7 Announcements and Voice Dialogs . . . . . . . . . . . 15 3.6.7 Announcements and Voice Dialogs . . . . . . . . . . . 15
3.7 Use of URIs . . . . . . . . . . . . . . . . . . . . . . . 16 3.7 Use of URIs . . . . . . . . . . . . . . . . . . . . . . . 17
3.7.1 Naming Users in SIP . . . . . . . . . . . . . . . . . 17 3.7.1 Naming Users in SIP . . . . . . . . . . . . . . . . . 17
3.7.2 Naming Services with SIP URIs . . . . . . . . . . . . 18 3.7.2 Naming Services with SIP URIs . . . . . . . . . . . . 19
3.8 Invoker Independence . . . . . . . . . . . . . . . . . . . 22 3.8 Invoker Independence . . . . . . . . . . . . . . . . . . . 22
3.9 Billing issues . . . . . . . . . . . . . . . . . . . . . . 23 3.9 Billing issues . . . . . . . . . . . . . . . . . . . . . . 23
4. Catalog of call control actions and sample features . . . . 23 4. Catalog of call control actions and sample features . . . . 23
4.1 Early Dialog Actions . . . . . . . . . . . . . . . . . . . 24 4.1 Early Dialog Actions . . . . . . . . . . . . . . . . . . . 24
4.1.1 Remote Answer . . . . . . . . . . . . . . . . . . . . 24 4.1.1 Remote Answer . . . . . . . . . . . . . . . . . . . . 24
4.1.2 Remote Forward or Put . . . . . . . . . . . . . . . . 24 4.1.2 Remote Forward or Put . . . . . . . . . . . . . . . . 24
4.1.3 Remote Busy or Error Out . . . . . . . . . . . . . . . 24 4.1.3 Remote Busy or Error Out . . . . . . . . . . . . . . . 24
4.2 Single Dialog Actions . . . . . . . . . . . . . . . . . . 24 4.2 Single Dialog Actions . . . . . . . . . . . . . . . . . . 24
4.2.1 Remote Dial . . . . . . . . . . . . . . . . . . . . . 24 4.2.1 Remote Dial . . . . . . . . . . . . . . . . . . . . . 24
4.2.2 Remote On and Off Hold . . . . . . . . . . . . . . . . 25 4.2.2 Remote On and Off Hold . . . . . . . . . . . . . . . . 25
skipping to change at page 3, line 14 skipping to change at page 3, line 12
4.3 Multi-dialog actions . . . . . . . . . . . . . . . . . . . 25 4.3 Multi-dialog actions . . . . . . . . . . . . . . . . . . . 25
4.3.1 Transfer . . . . . . . . . . . . . . . . . . . . . . . 25 4.3.1 Transfer . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.2 Take . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.3.2 Take . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.3 Add . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.3.3 Add . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.4 Local Join . . . . . . . . . . . . . . . . . . . . . . 27 4.3.4 Local Join . . . . . . . . . . . . . . . . . . . . . . 27
4.3.5 Insert . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3.5 Insert . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.6 Split . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3.6 Split . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.7 Near-fork . . . . . . . . . . . . . . . . . . . . . . 27 4.3.7 Near-fork . . . . . . . . . . . . . . . . . . . . . . 27
4.3.8 Far fork . . . . . . . . . . . . . . . . . . . . . . . 28 4.3.8 Far fork . . . . . . . . . . . . . . . . . . . . . . . 28
5. Security Considerations . . . . . . . . . . . . . . . . . . 28 5. Security Considerations . . . . . . . . . . . . . . . . . . 28
6. Appendix A: Example Features . . . . . . . . . . . . . . . . 29 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29
6.1 Implementation of these features . . . . . . . . . . . . . 33 7. Appendix A: Example Features . . . . . . . . . . . . . . . . 29
6.1.1 Call Park . . . . . . . . . . . . . . . . . . . . . . 33 7.1 Implementation of these features . . . . . . . . . . . . . 33
6.1.2 Call Pickup . . . . . . . . . . . . . . . . . . . . . 34 7.1.1 Call Park . . . . . . . . . . . . . . . . . . . . . . 33
6.1.3 Music on Hold . . . . . . . . . . . . . . . . . . . . 34 7.1.2 Call Pickup . . . . . . . . . . . . . . . . . . . . . 34
6.1.4 Call Monitoring . . . . . . . . . . . . . . . . . . . 34 7.1.3 Music on Hold . . . . . . . . . . . . . . . . . . . . 34
6.1.5 Barge-in . . . . . . . . . . . . . . . . . . . . . . . 35 7.1.4 Call Monitoring . . . . . . . . . . . . . . . . . . . 34
6.1.6 Intercom . . . . . . . . . . . . . . . . . . . . . . . 35 7.1.5 Barge-in . . . . . . . . . . . . . . . . . . . . . . . 35
6.1.7 Speakerphone paging . . . . . . . . . . . . . . . . . 35 7.1.6 Intercom . . . . . . . . . . . . . . . . . . . . . . . 35
6.1.8 Distinctive ring . . . . . . . . . . . . . . . . . . . 35 7.1.7 Speakerphone paging . . . . . . . . . . . . . . . . . 35
6.1.9 Voice message screening . . . . . . . . . . . . . . . 36 7.1.8 Distinctive ring . . . . . . . . . . . . . . . . . . . 35
6.1.10 Single Line Extension . . . . . . . . . . . . . . . 36 7.1.9 Voice message screening . . . . . . . . . . . . . . . 36
6.1.11 Click-to-dial . . . . . . . . . . . . . . . . . . . 36 7.1.10 Single Line Extension . . . . . . . . . . . . . . . 36
6.1.12 Pre-paid calling . . . . . . . . . . . . . . . . . . 36 7.1.11 Click-to-dial . . . . . . . . . . . . . . . . . . . 36
6.1.13 Voice Portal . . . . . . . . . . . . . . . . . . . . 37 7.1.12 Pre-paid calling . . . . . . . . . . . . . . . . . . 36
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 7.1.13 Voice Portal . . . . . . . . . . . . . . . . . . . . 37
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 37 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.2 Informational References . . . . . . . . . . . . . . . . . . 39 8.1 Normative References . . . . . . . . . . . . . . . . . . . 37
8.2 Informational References . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . 41 Intellectual Property and Copyright Statements . . . . . . . 41
1. Conventions 1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [2]. document are to be interpreted as described in RFC-2119 [2].
2. Motivation and Background 2. Motivation and Background
skipping to change at page 9, line 24 skipping to change at page 9, line 28
3.4 Mixing Models 3.4 Mixing Models
SIP permits a variety of mixing models, which are discussed here SIP permits a variety of mixing models, which are discussed here
briefly. This topic is discussed more thoroughly in the SIP briefly. This topic is discussed more thoroughly in the SIP
conferencing framework [15] and cc-conferencing [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
sophisticated behavior is available in tightly-coupled conferences. sophisticated behavior is available in tightly-coupled conferences.
In a tightly-coupled conference, a single SIP user agent (called the In a tightly-coupled conference, a single SIP user agent (called the
focus) has a direct dialog relationship with each participant (and focus) has a direct dialog relationship with each participant (and
may control non participant user agents as well). In a may control non participant user agents as well). In a loosely-
loosely-coupled conference there is no coordinated signaling coupled conference there is no coordinated signaling relationships
relationships among the participants. 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 mixing). Applications of the conversation spaces model to loosely-
loosely-coupled multicast and distributed full unicast mesh coupled multicast and distributed full unicast mesh conferences are
conferences are left as an exercise for the reader. Note that a left as an exercise for the reader. Note that a distributed full
distributed full mesh conference can be used for basic conferences, mesh conference can be used for basic conferences, but does not
but does not easily allow for more complex conferencing actions like easily allow for more complex conferencing actions like splitting,
splitting, merging, and sidebars. merging, and sidebars.
Call control features should be designed to allow a mixer (local or Call control features should be designed to allow a mixer (local or
centralized) to decide when to reduce a conference back to a 2-party centralized) to decide when to reduce a conference back to a 2-party
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.
skipping to change at page 16, line 46 skipping to change at page 17, line 13
Figure : Decomposed VoiceXML Server Figure : Decomposed VoiceXML Server
3.7 Use of URIs 3.7 Use of URIs
All naming in SIP uses URIs. URIs in SIP are used in a plethora of All naming in SIP uses URIs. URIs in SIP are used in a plethora of
contexts: the Request-URI; Contact, To, From, and *-Info headers; contexts: the Request-URI; Contact, To, From, and *-Info headers;
application/uri bodies; and embedded in email, web pages, instant application/uri bodies; and embedded in email, web pages, instant
messages, and ENUM records. The request-URI identifies the user or messages, and ENUM records. The request-URI identifies the user or
service that the call is destined for. service that the call is destined for.
SIP URIs embedded in informational SIP headers, SIP bodies, and SIP URIs embedded in informational SIP headers, SIP bodies, and non-
non-SIP content can also specify methods, special parameters, SIP content can also specify methods, special parameters, headers,
headers, and even bodies. For example: and even bodies. For example:
sip:bob@babylon.biloxi.com;method=BYE?Call-ID=13413098 sip:bob@babylon.biloxi.com;method=BYE?Call-ID=13413098
&To=<sip:bob@biloxi.com>;tag=879738 &To=<sip:bob@biloxi.com>;tag=879738
&From=<sip:alice@atlanta.com>;tag=023214 &From=<sip:alice@atlanta.com>;tag=023214
sip:bob@babylon.biloxi.com;method=REFER? sip:bob@babylon.biloxi.com;method=REFER?
Refer-To=<http://www.atlanta.com/~alice> Refer-To=<http://www.atlanta.com/~alice>
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
skipping to change at page 18, line 16 skipping to change at page 18, line 28
domain. These headers contain preferences that describe the set of domain. These headers contain preferences that describe the set of
desired URIs to which the caller would like their request routed. desired URIs to which the caller would like their request routed.
The proxy in the target domain matches these preferences with the The proxy in the target domain matches these preferences with the
Contact characteristics originally registered by the target user. Contact characteristics originally registered by the target user.
The target user can also choose to run arbitrarily complex "Find-me" The target user can also choose to run arbitrarily complex "Find-me"
feature logic on a proxy in the target domain. feature logic on a proxy in the target domain.
There is a strong asymmetry in how preferences for callers and There is a strong asymmetry in how preferences for callers and
callees can be presented to the network. While a caller takes an callees can be presented to the network. While a caller takes an
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 role in waiting for requests. This motivates the use of callee-
callee-supplied scripts and caller preferences included in the call supplied scripts and caller preferences included in the call
request. This asymmetry is also reflected in the appropriate request. This asymmetry is also reflected in the appropriate
relationship between caller and callee preferences. A server for a relationship between caller and callee preferences. A server for a
callee should respect the wishes of the caller to avoid certain callee should respect the wishes of the caller to avoid certain
locations, while the preferences among locations has to be the locations, while the preferences among locations has to be the
callee's choice, as it determines where, for example, the phone rings callee's choice, as it determines where, for example, the phone rings
and whether the callee incurs mobile telephone charges for incoming and whether the callee incurs mobile telephone charges for incoming
calls. 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,
skipping to change at page 26, line 23 skipping to change at page 26, line 23
A forcibly replaces C with itself. In most uses of this primitive, A A forcibly replaces C with itself. In most uses of this primitive, A
is just "un-replacing" itself. Using the peer-to-peer approach, "A" is just "un-replacing" itself. Using the peer-to-peer approach, "A"
sends: INVITE B Replaces: <call leg between B and C> sends: INVITE B Replaces: <call leg between B and C>
Using the 3pcc approach (all requests sent from controller) INVITE A Using the 3pcc approach (all requests sent from controller) INVITE A
(w/SDP of B) reINVITE B (w/SDP of A) BYE C (w/SDP of B) reINVITE B (w/SDP of A) BYE C
Features enabled by this action: - transferee completes an attended Features enabled by this action: - transferee completes an attended
transfer - retrieve from central mixer (not recommended) - retrieve transfer - retrieve from central mixer (not recommended) - retrieve
from music on hold or park - retrieve from queue - call center take - from music on hold or park - retrieve from queue - call center take -
voice portal resuming ownership of a call it originated - voice portal resuming ownership of a call it originated - answering-
answering-machine style screening (pickup) - pickup of a ringing call machine style screening (pickup) - pickup of a ringing call (i.e.
(i.e. early dialog) 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.
skipping to change at page 28, line 10 skipping to change at page 28, line 10
media from both spaces, presumably by mixing or rendering the media media from both spaces, presumably by mixing or rendering the media
from both. We can define that A is the "anchor" point for both from both. We can define that A is the "anchor" point for both
forks, each of which is a separate conversation space. This action forks, each of which is a separate conversation space. This action
is purely local implementation (it requires no special signaling). is purely local implementation (it requires no special signaling).
Local features such as switching calls between the background and Local features such as switching calls between the background and
foreground are possible using this media relationship. foreground are possible using this media relationship.
4.3.8 Far fork 4.3.8 Far fork
The conversation space diagram... { A, B } --> { A , B } & { B , C The conversation space diagram... { A, B } --> { A , B } & { B , C }
} A requests B to be the "anchor" of two conversation spaces. This A requests B to be the "anchor" of two conversation spaces. This is
is easily setup by creating a conference with two subconferences and easily setup by creating a conference with two subconferences and
setting the media policy appopriately such that B is a participant in setting the media policy appopriately such that B is a participant in
both. Media forking can also be setup using 3pcc as described in both. Media forking can also be setup using 3pcc as described in
Section 5.1 of RFC3264 [3] (an offer/answer model for SDP). The Section 5.1 of RFC3264 [3] (an offer/answer model for SDP). The
session descriptions for forking are quite complex. Controllers session descriptions for forking are quite complex. Controllers
should verify that endpoints can handle forked-media, for example should verify that endpoints can handle forked-media, for example
using prior configuration. using prior configuration.
Features enabled: Features enabled:
o barge-in o barge-in
o voice portal services o voice portal services
skipping to change at page 28, line 37 skipping to change at page 28, line 37
5. Security Considerations 5. Security Considerations
Call Control primitives provide a powerful set of features that can Call Control primitives provide a powerful set of features that can
be dangerous in the hands of an attacker. To complicate matters, be dangerous in the hands of an attacker. To complicate matters,
call control primitives are likely to be automatically authorized call control primitives are likely to be automatically authorized
without direct human oversight. without direct human oversight.
The class of attacks which are possible using these tools include the The class of attacks which are possible using these tools include the
ability to eavesdrop on calls, disconnect calls, redirect calls, ability to eavesdrop on calls, disconnect calls, redirect calls,
render irritating content (including ringing) at a user agent, cause render irritating content (including ringing) at a user agent, cause
an action that has billing consequences, subvert billing an action that has billing consequences, subvert billing (theft-of-
(theft-of-service), and obtain private information. Call control service), and obtain private information. Call control extensions
extensions must take extra care to describe how these attacks will be must take extra care to describe how these attacks will be prevented.
prevented.
We can also make some general observations about authorization and We can also make some general observations about authorization and
trust with respect to call control. The security model is trust with respect to call control. The security model is
dramatically dependent on the signaling model chosen (see section dramatically dependent on the signaling model chosen (see section
3.2) 3.2)
Let us first examine the security model used in the 3pcc approach. Let us first examine the security model used in the 3pcc approach.
All signaling goes through the controller, which is a trusted entity. All signaling goes through the controller, which is a trusted entity.
Traditional SIP authentication and hop-by-hop encrpytion and message Traditional SIP authentication and hop-by-hop encrpytion and message
integrity work fine in this environment, but end-to-end encrpytion integrity work fine in this environment, but end-to-end encrpytion
skipping to change at page 29, line 18 skipping to change at page 29, line 16
conversation space, or c) an entity trusted by one of the conversation space, or c) an entity trusted by one of the
participants. For example, a participant always initiates a participants. For example, a participant always initiates a
transfer; a retrieve from Park (a take) is initiated on behalf of a transfer; a retrieve from Park (a take) is initiated on behalf of a
former participant; and a barge-in (insert or far-fork) is initiated former participant; and a barge-in (insert or far-fork) is initiated
by a trusted entity (an operator for example). by a trusted entity (an operator for example).
Authenticating requests by an existing participant or a trusted Authenticating requests by an existing participant or a trusted
entity can be done with baseline SIP mechanisms. In the case of entity can be done with baseline SIP mechanisms. In the case of
features initiated by a former participant, these should be protected features initiated by a former participant, these should be protected
against replay attacks by using a unique name or identifier per against replay attacks by using a unique name or identifier per
invocation. The Replaces header exhibits this behavior as a invocation. The Replaces header exhibits this behavior as a by-
by-product of its operation (once a Replaces operation is successful, product of its operation (once a Replaces operation is successful,
the call-leg being Replaced no longer exists). For other requests, a the call-leg being Replaced no longer exists). For other requests, a
"one-time" Request-URI may be provided to the feature invoker. "one-time" Request-URI may be provided to the feature invoker.
To authorize call control primitives that trigger special behavior To authorize call control primitives that trigger special behavior
(such as an INVITE with Replaces or Join semantics), the receiving (such as an INVITE with Replaces or Join semantics), the receiving
user agent may have trouble finding appropriate credentials with user agent may have trouble finding appropriate credentials with
which to challenge or authorize the request, as the sender may be which to challenge or authorize the request, as the sender may be
completely unknown to the receiver, except through the introduction completely unknown to the receiver, except through the introduction
of a third party. These credentials need to be passed transitively of a third party. These credentials need to be passed transitively
in some way or fetched in an event body, for example. in some way or fetched in an event body, for example.
6. Appendix A: Example Features 6. IANA Considerations
This document required no action by IANA.
7. Appendix A: Example Features
Primitives are defined in terms of their ability to provide features. Primitives are defined in terms of their ability to provide features.
These example features should require an amply robust set of services These example features should require an amply robust set of services
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 briefly. Note that the descriptions of these features are non-
non-normative. Some of these features are used as examples in normative. Some of these features are used as examples in section 6
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
which are clearly Internet oriented. which are clearly Internet oriented.
Example Feature Definitions: Example Feature Definitions:
Call Waiting - Alice is in a call, then receives another call. Alice Call Waiting - Alice is in a call, then receives another call. Alice
can place the first call on hold, and talk with the other caller. can place the first call on hold, and talk with the other caller.
She can typically switch back and forth between the callers. She can typically switch back and forth between the callers.
skipping to change at page 30, line 33 skipping to change at page 30, line 36
group". group".
Music on Hold - When Alice places a call with Bob on hold, it Music on Hold - When Alice places a call with Bob on hold, it
replaces its audio with streaming content such as music, replaces its audio with streaming content such as music,
announcements, or advertisements. announcements, or advertisements.
Call Monitoring - A call center supervisor joins an in-progress call Call Monitoring - A call center supervisor joins an in-progress call
for monitoring purposes. for monitoring purposes.
Barge-in - Carol interrupts Alice who has a call in-progress call Barge-in - Carol interrupts Alice who has a call in-progress call
with Bob. In some variations, Alice forcibly joins a new with Bob. In some variations, Alice forcibly joins a new conversation
conversation with Carol, in other variations, all three parties are with Carol, in other variations, all three parties are placed in the
placed in the same conversation (basically a 3-way conference). same conversation (basically a 3-way conference).
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.
Autoanswer - Calls to a certain address or location answer Autoanswer - Calls to a certain address or location answer
immediately via a speakerphone. immediately via a speakerphone.
Intercom - Alice typically presses a button on a phone which Intercom - Alice typically presses a button on a phone which
immediately connects to another user or phone and casues that phone immediately connects to another user or phone and casues that phone
to play her voice over its speaker. Some variations immediately to play her voice over its speaker. Some variations immediately
skipping to change at page 31, line 9 skipping to change at page 31, line 13
to be pressed to enable a two-way conversation. to be pressed to enable a two-way conversation.
Speakerphone paging - Alice calls the paging address and speaks. Her Speakerphone paging - Alice calls the paging address and speaks. Her
voice is played on the speaker of every idle phone in a preconfigured voice is played on the speaker of every idle phone in a preconfigured
group of phones. group of phones.
Speed dial - Alice dials an abbreviated number, or enters an alias, Speed dial - Alice dials an abbreviated number, or enters an alias,
or presses a special speed dial button representing Bob. Her action or presses a special speed dial button representing Bob. Her action
is interpreted as if she specified the full address of Bob. is interpreted as if she specified the full address of Bob.
Call Return - Alice calls Bob. Bob misses the call or is Call Return - Alice calls Bob. Bob misses the call or is disconnected
disconnected before he is finished talking to Alice. Bob invokes before he is finished talking to Alice. Bob invokes Call return
Call return which calls Alice, even if Alice did not provide her real which calls Alice, even if Alice did not provide her real identity or
identity or location to Bob. location to Bob.
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 Outbound Call Screening - Alice is paged and unknowingly calls a PSTN
pay-service telephone number in the Carribean, but local policy pay-service telephone number in the Carribean, but local policy
blocks her call, and possibly informs her why. blocks her call, and possibly informs her why.
Call Forwarding - Before a call-leg is accepted it is redirected to Call Forwarding - Before a call-leg is accepted it is redirected to
skipping to change at page 33, line 5 skipping to change at page 33, line 5
call her call is disconnected or redirected to a service where she call her call is disconnected or redirected to a service where she
can purchase more calling value. can purchase more calling value.
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 restauraunt voice portal to check Carol's flight schedule, find a restauraunt
near her hotel, make a reservation, get directions there, and page near her hotel, make a reservation, get directions there, and page
Carol with this information. Carol with this information.
6.1 Implementation of these features 7.1 Implementation of these features
Example Features: Example Features:
Call Hold [Offer/Answer] for SIP Call Hold [Offer/Answer] for SIP
Call Waiting Local Implementation Call Waiting Local Implementation
Blind Transfer [cc-transfer] Blind Transfer [cc-transfer]
Attended Transfer [cc-transfer] Attended Transfer [cc-transfer]
Consultative transfer [cc-transfer] Consultative transfer [cc-transfer]
Conference Call [conf-models] Conference Call [conf-models]
Call Park *[examples] Call Park *[examples]
Call Pickup *[examples] Call Pickup *[examples]
skipping to change at page 33, line 42 skipping to change at page 33, line 42
Find-Me Proxy service based on presence Find-Me Proxy service based on presence
Whispered call waiting Local implementation Whispered call waiting Local implementation
Voice message screening * Voice message screening *
Presence-based Conferencing*call when presence = available Presence-based Conferencing*call when presence = available
IM Conference Alerts subscribe to conference status IM Conference Alerts subscribe to conference status
Single Line Extension * Single Line Extension *
Click-to-dial * Click-to-dial *
Pre-paid calling * Pre-paid calling *
Voice Portal * Voice Portal *
6.1.1 Call Park 7.1.1 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 7.1.2 Call Pickup
There are two different features which are called call pickup. The There are two different features which 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 session dialog state of the park
service or the UA which has locally parked the dialog. Dialogs which service or the UA which has locally parked the dialog. Dialogs which
are parked should be labeled with an identifier. The labels are used are parked should be labeled with an identifier. The labels are used
by the UA to allow the user to indicate which dialog is to be picked by the UA to allow the user to indicate which dialog is to be picked
up. The UA picking up the call invoked the URL in the call state up. The UA picking up the call invoked the URL in the call state
which is labeled as replace-remote. which is labeled as replace-remote.
skipping to change at page 34, line 30 skipping to change at page 34, line 30
(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 which is to phone is advertised using the dialog package. The UA which 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 URL in the call state labeled as
replace-remote. replace-remote.
6.1.3 Music on Hold 7.1.3 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 URL 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 7.1.4 Call Monitoring
Call monitoring is a Join operation. The monitoring UA sends a Join 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 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 dialog via the dialog state on the monitored UA. The monitoring UA
sends SDP in the INVITE which indicates receive only media. As the sends SDP in the INVITE which indicates receive only media. As the
UA is monitoring only it does not matter whether the UA indicates it UA is monitoring only it does not matter whether the UA indicates it
wishes the send stream be mix or point to point. wishes the send stream be mix or point to point.
6.1.5 Barge-in 7.1.5 Barge-in
Barge-in works the same as call monitoring except that it must Barge-in works the same as call monitoring except that it must
indicate that the send media stream to be mixed so that all of the indicate that the send media stream to be mixed so that all of the
other parties can hear the stream from UA barging in. other parties can hear the stream from UA barging in.
6.1.6 Intercom 7.1.6 Intercom
The UA initiates a dialog using INVITE in the ordinary way. The The UA initiates a dialog using INVITE in the ordinary way. The
calling UA then signals the paged UA to answer the call. The calling calling UA then signals the paged UA to answer the call. The calling
UA may discover the URL to answer the call via the session dialog UA may discover the URL to answer the call via the session dialog
package of the called UA. The called UA accepts the INVITE with a package of the called UA. The called UA accepts the INVITE with a
200 Ok and automatically enables the speakerphone. 200 Ok and automatically enables the speakerphone.
Alternatively this can be a local decision for the UA to answer based Alternatively this can be a local decision for the UA to answer based
upon called party identification. upon called party identification.
6.1.7 Speakerphone paging 7.1.7 Speakerphone paging
Speakerphone paging can be implemented using either multicast or Speakerphone paging can be implemented using either multicast or
through a simple multipoint mixer. In the multicast solution the through a simple multipoint mixer. In the multicast solution the
paging UA sends a multicast INVITE with send only media in the SDP paging UA sends a multicast INVITE with send only media in the SDP
(see also RFC3264). The automatic answer and enabling of the (see also RFC3264). The automatic answer and enabling of the
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 35, line 48 skipping to change at page 35, line 48
a single REFER which is parallel forked by the proxy server). The a single REFER which is parallel forked by the proxy server). The
UAs performing as paging speakers are configured to automatically UAs performing as paging speakers are configured to automatically
answer based upon caller identification (e.g. To field, URI or answer based upon caller identification (e.g. To field, URI or
Referred-To headers). Referred-To 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 invitations to the conference to all user agents in the paging send invitations to the conference to all user agents in the paging
group. group.
6.1.8 Distinctive ring 7.1.8 Distinctive ring
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 provded by the caller or inserted by a trusted Alert-Info header provded 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.9 Voice message screening 7.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
call-leg information. If the user screening their messages decides call-leg information. If the user screening their messages decides
to answer, they perform a Take from the voicemail system (for to answer, they perform a Take from the voicemail system (for
example, send an INVITE with Replaces to the UA leaving the message) example, send an INVITE with Replaces to the UA leaving the message)
6.1.10 Single Line Extension 7.1.10 Single Line Extension
Incoming calls ring all the extensions through basic parallel forking Incoming calls ring all the extensions through basic parallel forking
[bis]. Each extension subscribes to call-leg events from each other [bis]. Each extension subscribes to call-leg events from each other
extension. While one user has an active call, any other UA extension extension. While one user has an active call, any other UA extension
can insert itself into that conversation (it already knows the can insert itself into that conversation (it already knows the call-
call-leg information)in the same way as barge-in. leg information)in the same way as barge-in.
6.1.11 Click-to-dial 7.1.11 Click-to-dial
The application or server which hosts the click-to-dial application The application or server which hosts the click-to-dial application
captures the URL to be dialed and can setup the call using 3pcc or captures the URL to be dialed and can setup the call using 3pcc or
can send a REFER request to the UA which is to dial the address. As can send a REFER request to the UA which is to dial the address. As
users sometimes change their mind or wish to give up listing to a users sometimes change their mind or wish to give up listing to a
ringing or voicemail answered phone, this application illustrates the ringing or voicemail answered phone, this application illustrates the
need to also have the ability to remotely hangup a call. need to also have the ability to remotely hangup a call.
6.1.12 Pre-paid calling 7.1.12 Pre-paid calling
For prepaid calling, the user's media always passes through a device For prepaid calling, the user's media always passes through a device
which is trusted by the pre-paid provider. This may be the other which is trusted by the pre-paid provider. This may be the other
endpoint (for example a PSTN gateway). In either case, an endpoint (for example a PSTN gateway). In either case, an
intermediary proxy or B2BUA can periodically verify the amount of intermediary proxy or B2BUA can periodically verify the amount of
time available on the pre-paid account, and use the session-timer time available on the pre-paid account, and use the session-timer
extension to cause the trusted endpoint (gateway) or intermediary extension to cause the trusted endpoint (gateway) or intermediary
(media relay) to send a reINVITE before that time runs out. During (media relay) to send a reINVITE before that time runs out. During
the reINVITE, the SIP intermediary can reverify the account and the reINVITE, the SIP intermediary can reverify the account and
insert another session-timer header. insert another session-timer header.
Note that while most pre-paid systems on the PSTN use an IVR to Note that while most pre-paid systems on the PSTN use an IVR to
collect the account number and destination, this isn't strictly collect the account number and destination, this isn't strictly
necessary for a SIP-originated prepaid call. SIP requests and SIP necessary for a SIP-originated prepaid call. SIP requests and SIP
URIs are sufficiently expressive to convey the final destination, the URIs are sufficiently expressive to convey the final destination, the
provider of the prepaid service, the location from which the user is 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 calling, and the prepaid account they want to use. If a pre-paid IVR
is used, the mechanism described below (Voice Portals) can be is used, the mechanism described below (Voice Portals) can be
combined as well. combined as well.
6.1.13 Voice Portal 7.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
restauraunt reservation, or return a voicemail message for example). restauraunt 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
Menu"). Menu").
skipping to change at page 37, line 39 skipping to change at page 37, line 39
The Voice Portal is now just listening for a hotword or the The Voice Portal is now just listening for a hotword or the
appropriate DTMF. As soon as the user indicates they are done, the appropriate DTMF. As soon as the user indicates they are done, the
Voice Portal Takes the call from the old Target, and we are back to Voice Portal Takes the call from the old Target, and we are back to
the original media relationship. the original media relationship.
This feature can also be used by the account number and phone number This feature can also be used by the account number and phone number
collection menu in a pre-paid calling service. A user can press a collection menu in a pre-paid calling service. A user can press a
DTMF sequence which presents them with the appropriate menu again. DTMF sequence which presents them with the appropriate menu again.
7. References 8. References
7.1 Normative References 8.1 Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002. Notification", RFC 3265, June 2002.
[5] Handley, M. and V. Jacobson, "SDP: Session Description [5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[6] Johnston, A. and R. Sparks, "Session Initiation Protocol [6] Johnston, A., "Session Initiation Protocol Service Examples",
Service Examples", draft-ietf-sipping-service-examples-07 (work draft-ietf-sipping-service-examples-09 (work in progress),
in progress), July 2004. July 2005.
[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, April the Session Initiation Protocol (SIP)", BCP 85, RFC 3725,
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
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) [10] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP)
"Join" Header", RFC 3911, October 2004. "Join" Header", RFC 3911, October 2004.
[11] Rosenberg, J., "An INVITE Inititiated Dialog Event Package for [11] Rosenberg, J., "An INVITE Inititiated Dialog Event Package for
the Session Initiation Protocol (SIP)", the Session Initiation Protocol (SIP)",
draft-ietf-sipping-dialog-package-05 (work in progress), draft-ietf-sipping-dialog-package-06 (work in progress),
November 2004. April 2005.
[12] Rosenberg, J., "A Session Initiation Protocol (SIP) Event [12] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Conference State", Package for Conference State",
draft-ietf-sipping-conference-package-08 (work in progress), draft-ietf-sipping-conference-package-12 (work in progress),
December 2004. July 2005.
[13] Rosenberg, J., "A Session Initiation Protocol (SIP) Event [13] 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 [14] 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 [15] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol", Initiation Protocol",
draft-ietf-sipping-conferencing-framework-03 (work in draft-ietf-sipping-conferencing-framework-05 (work in
progress), October 2004. progress), May 2005.
[16] Rosenberg, J., "A Framework for Application Interaction in the [16] Rosenberg, J., "A Framework for Application Interaction in the
Session Initiation Protocol (SIP)", Session Initiation Protocol (SIP)",
draft-ietf-sipping-app-interaction-framework-03 (work in draft-ietf-sipping-app-interaction-framework-05 (work in
progress), October 2004. progress), July 2005.
[17] Camarillo, G., "Framework for Transcoding with the Session [17] Camarillo, G., "Framework for Transcoding with the Session
Initiation Protocol", draft-ietf-sipping-transc-framework-00 Initiation Protocol (SIP)",
(work in progress), February 2004. draft-ietf-sipping-transc-framework-02 (work in progress),
June 2005.
[18] Sparks, R. and A. Johnston, "Session Initiation Protocol Call [18] Sparks, R., "Session Initiation Protocol Call Control -
Control - Transfer", draft-ietf-sipping-cc-transfer-03 (work in Transfer", draft-ietf-sipping-cc-transfer-05 (work in
progress), October 2004. progress), July 2005.
[19] Johnston, A. and O. Levin, "Session Initiation Protocol Call [19] Johnston, A. and O. Levin, "Session Initiation Protocol Call
Control - Conferencing for User Agents", Control - Conferencing for User Agents",
draft-ietf-sipping-cc-conferencing-06 (work in progress), draft-ietf-sipping-cc-conferencing-07 (work in progress),
November 2004. June 2005.
[20] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Indicating User [20] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
Agent Capabilities in the Session Initiation Protocol (SIP)", User Agent Capabilities in the Session Initiation Protocol
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)", RFC Preferences for the Session Initiation Protocol (SIP)",
3841, August 2004. RFC 3841, August 2004.
7.2 Informational References 8.2 Informational References
[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] Mahy, R., "Remote Call Control in SIP using the REFER method [23] Mahy, R., "Remote Call Control in SIP using the REFER method
and the session-oriented dialog package", and the session-oriented dialog package",
draft-mahy-sip-remote-cc-01 (work in progress), February 2004. draft-mahy-sip-remote-cc-01 (work in progress), February 2004.
[24] Burger, E., "Basic Network Media Services with SIP", [24] Burger, E., "Basic Network Media Services with SIP",
draft-burger-sipping-netann-10 (work in progress), October draft-burger-sipping-netann-11 (work in progress),
2004. February 2005.
Authors' Addresses Authors' Addresses
Rohan Mahy Rohan Mahy
Airespace SIP Edge LLC
EMail: rohan@ekabal.com Email: rohan@ekabal.com
Ben Campbell Ben Campbell
Estacado Systems Estacado Systems
EMail: ben@nostrum.com Email: ben@nostrum.com
Robert Sparks Robert Sparks
XTen Estacado Systems
EMail: rjs@xten.com Email: rjsparks@nostrum.com
Jonathan Rosenberg Jonathan Rosenberg
Cisco Systems Cisco Systems
EMail: jdrosen@cisco.com Email: jdrosen@cisco.com
Dan Petrie Dan Petrie
Pingtel SIP EZ
EMail: dpetrie@pingtel.com Email: dpetrie@sipez.com
Alan Johnston Alan Johnston
MCI MCI
EMail: alan.johnston@mci.com Email: alan.johnston@mci.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 70 change blocks. 
136 lines changed or deleted 138 lines changed or added

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