draft-ietf-sipping-cc-framework-02.txt   draft-ietf-sipping-cc-framework-03.txt 
SIPPING WG R. Mahy SIPPING WG R. Mahy
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: September 5, 2003 B. Campbell Expires: April 26, 2004 B. Campbell
R. Sparks R. Sparks
J. Rosenberg J. Rosenberg
dynamicsoft dynamicsoft
D. Petrie D. Petrie
Pingtel Pingtel
A. Johnston A. Johnston
WorldCom WorldCom
March 7, 2003 October 27, 2003
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-02.txt draft-ietf-sipping-cc-framework-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 5, 2003. This Internet-Draft will expire on April 26, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document defines a framework and requirements for multi-party This document defines a framework and requirements for multi-party
usage of SIP. To enable discussion of multi-party features and usage of SIP. To enable discussion of multi-party features and
applications we define an abstract call model for describing the applications we define an abstract call model for describing the
skipping to change at page 2, line 42 skipping to change at page 2, line 42
3.7 Use of URIs . . . . . . . . . . . . . . . . . . . . . . . 17 3.7 Use of URIs . . . . . . . . . . . . . . . . . . . . . . . 17
3.7.1 Naming Users in SIP . . . . . . . . . . . . . . . . . . . 18 3.7.1 Naming Users in SIP . . . . . . . . . . . . . . . . . . . 18
3.7.2 Naming Services with SIP URIs . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . 25 4.2 Single Dialog Actions . . . . . . . . . . . . . . . . . . 24
4.2.1 Remote Dial . . . . . . . . . . . . . . . . . . . . . . . 25 4.2.1 Remote Dial . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.2 Remote On and Off Hold . . . . . . . . . . . . . . . . . . 25 4.2.2 Remote On and Off Hold . . . . . . . . . . . . . . . . . . 25
4.2.3 Remote Hangup . . . . . . . . . . . . . . . . . . . . . . 25 4.2.3 Remote Hangup . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Multi-dialog actions . . . . . . . . . . . . . . . . . . . 25 4.3 Multi-dialog actions . . . . . . . . . . . . . . . . . . . 25
4.3.1 Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.3.1 Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.2 Take . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.3.2 Take . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.3 Add . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3.3 Add . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.4 Local Join . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3.4 Local Join . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.5 Insert . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3.5 Insert . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.6 Split . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3.6 Split . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.7 Near-fork . . . . . . . . . . . . . . . . . . . . . . . . 28 4.3.7 Near-fork . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.8 Far fork . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.3.8 Far fork . . . . . . . . . . . . . . . . . . . . . . . . . 28
5. Security Considerations . . . . . . . . . . . . . . . . . 28 5. Security Considerations . . . . . . . . . . . . . . . . . 28
6. Appendix A: Example Features . . . . . . . . . . . . . . . 29 6. Appendix A: Example Features . . . . . . . . . . . . . . . 29
6.1 Implementation of these features . . . . . . . . . . . . . 33 6.1 Implementation of these features . . . . . . . . . . . . . 33
6.1.1 Call Park . . . . . . . . . . . . . . . . . . . . . . . . 34 6.1.1 Call Park . . . . . . . . . . . . . . . . . . . . . . . . 34
6.1.2 Call Pickup . . . . . . . . . . . . . . . . . . . . . . . 35 6.1.2 Call Pickup . . . . . . . . . . . . . . . . . . . . . . . 34
6.1.3 Music on Hold . . . . . . . . . . . . . . . . . . . . . . 35 6.1.3 Music on Hold . . . . . . . . . . . . . . . . . . . . . . 34
6.1.4 Call Monitoring . . . . . . . . . . . . . . . . . . . . . 35 6.1.4 Call Monitoring . . . . . . . . . . . . . . . . . . . . . 35
6.1.5 Barge-in . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.1.5 Barge-in . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.1.6 Intercom . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.1.6 Intercom . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.1.7 Speakerphone paging . . . . . . . . . . . . . . . . . . . 36 6.1.7 Speakerphone paging . . . . . . . . . . . . . . . . . . . 35
6.1.8 Distinctive ring . . . . . . . . . . . . . . . . . . . . . 36 6.1.8 Distinctive ring . . . . . . . . . . . . . . . . . . . . . 36
6.1.9 Voice message screening . . . . . . . . . . . . . . . . . 37 6.1.9 Voice message screening . . . . . . . . . . . . . . . . . 36
6.1.10 Single Line Extension . . . . . . . . . . . . . . . . . . 37 6.1.10 Single Line Extension . . . . . . . . . . . . . . . . . . 36
6.1.11 Click-to-dial . . . . . . . . . . . . . . . . . . . . . . 37 6.1.11 Click-to-dial . . . . . . . . . . . . . . . . . . . . . . 36
6.1.12 Pre-paid calling . . . . . . . . . . . . . . . . . . . . . 37 6.1.12 Pre-paid calling . . . . . . . . . . . . . . . . . . . . . 37
6.1.13 Voice Portal . . . . . . . . . . . . . . . . . . . . . . . 38 6.1.13 Voice Portal . . . . . . . . . . . . . . . . . . . . . . . 37
Normative References . . . . . . . . . . . . . . . . . . . 38 Normative References . . . . . . . . . . . . . . . . . . . 38
Informational References . . . . . . . . . . . . . . . . . 40 Informational References . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . 42 Intellectual Property and Copyright Statements . . . . . . 42
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].
skipping to change at page 18, line 29 skipping to change at page 18, line 25
that points to a domain with a location server that can map the URI that points to a domain with a location server that can map the URI
to set of Contact URIs where the user might be available. Typically to set of Contact URIs where the user might be available. Typically
the Contact URIs are populated via registration. the Contact URIs are populated via registration.
Address of Record Contacts Address of Record Contacts
sip:bob@biloxi.com -> sip:bob@babylon.biloxi.com:5060 sip:bob@biloxi.com -> sip:bob@babylon.biloxi.com:5060
sip:bbrown@mailbox.provider.net sip:bbrown@mailbox.provider.net
sip:+1.408.555.6789@mobile.net sip:+1.408.555.6789@mobile.net
Caller Preferences and Callee Capabilities [21] defines a set of Callee Capabilities [21] defines a set of additional parameters to
additional parameters to the Contact header that define the the Contact header that define the characteristics of the user agent
characteristics of the user agent at the specified URI. For example, at the specified URI. For example, there is a mobility parameter
there is a mobility parameter which indicates whether the UA is fixed which indicates whether the UA is fixed or mobile. When a user agent
or mobile. When a user agent registers, it places these parameters registers, it places these parameters in the Contact headers to
in the Contact headers to characterize the URIs it is registering. characterize the URIs it is registering. This allows a proxy for
This allows a proxy for that domain to have information about the that domain to have information about the contact addresses for that
contact addresses for that user. user.
When a caller sends a request, it can optionally include the When a caller sends a request, it can optionally request Caller
Accept-Contact and Reject-Contact headers which request certain Preferences [22], by including the Accept-Contact and Reject-Contact
handling by the proxy in the target domain. These headers contain headers which request certain handling by the proxy in the target
preferences that describe the set of desired URIs to which the caller domain. These headers contain preferences that describe the set of
would like their request routed. The proxy in the target domain desired URIs to which the caller would like their request routed.
matches these preferences with the Contact characteristics originally The proxy in the target domain matches these preferences with the
registered by the target user. The target user can also choose to Contact characteristics originally registered by the target user.
run arbitrarily complex "Find-me" feature logic on a proxy in the The target user can also choose to run arbitrarily complex "Find-me"
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-supplied scripts and caller preferences included in the call callee-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
skipping to change at page 24, line 35 skipping to change at page 24, line 31
The following are a set of actions that may be performed on a single The following are a set of actions that may be performed on a single
early dialog. These actions can be thought of as a set of remote early dialog. These actions can be thought of as a set of remote
control operations. For example an automaton might perform the control operations. For example an automaton might perform the
operation on behalf of a user. Alternatively a user might use the operation on behalf of a user. Alternatively a user might use the
remote control in the form of an application to perform the action on remote control in the form of an application to perform the action on
the early dialog of a UA which may be out of reach. All of these the early dialog of a UA which may be out of reach. All of these
actions correspond to telling the UA how to respond to a request to actions correspond to telling the UA how to respond to a request to
establish an early dialog. These actions provide useful functionality establish an early dialog. These actions provide useful functionality
for PDA, PC and server based applications which desire the ability to for PDA, PC and server based applications which desire the ability to
control a UA. control a UA. A proposed mechanism for this type of functionality is
described in Remote Call Control [24].
4.1.1 Remote Answer 4.1.1 Remote Answer
A dialog is in some early dialog state such as 180 Ringing. It may A dialog is in some early dialog state such as 180 Ringing. It may
be desirable to tell the UA to answer the dialog. That is tell it to be desirable to tell the UA to answer the dialog. That is tell it to
send a 200 Ok response to establish the dialog. send a 200 Ok response to establish the dialog.
4.1.2 Remote Forward or Put 4.1.2 Remote Forward or Put
It may be desirable to tell the UA to respond with a 3xx class It may be desirable to tell the UA to respond with a 3xx class
skipping to change at page 25, line 12 skipping to change at page 25, line 8
It may be desirable to instruct the UA to send an error response such It may be desirable to instruct the UA to send an error response such
as 486 Busy Here. as 486 Busy Here.
4.2 Single Dialog Actions 4.2 Single Dialog Actions
There is another useful set of actions which operate on a single There is another useful set of actions which operate on a single
established dialog. These operations are useful in building established dialog. These operations are useful in building
productivity applications for aiding users to control their phone. productivity applications for aiding users to control their phone.
For example a CRM application which sets up calls for a user For example a CRM application which sets up calls for a user
eliminating the need for the user to actually enter an address. eliminating the need for the user to actually enter an address.
These operations can also be thought of a remote control actions. These operations can also be thought of a remote control actions. A
proposed mechanism for this type of functionality is described in
Remote Call Control [24].
4.2.1 Remote Dial 4.2.1 Remote Dial
This action instructs the UA to initiate a dialog. This action can This action instructs the UA to initiate a dialog. This action can
be performed using the REFER method. be performed using the REFER method.
4.2.2 Remote On and Off Hold 4.2.2 Remote On and Off Hold
This action instructs the UA to put an established dialog on hold. This action instructs the UA to put an established dialog on hold.
Though this operation can be conceptually be performed with the REFER Though this operation can be conceptually be performed with the REFER
skipping to change at page 39, line 15 skipping to change at page 38, line 36
[6] Johnston, A. and S. Donovan, "Session Initiation Protocol [6] Johnston, A. and S. Donovan, "Session Initiation Protocol
Service Examples", draft-ietf-sipping-service-examples-04 (work Service Examples", draft-ietf-sipping-service-examples-04 (work
in progress), March 2003. in progress), March 2003.
[7] Rosenberg, J., Schulzrinne, H., Camarillo, G. and J. Peterson, [7] Rosenberg, J., Schulzrinne, H., Camarillo, G. and J. Peterson,
"Best Current Practices for Third Party Call Control in the "Best Current Practices for Third Party Call Control in the
Session Initiation Protocol", draft-ietf-sipping-3pcc-03 (work Session Initiation Protocol", draft-ietf-sipping-3pcc-03 (work
in progress), March 2003. in progress), March 2003.
[8] Sparks, R., "The SIP Refer Method", draft-ietf-sip-refer-07 [8] Sparks, R., "The Session Initiation Protocol (SIP) Refer
(work in progress), December 2002. Method", RFC 3515, April 2003.
[9] Dean, R., Biggs, B. and R. Mahy, "The Session Inititation [9] Dean, R., Biggs, B. and R. Mahy, "The Session Inititation
Protocol (SIP) 'Replaces' Header", draft-ietf-sip-replaces-03 Protocol (SIP) 'Replaces' Header", draft-ietf-sip-replaces-03
(work in progress), March 2003. (work in progress), March 2003.
[10] Mahy, R. and D. Petrie, "The Session Inititation Protocol (SIP) [10] Mahy, R. and D. Petrie, "The Session Inititation Protocol (SIP)
'Join' Header", draft-ietf-sip-join-01 (work in progress), 'Join' Header", draft-ietf-sip-join-01 (work in progress),
March 2003. March 2003.
[11] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog [11] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog
skipping to change at page 39, line 46 skipping to change at page 39, line 18
[13] Rosenberg, J., "A Session Initiation Protocol (SIP) Event [13] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", draft-ietf-sipping-reg-event-00 Package for Registrations", draft-ietf-sipping-reg-event-00
(work in progress), October 2002. (work in progress), October 2002.
[14] Rosenberg, J., "A Presence Event Package for the Session [14] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
in progress), January 2003. in progress), January 2003.
[15] Rosenberg, J., "A Framework for Conferencing with the Session [15] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol", Initiation Protocol",
draft-rosenberg-sipping-conferencing-framework-01 (work in draft-ietf-sipping-conferencing-framework-00 (work in
progress), February 2003. progress), May 2003.
[16] Rosenberg, J., "A Framework and Requirements for Application [16] Rosenberg, J., "A Framework for Application Interaction in the
Interaction in SIP", Session Initiation Protocol (SIP)",
draft-rosenberg-sipping-app-interaction-framework-00 (work in draft-ietf-sipping-app-interaction-framework-00 (work in
progress), November 2002. progress), October 2003.
[17] Mahy, R. and N. Ismail, "Media Policy Manipulation in the [17] Mahy, R. and N. Ismail, "Media Policy Manipulation in the
Conference Policy Control Protocol", Conference Policy Control Protocol",
draft-mahy-sipping-media-policy-control-00 (work in progress), draft-mahy-xcon-media-policy-control-00 (work in progress),
February 2003. June 2003.
[18] Camarillo, G., "Transcoding Services Invocation in the Session [18] Camarillo, G., "Transcoding Services Invocation in the Session
Initiation Protocol", draft-camarillo-sip-deaf-02 (work in Initiation Protocol", draft-camarillo-sip-deaf-02 (work in
progress), February 2003. progress), February 2003.
[19] Sparks, R. and A. Johnston, "Session Initiation Protocol Call [19] Sparks, R. and A. Johnston, "Session Initiation Protocol Call
Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in
progress), February 2003. progress), February 2003.
[20] Johnston, A. and O. Levin, "Session Initiation Protocol Call [20] Johnston, A. and O. Levin, "Session Initiation Protocol Call
Control - Conferencing for User Agents", Control - Conferencing for User Agents",
draft-johnston-sipping-cc-conferencing-01 (work in progress), draft-ietf-sipping-cc-conferencing-00 (work in progress), April
February 2003. 2003.
[21] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller [21] Rosenberg, J., "Indicating User Agent Capabilities in the
Session Initiation Protocol (SIP)",
draft-ietf-sip-callee-caps-00 (work in progress), June 2003.
[22] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller
Preferences and Callee Capabilities for the Session Initiation Preferences and Callee Capabilities for the Session Initiation
Protocol (SIP)", draft-ietf-sip-callerprefs-08 (work in Protocol (SIP)", draft-ietf-sip-callerprefs-08 (work in
progress), March 2003. progress), March 2003.
Informational References Informational References
[23] Campbell, B. and R. Sparks, "Control of Service Context using
SIP Request-URI", RFC 3087, April 2001.
[24] Mahy, R., "Remote Call Control in SIP using the REFER method
and the session-oriented dialog package",
draft-mahy-sip-remote-cc-00 (work in progress), October 2003.
[25] Burger, E., Dyke, J. and A. Spitzer, "Basic Network Media
Services with SIP", draft-burger-sipping-netann-05 (work in
progress), March 2003.
Authors' Addresses Authors' Addresses
Rohan Mahy Rohan Mahy
Cisco Systems Cisco Systems
EMail: rohan@cisco.com EMail: rohan@cisco.com
Ben Campbell Ben Campbell
dynamicsoft dynamicsoft
 End of changes. 

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