Internet DRAFT - draft-wu-sipping-media-recording
draft-wu-sipping-media-recording
Transport Area X. Wu
Internet-Draft V. Krishnaswamy
Expires: December 9, 2006 Avaya Labs Research
June 7, 2006
Using SIP Event Package and CONSENT Request for Media Recording
draft-wu-sipping-media-recording-00.txt
Status of this Memo
By submitting this Internet-Draft, each 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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 9, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Media recording enables the parties of a conversation to record all
or part of the conversation. Automatic recording may bring great
convenience to users. However, federal law requires the parties of a
conversation to have a consent for media recording. In addition, FCC
requires the recorded parties must be notified before the recording.
These requirements make automatic recording impossible without
defining a mechanism to negotiate the consent and send recording
notifications. This document defines a SIP event package for
Wu & Krishnaswamy Expires December 9, 2006 [Page 1]
Internet-Draft media-recording June 2006
recording event notifications and use the SIP CONSENT method to
negotiate a consent among multiple parties for media recording.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Acquiring conversation parties' location information . . . . . 4
5. Using CONSENT request to negotiate recording consent . . . . . 5
5.1. Negotiating consent before the conversation . . . . . . . 7
6. Using recording event package for recording notifications . . 7
7. Recording a conference . . . . . . . . . . . . . . . . . . . . 8
8. Integrating with PSTN . . . . . . . . . . . . . . . . . . . . 9
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. XML Schema Definitions . . . . . . . . . . . . . . . . . . . . 11
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 13
11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 14
12. Security Considerations . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Wu & Krishnaswamy Expires December 9, 2006 [Page 2]
Internet-Draft media-recording June 2006
1. Introduction
Media recording is important for communications. With media
recording, people can get reminded of their previous conversations,
or play back some special moments. Many times, it is too late when
people want to start recording. Some events are just unrepeatable,
e.g., children's first laugh over the phone. Given that most
Internet telephony endpoints have CPU and memory, it should be
straightforward to automatically start recording on an Internet
telephony endpoint when a conversation starts. When the conversation
ends, the endpoint can ask the user to upload the saved audio clips
to a permanent storage, e.g., uploading to a web server. However,
media recording may require consent from all parties of the
conversation, otherwise will be considered unlawful.
The federal law [6] makes it unlawful to record telephone
conversations except in one party consent cases which permit one
party consent recording by state law. What one party consent means
is a person can record their own telephone conversations without the
knowledge or consent of the other party in those states that allow
one party consent. In addition, the Federal Communications
Commission (FCC) goes further into details on recording telephone
conversations and states that the party recording must give verbal
notification before the recording and that there must be a beep tone
on the line to indicate that the line is being recorded.
To fulfull the federal law and FCC's requirements, we need to define
a mechanism to automatically negotiate recording consent based on the
location of the conversation parties, and send a recording
notification to all parties of the conversation. When an endpoint
starts to record, it first checks every party's physical location.
If all parties are in a place that requires one party consent for
recording, the endpoint can start recording immediately without
negotiating recording consent. Otherwise, the endpoint must send a
SIP [2] CONSENT [8] [3] request to all the parties that at the place
that requires all party consent. The endpoint must not start
recording until receiving positive responses of all the CONSENT
requests. Before starting to record, the endpoint should send a
recording start event to all the conversation parties.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Wu & Krishnaswamy Expires December 9, 2006 [Page 3]
Internet-Draft media-recording June 2006
3. Terminology
Recording: The operation that is performed by a recording party to
save part or all of the media streams of a conversation to a
permanent storage device.
Recording party: A recording party is the entity who will record
media streams of a conversation. The recording party may not be in
the conversation. If the recording party is in the conversation, the
recording party may record his/her own media streams.
Recorded party: A recorded party is the entity whose media streams
will be recorded by a recording party.
One party consent: One party consent means that one party to the
conversation must have knowledge and give consent to the recording.
In the United States, there are thirty eight states that permit one
party consent. They are Alaska, Arkansas, Colorado District of
Columbia, Georgia, Hawaii, Idaho, Indiana, Iowa Kansas, Kentucky,
Louisiana, Maine, Minnesota, Mississippi Missouri, Nebraska, Nevada,
New Jersey, New Mexico, New York North Carolina, North Dakota, Ohio,
Oklahoma, Oregon, Rhode Island South Carolina, South Dakota,
Tennessee, Texas, Utah, Vermont Virginia, West Virginia, Wisconsin,
and Wyoming. [9]
Two party or all party consent: Two party or all party consent means
that every party to the conversation must have knowledge and give
consent to the recording. In the United States, there are twelve
states require, under most circumstances, the consent of all parties
to a conversation. Those jurisdictions are California, Connecticut,
Florida, Illinois, Maryland, Massachusetts, Michigan, Montana,
Nevada, New Hampshire, Pennsylvania and Washington. [9]
4. Acquiring conversation parties' location information
When an endpoint wants to start recording, the endpoint should check
all the conversation parties' location information. It can use SIP
SUBSCRIBE requests [5] to acquire remote parties' location
information. The location information can be presented in Presence-
based GEOPRIV Location Object Format (pidf-lo) [10] and sent in SIP
NOTIFY requests [5]. For the remote parties that have unknown
location or at a location requiring all party consent, the endpoint
MUST use SIP CONSENT requests to acquire the consents from these
parties. The endpoint MUST NOT start recording until receiving
positive consent response from all the parties that have unknown
location or requiring all party consent.
Wu & Krishnaswamy Expires December 9, 2006 [Page 4]
Internet-Draft media-recording June 2006
5. Using CONSENT request to negotiate recording consent
The Framework for Consent-Based Communications in the Session
Initiation Protocol [8] uses an asynchoronous way to acquire
consents. The party who sends a CONSENT request should first send a
SUBSCRIBE request for the "grant-permission" events. The reason is
that users are not on-line all the time, so, sometimes are not able
to receive CONSENT requests. But for negotiating recording consent,
we expect all parties are online and be able to give or deny the
permission needed for doing the recording. So, the recording consent
negotiation should be in a synchronous way. The recipients of
CONSENT requests should use "200 Ok" response to grant a permission,
and "403 Forbidden" or "603 Decline" response to deny a recording
permission. [[Comment.1: The current proposal of SIP CONSENT
methodis designed specifically for SIP relays to handle permissions
to perform translations. It may be desirable to define a more
general SIP CONSENT method to handle different consent negotiations,
including but not limited to recording consent negotiation, among
multiple parties.]][3]
The CONSENT requests sent by the recording party should indicate that
the purpose of the consent is for recording. The request should also
provide the information about what type of media streams will be
recorded and in what mode. The mode information indicates whether
the recording will be done in an "all-or-none" mode or in "partial"
mode. If the recording is done in "all-or-none" mode, media streams
from all parties will be recorded and saved in one media clip. If
the recording is done in "partial" mode, only part of the
conversation parties' media streams will be recorded. These
information can be conveyed by using one or more "Consent-Needed"
header field. For example, the "Consent-Needed" header below asks
for consent from sip:tom@example.com for recording permission on both
audio and video. The recording mode is "partial" for both audio and
video.
Consent-Needed: sip:tom@example.com;
purpose=recording;audio;video;mode=partial
The "Consent-Needed" headers below also ask for consent from
sip:tom@example.com for recording permission on both audio and video.
But the recording mode is "all-or-none" for audio, and "partial" for
video.
Consent-Needed: sip:tom@example.com;
purpose=recording;audio;mode=all-or-none
Consent-Needed: sip:tom@example.com;
purpose=recording;video;mode=partial
Wu & Krishnaswamy Expires December 9, 2006 [Page 5]
Internet-Draft media-recording June 2006
[[Comment.2: Note that we may also use an XML document to describe
the consent. Using XML document seems more flexible than using a SIP
header. We can easily specify the starting time, the ending time,
and the duration of a recording. For example, we can set the
Content-Type as "application/consent+xml" and have an XML document
like]]
<xml version="1.0"?>
<consent id="a7b8c65a">
<sender uri="sip:tom@example.com"/>
<recipient uri="sip:bob@example.com"/>
<purpose purpose="session-recording">
<session-recording id="123456" mode="mixed">
<call-leg uri="sip:bob@example.com"
call-id="a1b2c3d4@10.1.2.3">
<media type="audio" mid="mid:1"
from="2005-11-30T22:30:00Z"
until="2005-11-30T23:00:00Z"/>
<media type="video" mid="mid:2"/>
</call-leg>
<call-leg uri="sip:tom@example.com"
call-id="a1b2c3d4@10.1.2.3">
<media type="audio" mid="mid:1"
from="2005-11-30T22:30:00Z"
until="2005-11-30T23:00:00Z"/>
</call-leg>
</session-recording>
</purpose>
</consent>
CONSENT requests for recording a session should be sent inside the
session and have the same Call-ID as the INVITE request for the
session.
A CONSENT request should use the 'Expires' header to indicate how
long the recording party wants to record the conversation. If the
header is not presented, by default, it means the recording will
continue until the end of the session. The recorded parties should
use the 'Expires' header in its '200 Ok' response to indicate how
long they would like to be recorded. The recording party MUST use
the shortest expiration time from all recorded parties to handle the
recording if the recording is done in the "all-or-none" mode.
[[Comment.3: Note that an endpoint may cache media streams so the
starting time of a recording may before the time of sending the
CONSENT request. That's another reason that using a consent XML
document is a better way.]]
Wu & Krishnaswamy Expires December 9, 2006 [Page 6]
Internet-Draft media-recording June 2006
5.1. Negotiating consent before the conversation
With the CONSENT request, it is possible for people to negotiate a
recording consent before the conversation so people can record the
whole conversation once it starts. There are several ways to handle
this. We can put the consent XML document as a MIME content in the
SIP INVITE request. We can also send a CONSENT request before the
initial INVITE has been completed, like the way used by SIP UPDATE
requests [11], as shown in Figure 4.
Recording Recorded
| |
|---(1) INVITE ---->|
| |
|<--(2) 180 --------|
| |
|---(3) CONSENT---->|
| |
|<--(4) 200 OK------|
| (for CONSENT) |
| |
|<--(5) 200 OK------|
| (for INVITE) |
| |
|---(6) ACK ------->|
| (start recording) |
| |
Figure 4: CONSENT before the conversation
6. Using recording event package for recording notifications
Before starting a recording, the recording party SHOULD send
notifications to all recorded parties about the recording. The event
information is carried as XML, and with the content type as
application/session-recording+xml. The document MUST indicate when
the recording started, what's the duration of the recording, and the
information of the recorded parties, medias, and modes. [[Comment.4:
Note that even the recorded parties did not subscribe for this event,
the recording party SHOULD still send this notification to fulfill
the requirement of FCC. Since the recording operation is part of a
session and very closely related to the dialog of a session, the
session-recording notification may need to be considered as an INVITE
initiated event package. Maybe there should be an embeded FSM to
handle recording in the "Confirmed" state in SIP dialog state
machine.]][7] [[Comment.5: The other way to initiate the session
recording notification is to treat the notification as a CONSENT
Wu & Krishnaswamy Expires December 9, 2006 [Page 7]
Internet-Draft media-recording June 2006
triggered notification, like the way used by SIP REFER
requests.]][12] The XML document below shows an example of session-
recording notification.
....
Content-Type: application/session-recording+xml
....
<?xml version="1.0" encoding="UTF-8"?>
<session-recording
xmlns="urn:ietf:params:xml:ns:session-recording"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
id="123456" mode="mixed">
<call-leg uri="sip:bob@example.com"
call-id="a1b2c3d4@10.1.2.3"
consent-id="a7b8c65a">
<media type="audio" mid="mid:1"
from="2005-11-30T22:30:00Z"
until="2005-11-30T23:00:00Z"/>
<media type="video" mid="mid:2"/>
</call-leg>
<call-leg uri="sip:tom@example.com"
call-id="a1b2c3d4@10.1.2.3">
<media type="audio" mid="mid:1"
from="2005-11-30T22:30:00Z"
until="2005-11-30T23:00:00Z"/>
</call-leg>
</session-recording>
7. Recording a conference
When a conference participant wants to record a conference, the
participant MUST acquire consents from all other conference
participants. Since usually a conference participant does not know
other conference participants' session information, the recording
party has to send a CONSENT request to the conference server and the
conference server will then ask for consents from other conference
participants on behalf of the recording party. The conference server
can use a "Consent-RequestedBy" header to carry the information of
the recording party. For example, the "Consent-RequestedBy" header
below indicates the CONSENT request is sent on behalf of
"sip:tom@example.com".
Consent-RequestedBy: sip:tom@example.com
[[Comment.6: Note that a consent XML document seems a better
solution. A consent XML document can clearly indicate who is
requiring a consent. The recording party does not have to be the
Wu & Krishnaswamy Expires December 9, 2006 [Page 8]
Internet-Draft media-recording June 2006
sender of the CONSENT request.]]
8. Integrating with PSTN
When a SIP phone user is talking with a PSTN phone user, the SIP
phone user cannot directly use the CONSENT method to negotiate a
recording consent with the PSTN phone user. There must be an
application server, or a gateway in between, and have an Interactive
Voice Response (IVR) system to handle text to speech (TTS) and speech
to text (STT).
+-------+ +-----------+ +--------+
| IP | CONSENT |Application| IVR | Voice |
| phone +----------+ server +-----+ portal |
+-------+ +-----+-----+ +--------+
|
|
+----+----+ +-------+
| PSTN | | POTS |
+ gateway +-------+ phone |
+---------+ +-------+
Figure 7: Makeing consent through an application server
Figure 7 shows how to negotiate a recording consent between an IP
phone and a POTS phone. The IP phone sends a CONSENT request to the
application server. The application server brings the voice portal
in the conversation by asking recording consent verbally. The POTS
phone user can respond by saying "yes" or "no" for the recording
consent, and may be prompted for more recording parameters, such as
how long the recording should be. Through the voice portal, the
application server can get all the required information for
generating a response for the CONSENT request, and send back to the
IP phone.
Wu & Krishnaswamy Expires December 9, 2006 [Page 9]
Internet-Draft media-recording June 2006
+--------+
IVR | Voice |
+--------+ portal |
| +--------+
|
|
+-------+ +------+--+ +-------+
| IP | CONSENT | PSTN | | POTS |
| phone +-----------+ gateway +------+ phone |
+-------+ +---------+ +-------+
Figure 8: Makeing consent through a PSTN gateway
Figure 8 shows the way of using a PSTN gateway directly talk to the
voice portal for TTS and STT.
9. Examples
Recording Recorded
| |
|--(1) SUBSCRIBE--->|
| location info-->|
| |
|<-(2) NOTIFY-------|
| ...A1="CA"...----|
| |
|---(3) CONSENT---->|
| |
|<--(4) 200 OK------|
|---(5) NOTIFY----->|
|<--(6) 200 OK------|
|(start recording) |
| |
Figure 9: Two party recording
Figure 9 shows a two party recording consent negotiation process.
The recording party first sends a SUBSCRIBE for the recorded party's
location information. The recorded party is in California, which
requires two party consent. The recording party then sends a CONSENT
request asking for recording consent from the recorded party. Once
the recording party gets the 200 OK response, it will send a NOTIFY
for the recording and then start to record.
Wu & Krishnaswamy Expires December 9, 2006 [Page 10]
Internet-Draft media-recording June 2006
Recording Conference Recorded Recorded
Server
| | | |
|---(1) CONSENT---->| | |
|<--(2) 100 Trying--| | |
| |---(3) CONSENT---->| |
| |---(4) CONSENT---------------------->|
| |<--(5) 200 OK------| |
| |<--(6) 200 OK------------------------|
|<--(7) 200 OK------| | |
|---(8) NOTIFY----->| | |
| |---(9) NOTIFY----->| |
| |---(10) NOTIFY---------------------->|
|<--(11) 200 OK-----| | |
|(start recording) | | |
| | | |
Figure 10: Recording a conference
Figure 10 shows how to acquire recording consent in a conference.
The recording party sends a CONSENT request to the conference server.
The conference server then sends CONSENT requests to all the
conference participants. Upon receiving all consents, the conference
server sends a "200 Ok" response to the recording party. The
recording party starts recording and sends a NOTIFY for recording
started event. The conference server relay the NOTIFY to all the
recorded parties.
10. XML Schema Definitions
The session-recording schema is shown below. We expect a separate
document defining the XML schema for consent negotiation.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:session-recording"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:session-recording"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="session-recording">
<xs:complexType>
<xs:sequence>
<xs:element name="call-leg" type="CallLegType"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
Wu & Krishnaswamy Expires December 9, 2006 [Page 11]
Internet-Draft media-recording June 2006
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="mode" use="optional" default="mixed">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="non-mixed"/>
<xs:enumeration value="mixed"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:complexType name="CallLegType">
<xs:sequence>
<xs:element name="media" type="MediaType"
minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>If no media provided, all the media
streams from the call will be recorded.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
<xs:attribute name="uri" type="xs:anyURI" use="required"/>
<xs:attribute name="call-id" type="xs:string" use="required"/>
<xs:attribute name="consent-id" type="xs:string" use="optional"/>
</xs:complexType>
<xs:complexType name="MediaType">
<xs:attribute name="type" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="audio"/>
<xs:enumeration value="video"/>
<xs:enumeration value="text"/>
<xs:enumeration value="application"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="mid" use="optional" type="xs:string">
<xs:annotation>
<xs:documentation>If no mid provided, all streams with the
same media type will be recorded.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="from" use="optional" type="xs:date">
<xs:annotation>
<xs:documentation>If no "from" provided, recording
starts immediately after the session-recording
notification. Note that the value of "from" may
before the current time.</xs:documentation>
Wu & Krishnaswamy Expires December 9, 2006 [Page 12]
Internet-Draft media-recording June 2006
</xs:annotation>
</xs:attribute>
<xs:attribute name="until" use="optional" type="xs:date">
<xs:annotation>
<xs:documentation>If no until provided, recording lasts
until the end of the session.</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
</xs:schema>
Figure 11: XML schema for session-recording
11. IANA Considerations
11.1. URN Sub-Namespace Registration
This section registers a new XML namespace, per the guidelines in [4]
URI: The URI for this namespace is
urn:ietf:params:xml:ns:session-recording.
Registrant Contact: Xiaotao Wu (xwu@avaya.com), Venkatesh
Krishnaswamy (venky@avaya.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Session Recording Notification Namespace</title>
</head>
<body>
<h1>Namespace for Session Recording Notification</h1>
<h2>urn:ietf:params:xml:ns:session-recording</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
Wu & Krishnaswamy Expires December 9, 2006 [Page 13]
Internet-Draft media-recording June 2006
11.2. XML Schema Registration
This section registers one XML schemas per the procedures in [4].
URI: urn:ietf:params:xml:ns:session-recording.
Registrant Contact: Xiaotao Wu (xwu@avaya.com), Venkatesh
Krishnaswamy (venky@avaya.com).
The XML for this schema can be found in Section 10.
12. Security Considerations
TBD [[Comment.7: The same security considerations of the framework
for Consent-Based Communications in SIP applied here. The parties
who grant permissions for recording should have the consent documents
signatured.]]
13. References
13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCD 14, March 1997.
[2] Rosenberg et al., J., "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[3] Camarillo, G., "The Session Initiation Protocol (SIP) CONSENT
Method", draft-camarillo-sip-consent-method-00.txt (work in
progress), February 2006.
[4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[6] PUBLIC LAW 99-508, "Electronic Communications Privacy Act of
1986", October 1986.
[7] Rosenberg, J., "An INVITE Inititiated Dialog Event Package for
the Session Initiation Protocol (SIP)",
draft-ietf-sipping-dialog-package-06 (work in progress),
April 2005.
Wu & Krishnaswamy Expires December 9, 2006 [Page 14]
Internet-Draft media-recording June 2006
13.2. Informative References
[8] Rosenberg, J., "A Framework for Consent-Based Communications in
the Session Initiation Protocol (SIP)",
draft-ietf-sipping-consent-framework-04 (work in progress),
February 2006.
[9] The Reporters Committee for Freedom of the Press, "A Practical
Guide to Taping Phone Calls and In-Person Conversations in the
50 States and D.C.", December 2003.
[10] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[11] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[12] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
Wu & Krishnaswamy Expires December 9, 2006 [Page 15]
Internet-Draft media-recording June 2006
Authors' Addresses
Xiaotao Wu
Avaya Labs Research
307 Middletown Lincroft Road
Lincroft 07738
USA
Email: xwu@avaya.com
Venkatesh Krishnaswamy
Avaya Labs Research
307 Middletown Lincroft Road
Lincroft 07738
USA
Email: venky@avaya.com
Wu & Krishnaswamy Expires December 9, 2006 [Page 16]
Internet-Draft media-recording June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Wu & Krishnaswamy Expires December 9, 2006 [Page 17]
