draft-ietf-sipping-app-interaction-framework-03.txt   draft-ietf-sipping-app-interaction-framework-04.txt 
SIPPING J. Rosenberg SIPPING J. Rosenberg
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: April 24, 2005 October 24, 2004 Expires: August 17, 2005 February 16, 2005
A Framework for Application Interaction in the Session Initiation A Framework for Application Interaction in the Session Initiation
Protocol (SIP) Protocol (SIP)
draft-ietf-sipping-app-interaction-framework-03 draft-ietf-sipping-app-interaction-framework-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668. 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-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at 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 April 24, 2005. This Internet-Draft will expire on August 17, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes a framework for the interaction between users This document describes a framework for the interaction between users
and Session Initiation Protocol (SIP) based applications. By and Session Initiation Protocol (SIP) based applications, and defines
interacting with applications, users can guide the way in which they a new Refer-To header field parameter and option tag in support of
operate. The focus of this framework is stimulus signaling, which that framework. By interacting with applications, users can guide
allows a user agent to interact with an application without knowledge the way in which they operate. The focus of this framework is
of the semantics of that application. Stimulus signaling can occur stimulus signaling, which allows a user agent to interact with an
to a user interface running locally with the client, or to a remote application without knowledge of the semantics of that application.
user interface, through media streams. Stimulus signaling
encompasses a wide range of mechanisms, ranging from clicking on Stimulus signaling can occur to a user interface running locally with
hyperlinks, to pressing buttons, to traditional Dual Tone Multi the client, or to a remote user interface, through media streams.
Frequency (DTMF) input. In all cases, stimulus signaling is Stimulus signaling encompasses a wide range of mechanisms, ranging
supported through the use of markup languages, which play a key role from clicking on hyperlinks, to pressing buttons, to traditional Dual
in this framework. Tone Multi Frequency (DTMF) input. In all cases, stimulus signaling
is supported through the use of markup languages, which play a key
role in this framework.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. A Model for Application Interaction . . . . . . . . . . . . . 7 3. A Model for Application Interaction . . . . . . . . . . . . . 7
3.1 Functional vs. Stimulus . . . . . . . . . . . . . . . . . 8 3.1 Functional vs. Stimulus . . . . . . . . . . . . . . . . . 9
3.2 Real-Time vs. Non-Real Time . . . . . . . . . . . . . . . 9 3.2 Real-Time vs. Non-Real Time . . . . . . . . . . . . . . . 9
3.3 Client-Local vs. Client-Remote . . . . . . . . . . . . . . 9 3.3 Client-Local vs. Client-Remote . . . . . . . . . . . . . . 10
3.4 Presentation Capable vs. Presentation Free . . . . . . . . 10 3.4 Presentation Capable vs. Presentation Free . . . . . . . . 11
4. Interaction Scenarios on Telephones . . . . . . . . . . . . . 11 4. Interaction Scenarios on Telephones . . . . . . . . . . . . . 11
4.1 Client Remote . . . . . . . . . . . . . . . . . . . . . . 11 4.1 Client Remote . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Client Local . . . . . . . . . . . . . . . . . . . . . . . 12 4.2 Client Local . . . . . . . . . . . . . . . . . . . . . . . 12
4.3 Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3 Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Framework Overview . . . . . . . . . . . . . . . . . . . . . . 13 5. Framework Overview . . . . . . . . . . . . . . . . . . . . . . 13
6. Deployment Topologies . . . . . . . . . . . . . . . . . . . . 15 6. Deployment Topologies . . . . . . . . . . . . . . . . . . . . 15
6.1 Third Party Application . . . . . . . . . . . . . . . . . 16 6.1 Third Party Application . . . . . . . . . . . . . . . . . 16
6.2 Co-Resident Application . . . . . . . . . . . . . . . . . 16 6.2 Co-Resident Application . . . . . . . . . . . . . . . . . 16
6.3 Third Party Application and User Device Proxy . . . . . . 17 6.3 Third Party Application and User Device Proxy . . . . . . 17
6.4 Proxy Application . . . . . . . . . . . . . . . . . . . . 18 6.4 Proxy Application . . . . . . . . . . . . . . . . . . . . 18
7. Application Behavior . . . . . . . . . . . . . . . . . . . . . 19 7. Application Behavior . . . . . . . . . . . . . . . . . . . . . 19
7.1 Client Local Interfaces . . . . . . . . . . . . . . . . . 19 7.1 Client Local Interfaces . . . . . . . . . . . . . . . . . 19
skipping to change at page 2, line 46 skipping to change at page 2, line 50
7.2.2 Intermediary Applications . . . . . . . . . . . . . . 24 7.2.2 Intermediary Applications . . . . . . . . . . . . . . 24
8. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 24 8. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 24
8.1 Advertising Capabilities . . . . . . . . . . . . . . . . . 24 8.1 Advertising Capabilities . . . . . . . . . . . . . . . . . 24
8.2 Receiving User Interface Components . . . . . . . . . . . 25 8.2 Receiving User Interface Components . . . . . . . . . . . 25
8.3 Mapping User Input to User Interface Components . . . . . 26 8.3 Mapping User Input to User Interface Components . . . . . 26
8.4 Receiving Updates to User Interface Components . . . . . . 27 8.4 Receiving Updates to User Interface Components . . . . . . 27
8.5 Terminating a User Interface Component . . . . . . . . . . 27 8.5 Terminating a User Interface Component . . . . . . . . . . 27
9. Inter-Application Feature Interaction . . . . . . . . . . . . 28 9. Inter-Application Feature Interaction . . . . . . . . . . . . 28
9.1 Client Local UI . . . . . . . . . . . . . . . . . . . . . 28 9.1 Client Local UI . . . . . . . . . . . . . . . . . . . . . 28
9.2 Client-Remote UI . . . . . . . . . . . . . . . . . . . . . 29 9.2 Client-Remote UI . . . . . . . . . . . . . . . . . . . . . 29
10. Intra Application Feature Interaction . . . . . . . . . . . 29 10. Intra Application Feature Interaction . . . . . . . . . . . 30
11. Example Call Flow . . . . . . . . . . . . . . . . . . . . . 30 11. Example Call Flow . . . . . . . . . . . . . . . . . . . . . 30
12. Security Considerations . . . . . . . . . . . . . . . . . . 35 12. Security Considerations . . . . . . . . . . . . . . . . . . 35
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 36 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 36
13.1 SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 36 13.1 SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 36
13.2 Header Field Parameter . . . . . . . . . . . . . . . . . . 36 13.2 Header Field Parameter . . . . . . . . . . . . . . . . . . 36
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
16.1 Normative References . . . . . . . . . . . . . . . . . . . . 37 16.1 Normative References . . . . . . . . . . . . . . . . . . . . 37
16.2 Informative References . . . . . . . . . . . . . . . . . . . 37 16.2 Informative References . . . . . . . . . . . . . . . . . . . 37
skipping to change at page 4, line 34 skipping to change at page 4, line 34
Functional interaction requires the user device to understand the Functional interaction requires the user device to understand the
semantics of the application, whereas stimulus interaction does not. semantics of the application, whereas stimulus interaction does not.
Stimulus signaling allows for applications to be built without Stimulus signaling allows for applications to be built without
requiring modifications to the user device. Stimulus interaction is requiring modifications to the user device. Stimulus interaction is
the subject of this framework. The framework provides a model for the subject of this framework. The framework provides a model for
how users interact with applications through user interfaces, and how how users interact with applications through user interfaces, and how
user interfaces and applications can be distributed throughout a user interfaces and applications can be distributed throughout a
network. This model is then used to describe how applications can network. This model is then used to describe how applications can
instantiate and manage user interfaces. instantiate and manage user interfaces.
This document also defines a new SIP Refer-To header field parameter
and a new SIP option tag indicating support for that parameter.
2. Definitions 2. Definitions
SIP Application: A SIP application is defined as a program running on SIP Application: A SIP application is defined as a program running on
a SIP-based element (such as a proxy or user agent) that provides a SIP-based element (such as a proxy or user agent) that provides
some value-added function to a user or system administrator. some value-added function to a user or system administrator.
Examples of SIP applications include pre-paid calling card calls, Examples of SIP applications include pre-paid calling card calls,
conferencing, and presence-based [11] call routing. conferencing, and presence-based [11] call routing.
Application Interaction: The process by which a user provides input Application Interaction: The process by which a user provides input
to an application. to an application.
skipping to change at page 6, line 5 skipping to change at page 6, line 7
Client-Local User Interface: A user interface which is co-resident Client-Local User Interface: A user interface which is co-resident
with the user device. with the user device.
Client-Remote User Interface: A user interface which executes Client-Remote User Interface: A user interface which executes
remotely from the user device. In this case, a standardized remotely from the user device. In this case, a standardized
interface is needed between the user device and the user interface is needed between the user device and the user
interface. Typically, this is done through media sessions - interface. Typically, this is done through media sessions -
audio, video, or application sharing. audio, video, or application sharing.
Markup Language: A markup language describes a logical flow of
presentation of information to the user, collection of information
from the user, and transmission of that information to an
application.
Media Interaction: A means of separating a user and a user interface Media Interaction: A means of separating a user and a user interface
by connecting them with media streams. by connecting them with media streams.
Interactive Voice Response (IVR): An IVR is a type of user interface Interactive Voice Response (IVR): An IVR is a type of user interface
that allows users to speak commands to the application, and hear that allows users to speak commands to the application, and hear
responses to those commands prompting for more information. responses to those commands prompting for more information.
Prompt-and-Collect: The basic primitive of an IVR user interface. Prompt-and-Collect: The basic primitive of an IVR user interface.
The user is presented with a voice option, and the user speaks The user is presented with a voice option, and the user speaks
their choice. their choice.
Barge-In: In an IVR user interface, a user is prompted to enter some Barge-In: The act of entering information into an IVR user inteface
information. With some prompts, the user may enter the requested prior to the completion of a prompt requesting that information.
information before the prompt completes. In that case, the prompt
ceases. The act of entering the information before completion of
the prompt is referred to as barge-in.
Focus: A user interface component has focus when user input is Focus: A user interface component has focus when user input is
provided fed to it, as opposed to any other user interface provided fed to it, as opposed to any other user interface
components. This is not to be confused with the term focus within components. This is not to be confused with the term focus within
the SIP conferencing framework, which refers to the center user the SIP conferencing framework, which refers to the center user
agent in a conference [13]. agent in a conference [13].
Focus Determination: The process by which the user device determines Focus Determination: The process by which the user device determines
which user interface component will receive the user input. which user interface component will receive the user input.
Focusless User Interface: A user interface which has no ability to Focusless Device: A user device which has no ability to perform focus
perform focus determination. An example of a focusless user determination. An example of a focusless device is a telephone
interface is a keypad on a telephone. with a keypad.
Presentation Capable UI: A user interface which can prompt the user Presentation Capable UI: A user interface which can prompt the user
with input, collect results, and then prompt the user with new with input, collect results, and then prompt the user with new
information based on those results. information based on those results.
Presentation Free UI: A user interface which cannot prompt the user Presentation Free UI: A user interface which cannot prompt the user
with information. with information.
Feature Interaction: A class of problems which result when multiple Feature Interaction: A class of problems which result when multiple
applications or application components are trying to provide applications or application components are trying to provide
skipping to change at page 29, line 7 skipping to change at page 29, line 7
clear to which application the user input is targeted. clear to which application the user input is targeted.
As another example, consider the same two applications, but on a As another example, consider the same two applications, but on a
"smart phone" that has a set of buttons, and next to each button, an "smart phone" that has a set of buttons, and next to each button, an
LCD display that can provide the user with an option. This user LCD display that can provide the user with an option. This user
interface can be represented using the Wireless Markup Language interface can be represented using the Wireless Markup Language
(WML). (WML).
The phone would allocate some number of buttons to each application. The phone would allocate some number of buttons to each application.
The prepaid calling card would get one button for its "hangup" The prepaid calling card would get one button for its "hangup"
command, and the recording application would get one for its "start/ command, and the recording application would get one for its
stop" command. The user can easily determine which application to "start/stop" command. The user can easily determine which
interact with by pressing the appropriate button. Pressing a button application to interact with by pressing the appropriate button.
determines focus and provides user input, both at the same time. Pressing a button determines focus and provides user input, both at
the same time.
Unfortunately, not all devices will have these advanced displays. A Unfortunately, not all devices will have these advanced displays. A
PSTN gateway, or a basic IP telephone, may only have a 12-key keypad. PSTN gateway, or a basic IP telephone, may only have a 12-key keypad.
The user interfaces for these devices are provided through the Keypad The user interfaces for these devices are provided through the Keypad
Markup Language (KPML). Considering once again the feature Markup Language (KPML). Considering once again the feature
interaction case above, the pre-paid calling card application and the interaction case above, the pre-paid calling card application and the
call recording application would both pass a KPML document to the call recording application would both pass a KPML document to the
device. When the user presses a button on the keypad, to which device. When the user presses a button on the keypad, to which
document does the input apply? The user interface does not allow the document does the input apply? The device does not allow the user to
user to select. A user interface where the user cannot provide focus select. A device where the user cannot provide focus is called a
is called a focusless user interface. This is quite a hard problem focusless device. This is quite a hard problem to solve. This
to solve. This framework does not make any explicit normative framework does not make any explicit normative recommendation, but
recommendation, but concludes that the best option is to send the concludes that the best option is to send the input to both user
input to both user interfaces unless the markup in one interface has interfaces unless the markup in one interface has indicated that it
indicated that it should be suppressed from others. This is a should be suppressed from others. This is a sensible choice by
sensible choice by analogy - its exactly what the existing circuit analogy - its exactly what the existing circuit switched telephone
switched telephone network will do. It is an explicit non-goal to network will do. It is an explicit non-goal to provide a better
provide a better mechanism for feature interaction resolution than mechanism for feature interaction resolution than the PSTN on devices
the PSTN on devices which have the same user interface as they do on which have the same user interface as they do on the PSTN. Devices
the PSTN. Devices with better displays, such as PCs or screen with better displays, such as PCs or screen phones, can benefit from
phones, can benefit from the capabilities of this framework, allowing the capabilities of this framework, allowing the user to determine
the user to determine which application they are interacting with. which application they are interacting with.
Indeed, when a user provides input on a focusless device, the input Indeed, when a user provides input on a focusless device, the input
must be passed to all client local user interfaces, AND all client must be passed to all client local user interfaces, AND all client
remote user interfaces, unless the markup tells the UI to suppress remote user interfaces, unless the markup tells the UI to suppress
the media. In the case of KPML, key events are passed to remote user the media. In the case of KPML, key events are passed to remote user
interfaces by encoding them in RFC 2833 [17]. Of course, since a interfaces by encoding them in RFC 2833 [17]. Of course, since a
client cannot determine if a media stream terminates in a remote user client cannot determine if a media stream terminates in a remote user
interface or not, these key events are passed in all audio media interface or not, these key events are passed in all audio media
streams unless the KPML request document is used to suppress. streams unless the KPML request document is used to suppress.
skipping to change at page 30, line 13 skipping to change at page 30, line 17
An application can instantiate a multiplicity of user interface An application can instantiate a multiplicity of user interface
components. For example, a single application can instantiate two components. For example, a single application can instantiate two
separate HTML components and one WML component. Furthermore, an separate HTML components and one WML component. Furthermore, an
application can instantiate both client local and client remote user application can instantiate both client local and client remote user
interfaces. interfaces.
The feature interaction issues between these components within the The feature interaction issues between these components within the
same application are less severe. If an application has multiple same application are less severe. If an application has multiple
client user interface components, their interaction is resolved client user interface components, their interaction is resolved
identically to the inter-application case - through focus identically to the inter-application case - through focus
determination. However, the problems in focusless user interfaces determination. However, the problems in focusless user devices (such
(such as a keypad) generally won't exist, since the application can as a keypad on a telephone) generally won't exist, since the
generate user interfaces which do not overlap in their usage of an application can generate user interfaces which do not overlap in
input. their usage of an input.
The real issue is that the optimal user experience frequently The real issue is that the optimal user experience frequently
requires some kind of coupling between the differing user interface requires some kind of coupling between the differing user interface
components. This is a classic problem in multi-modal user components. This is a classic problem in multi-modal user
interfaces, such as those described by Speech Application Language interfaces, such as those described by Speech Application Language
Tags (SALT). As an example, consider a user interface where a user Tags (SALT). As an example, consider a user interface where a user
can either press a labeled button to make a selection, or listen to a can either press a labeled button to make a selection, or listen to a
prompt, and speak the desired selection. Ideally, when the user prompt, and speak the desired selection. Ideally, when the user
presses the button, the prompt should cease immediately, since both presses the button, the prompt should cease immediately, since both
of them were targeted at collecting the same information in parallel. of them were targeted at collecting the same information in parallel.
skipping to change at page 37, line 31 skipping to change at page 37, line 31
February 2003. February 2003.
[5] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Indicating User [5] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Indicating User
Agent Capabilities in the Session Initiation Protocol (SIP)", Agent Capabilities in the Session Initiation Protocol (SIP)",
RFC 3840, August 2004. RFC 3840, August 2004.
[6] Sparks, R., "The Session Initiation Protocol (SIP) Refer [6] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[7] Burger, E., "A Session Initiation Protocol (SIP) Event Package [7] Burger, E., "A Session Initiation Protocol (SIP) Event Package
for Key Press Stimulus (KPML)", draft-ietf-sipping-kpml-04 for Key Press Stimulus (KPML)", draft-ietf-sipping-kpml-07
(work in progress), July 2004. (work in progress), December 2004.
[8] Rosenberg, J., "Obtaining and Using Globally Routable User Agent [8] Rosenberg, J., "Obtaining and Using Globally Routable User Agent
(UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)",
draft-ietf-sip-gruu-02 (work in progress), July 2004. draft-ietf-sip-gruu-02 (work in progress), July 2004.
[9] Camarillo, G., "The Internet Assigned Number Authority (IANA) [9] Camarillo, G., "The Internet Assigned Number Authority (IANA)
Header Field Parameter Registry for the Session Initiation Header Field Parameter Registry for the Session Initiation
Protocol (SIP)", draft-ietf-sip-parameter-registry-02 (work in Protocol (SIP)", BCP 98, RFC 3968, December 2004.
progress), June 2004.
16.2 Informative References 16.2 Informative References
[10] Peterson, J., "Enhancements for Authenticated Identity [10] Peterson, J., "Enhancements for Authenticated Identity
Management in the Session Initiation Protocol (SIP)", Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-03 (work in progress), September 2004. draft-ietf-sip-identity-03 (work in progress), September 2004.
[11] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and [11] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000. Instant Messaging", RFC 2778, February 2000.
[12] Jennings, C., Peterson, J. and M. Watson, "Private Extensions [12] Jennings, C., Peterson, J. and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002. within Trusted Networks", RFC 3325, November 2002.
[13] Rosenberg, J., "A Framework for Conferencing with the Session [13] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol", Initiation Protocol",
draft-ietf-sipping-conferencing-framework-02 (work in draft-ietf-sipping-conferencing-framework-03 (work in
progress), June 2004. progress), October 2004.
[14] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller [14] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)", RFC Preferences for the Session Initiation Protocol (SIP)", RFC
3841, August 2004. 3841, August 2004.
[15] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog [15] Rosenberg, J., "An INVITE Inititiated Dialog Event Package for
Event Package for the Session Initiation Protocol (SIP)", the Session Initiation Protocol (SIP)",
draft-ietf-sipping-dialog-package-04 (work in progress), draft-ietf-sipping-dialog-package-05 (work in progress),
February 2004. November 2004.
[16] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, [16] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC "RTP: A Transport Protocol for Real-Time Applications", RFC
3550, July 2003. 3550, July 2003.
[17] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, [17] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000. Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[18] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [18] 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.
skipping to change at page 38, line 43 skipping to change at page 38, line 42
Author's Address Author's Address
Jonathan Rosenberg Jonathan Rosenberg
Cisco Systems Cisco Systems
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
Phone: +1 973 952-5000 Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
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
skipping to change at page 39, line 41 skipping to change at page 39, line 41
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 AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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