draft-ietf-siprec-req-03.txt   draft-ietf-siprec-req-04.txt 
DISPATCH K. Rehor, Ed. DISPATCH K. Rehor, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational R. Jain Intended status: Informational R. Jain
Expires: April 15, 2011 IPC Systems Expires: April 29, 2011 IPC Systems
L. Portman L. Portman
NICE Systems NICE Systems
A. Hutton A. Hutton
Siemens Enterprise Communications Siemens Enterprise Communications
October 12, 2010 October 25, 2010
Requirements for SIP-based Media Recording (SIPREC) Requirements for SIP-based Media Recording (SIPREC)
draft-ietf-siprec-req-03 draft-ietf-siprec-req-04
Abstract Abstract
Session recording is a critical requirement in many business Session recording is a critical requirement in many business
communications environments such as call centers and financial communications environments such as call centers and financial
trading floors. In some of these environments, all calls must be trading floors. In some of these environments, all calls must be
recorded for regulatory and compliance reasons. In others, calls may recorded for regulatory and compliance reasons. In others, calls may
be recorded for quality control or business analytics. be recorded for quality control or business analytics.
Recording is typically done by sending a copy of the session media to Recording is typically done by sending a copy of the session media to
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 15, 2011. This Internet-Draft will expire on April 29, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 10 skipping to change at page 3, line 10
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Example Deployment Architectures . . . . . . . . . . . . . . . 6 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Normative References . . . . . . . . . . . . . . . . . . . . . 15
11. Normative References . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Requirements notation 1. Requirements notation
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 [RFC2119] and indicate document are to be interpreted as described in [RFC2119] and indicate
requirement levels for compliant mechanisms. requirement levels for compliant mechanisms.
2. Introduction 2. Introduction
skipping to change at page 5, line 8 skipping to change at page 5, line 8
Communication Session." The Session Recording Client is the source Communication Session." The Session Recording Client is the source
of the recorded media. The Session Recording Server is the sink of of the recorded media. The Session Recording Server is the sink of
recorded media. It should be noted that the requirements for the recorded media. It should be noted that the requirements for the
protocol between a Session Recording Server and Session Recording protocol between a Session Recording Server and Session Recording
Client have very similar requirements (such as codec and transport Client have very similar requirements (such as codec and transport
negotiation, encryption key interchange, firewall traversal) as negotiation, encryption key interchange, firewall traversal) as
compared to regular SIP media sessions. The choice of SIP for compared to regular SIP media sessions. The choice of SIP for
session recording provides reuse of an existing protocol. session recording provides reuse of an existing protocol.
The recorded sessions can be any RTP media sessions including voice, The recorded sessions can be any RTP media sessions including voice,
video, and text (as defined by [RFC4103]). DTMF (as defined by [RFC4733]), video, and text (as defined by
[RFC4103]).
An archived session recording is typically comprised of the An archived session recording is typically comprised of the
Communication Session media content and the Communication Session Communication Session media content and the Communication Session
Metadata. The Communication Session Metadata allows recording Metadata. The Communication Session Metadata allows recording
archives to be searched and filtered at a later time and allows a archives to be searched and filtered at a later time and allows a
session to be played back in a meaningful way, e.g., with correct session to be played back in a meaningful way, e.g., with correct
synchronization between the media. The Communication Session synchronization between the media. The Communication Session
Metadata needs to be conveyed from the Session Recording Client to Metadata needs to be conveyed from the Session Recording Client to
the Session Recording Server. (The requirements for session metadata the Session Recording Server. (The requirements for session metadata
delivery are specified separately [draft-ram-siprec-metadata-00]). delivery are specified separately [draft-ram-siprec-metadata-00]).
skipping to change at page 6, line 11 skipping to change at page 6, line 12
Communication Session (CS): A session created between two or more SIP Communication Session (CS): A session created between two or more SIP
User Agents (UAs) that is the target for recording. User Agents (UAs) that is the target for recording.
Recording Session (RS): The SIP session created between an SRC and Recording Session (RS): The SIP session created between an SRC and
SRS for the purpose of recording a Communication Session. SRS for the purpose of recording a Communication Session.
Figure 1 pictorially represents the relationship between a Recording Figure 1 pictorially represents the relationship between a Recording
Session and Communication Session. Session and Communication Session.
+---------------------------------------------------------------+ +-------------+ +-----------+
| (Session Recording Client) | | | Communication Session | |
| +-------------+ +-----------+ | | A |<------------------------------------>| B |
| | | Communication Session | | | | | | |
| | A |<------------------------->| B | | +-------------+ +-----------+
| | | | | | ..................................................................
| +-------------+ +-----------+ | . Session .
+---------------------------------------------------------------+ . Recording .
| . Client .
| Recording ..................................................................
| Session |
| | Recording
v | Session
+-------------+ |
| | v
| Session | +------------+
| Recording | | Session |
| Server | | Recording |
| | | Server |
+-------------+ +------------+
Figure 1 Figure 1
Metadata: Information that describes recorded media and the CS to Metadata: Information that describes recorded media and the CS to
which they relate. which they relate.
SIPREC: The set of SIP extensions that supports recording of SIPREC: The set of SIP extensions that supports recording of
Communication Sessions. Communication Sessions.
Pause and Resume during a Communication Session: Pause: The action of Pause and Resume during a Communication Session: Pause: The action of
temporarily discontinuing the recording of media during a CS. temporarily discontinuing the recording of media during a CS.
Resume: The action of recommencing the recording of media for a CS Resume: The action of recommencing the recording of media for a CS
following a pause. following a pause.
4. Example Deployment Architectures 4. Use Cases
A recording system deployment consists of the Recording Client and
Recording Server. Recording Control is bi-directional; Recording
Media and Communication Session (CS) Metadata are sent from the SRC
to SRS.
+-------------+ +--------------+
| | CS Metadata | |
| Session |-------------------------->| Session |
| Recording | | Recording |
| Client | Recording Control | Server |
| (SRC) |<------------------------->| (SRS) |
| | | |
| | Recorded Media | |
| |-------------------------->| |
| | | |
+-------------+ +--------------+
Figure 2
5. Use Cases
Use Case 1: Full-time Recording: One (or more, in the case of Use Case 1: Full-time Recording: One (or more, in the case of
redundant recording) Recording Session for each Communication redundant recording) Recording Session for each Communication
Session. Session.
For example, the diagram below shows the lifecycle of Communication For example, the diagram below shows the lifecycle of Communication
Sessions (CS) and the relationship to the Recording Sessions (RS) Sessions (CS) and the relationship to the Recording Sessions (RS)
CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---|
RS |--- RS 1 ---| |--- RS 2 ---| |--- RS 3 ---| RS |--- RS 1 ---| |--- RS 2 ---| |--- RS 3 ---|
Figure 3 Figure 2
Record every call for specific extension/person. Record every CS for specific extension/person.
The need to record all calls is typically due to business process The need to record all calls is typically due to business process
purposes (such as transaction confirmation or dispute resolution) or purposes (such as transaction confirmation or dispute resolution) or
to ensure compliance with governmental regulations. Applications to ensure compliance with governmental regulations. Applications
include enterprise, contact center, and financial trading floors. include enterprise, contact center, and financial trading floors.
Also commonly known as Total Recording. Also commonly known as Total Recording.
Use Case 2: Selective Recording: Start a Recording Session when a Use Case 2: Selective Recording: Start a Recording Session when a
Communication Session to be recorded is established. Communication Session to be recorded is established.
In this example, Communication Sessions 1 and 3 are recorded but CS 2 In this example, Communication Sessions 1 and 3 are recorded but CS 2
is not. is not.
CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---|
RS |--- RS 1----| |--- RS 2 ---| RS |--- RS 1----| |--- RS 2 ---|
Figure 4 Figure 3
Use Case 3: Dynamic Recording: Start/Stop a Recording Session during Use Case 3: Dynamic Recording: Start/Stop a Recording Session during
a Communication Session. a Communication Session.
The Recording Session starts during a Communication Session, either The Recording Session starts during a Communication Session, either
manually via a user-controlled mechanism (e.g. button on user's manually via a user-controlled mechanism (e.g. button on user's
phone) or automatically via an application (e.g. a Contact Center phone) or automatically via an application (e.g. a Contact Center
customer service application) or business event. A Recording Session customer service application) or business event. A Recording Session
either ends during the Communication Session, or when the either ends during the Communication Session, or when the
Communication Session ends. Communication Session ends.
One or more Recording Sessions per Communication Session: One or more Recording Sessions per Communication Session:
CS |------------- Communication Session -----------| CS |------------- Communication Session -----------|
RS |---- RS 1 ----| |---- RS 2 -----| RS |---- RS 1 ----| |---- RS 2 -----|
Figure 5 Figure 4
Also known as Mid-session or Mid-call Recording. Also known as Mid-session or Mid-call Recording.
Use Case 4: Persistent Recording: A single Recording Session captures Use Case 4: Persistent Recording: A single Recording Session captures
one or more Communication Sessions, in sequence (Fig. 6) or in one or more Communication Sessions, in sequence (Fig. 6) or in
parallel (Fig. 7). parallel (Fig. 7).
|--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---|
RS |---------------------- Recording Session ---------------------| RS |---------------------- Recording Session ---------------------|
Figure 6 Figure 5
A Recording Session records continuously without interruption. A Recording Session records continuously without interruption.
Silent periods must be reproduced upon playback (e.g. by recording Silent periods must be reproduced upon playback (e.g. by recording
the silent period, by not recording the silent periods but marking the silent period, by not recording the silent periods but marking
them as metadata for a player to utilize, etc.) Applications include them as metadata for a player to utilize, etc.) Applications include
financial trading desks and emergency (first-responder) service financial trading desks and emergency (first-responder) service
bureaus. The length of a Persistent Recording Sessions is bureaus. The length of a Persistent Recording Sessions is
independent from the length of the actual Communication Sessions. independent from the length of the actual Communication Sessions.
Persistent Recording Sessions avoid issues such as media clipping Persistent Recording Sessions avoid issues such as media clipping
that can occur due to delays in Recording Session establishment. that can occur due to delays in Recording Session establishment.
skipping to change at page 9, line 23 skipping to change at page 9, line 15
In some cases, more than one concurrent Communication Session (on a In some cases, more than one concurrent Communication Session (on a
single end-user apparatus, e.g. trading floor turret) is mixed into single end-user apparatus, e.g. trading floor turret) is mixed into
one Recording Session: one Recording Session:
|-------- CS 1 -------| |-------- CS 1 -------|
|-------- CS 2 -------| |-------- CS 2 -------|
|-------- CS 3 -------| |-------- CS 3 -------|
RS |----------- Recording Session --------------| RS |----------- Recording Session --------------|
Figure 7 Figure 6
Use Case 5: Real-time Recording Controls. Use Case 5: Real-time Recording Controls.
For an active Recording Session, privacy or security reasons may For an active Recording Session, privacy or security reasons may
demand not capturing a specific portion of a conversation. An demand not capturing a specific portion of a conversation. An
example is for PCI (payment card industry) compliance where credit example is for PCI (payment card industry) compliance where credit
card info must be protected. One solution is to not record a caller card info must be protected. One solution is to not record a caller
speaking their credit card information. speaking their credit card information.
An example of a real-time controls is Pause/Resume. An example of a real-time controls is Pause/Resume.
skipping to change at page 11, line 34 skipping to change at page 11, line 24
analytics. analytics.
Recording and real-time analytics of trading floor interactions Recording and real-time analytics of trading floor interactions
(including video and instant messaging). Real time analytics is (including video and instant messaging). Real time analytics is
required for automatic intervention (stopping interaction or alert) required for automatic intervention (stopping interaction or alert)
if for example, trader is not following regulations. if for example, trader is not following regulations.
Speaker separation is required in order to reliably detect who is Speaker separation is required in order to reliably detect who is
saying specific phrases. saying specific phrases.
6. Requirements 5. Requirements
The following are requirements for SIP-based Media Recording: The following are requirements for SIP-based Media Recording:
o REQ-000 The mechanism MUST provide a means for "using the SIP o REQ-000 The mechanism MUST provide a means for "using the SIP
protocol for" establishing, maintaining and terminating Recording protocol for" establishing, maintaining and terminating Recording
Sessions between a Session Recording Client and a Session Recording Sessions between a Session Recording Client and a Session Recording
Server. Server.
o REQ-001 The mechanism MUST support the ability to record all CSs in o REQ-001 The mechanism MUST support the ability to record all CSs in
their entirety. their entirety.
skipping to change at page 12, line 13 skipping to change at page 11, line 50
parts of selected CSs. parts of selected CSs.
o REQ-004 The mechanism MUST support the ability to record a CS o REQ-004 The mechanism MUST support the ability to record a CS
without an intentional loss of media (for example, clipping media at without an intentional loss of media (for example, clipping media at
the beginning of the CS) and without impacting the quality or timing the beginning of the CS) and without impacting the quality or timing
of the CS (for example, delaying the start of the CS while of the CS (for example, delaying the start of the CS while
preparation for recording takes place). See Use Case 4 in Section 5. preparation for recording takes place). See Use Case 4 in Section 5.
o REQ-007 The mechanism MUST support the recording of IVR sessions. o REQ-007 The mechanism MUST support the recording of IVR sessions.
o REQ-007bis1 The mechanism MUST support the recording of DTMF in- o REQ-008 The mechanism MUST support the recording of RTP media types
band audio. voice, DTMF (as defined by [RFC4733]), video, and text (as defined by
[RFC4103]).
o REQ-007bis2 The mechanism MUST support the recording of DTMF out-
of-band according to RFC2833.
o REQ-012 The mechanism MUST support the ability for an SRC to o REQ-012 The mechanism MUST support the ability for an SRC to
deliver mixed audio streams from multiple Communication Sessions to deliver mixed audio streams from multiple Communication Sessions to
an SRS. an SRS.
Note: A mixed audio stream is where several Communication Sessions Note: A mixed audio stream is where several Communication Sessions
are carried in a single Recording Session. A mixed media stream is are carried in a single Recording Session. A mixed media stream is
typically produced by a mixer function. The RS MAY be informed about typically produced by a mixer function. The RS MAY be informed about
the composition of the mixed streams through session metadata. the composition of the mixed streams through session metadata.
skipping to change at page 12, line 44 skipping to change at page 12, line 32
Recording Sessions to the SRS. Recording Sessions to the SRS.
o REQ-014 The mechanism MUST support the ability to deliver multiple o REQ-014 The mechanism MUST support the ability to deliver multiple
media streams for a given Communication Session over a single media streams for a given Communication Session over a single
Recording Session to the SRS. Recording Session to the SRS.
o REQ-015 The mechanism MUST support the ability to pause and resume o REQ-015 The mechanism MUST support the ability to pause and resume
the Recording Session from the SRC. the Recording Session from the SRC.
o REQ-016 The mechanism MUST support the ability to pause and resume o REQ-016 The mechanism MUST support the ability to pause and resume
the Recording Session from the SRS. the RS from the SRS.
o REQ-017 The mechanism MUST provide the SRS with metadata describing o REQ-017 The mechanism MUST provide the SRS with metadata describing
CSs that are being recorded, including the media being used and the CSs that are being recorded, including the media being used and the
identities of parties involved. identities of parties involved.
o REQ-018 The mechanism MUST provide the SRS with the means to o REQ-018 The mechanism MUST provide the SRS with the means to
correlate RS media with CS participant media described in metadata. correlate RS media with CS participant media described in metadata.
o REQ-019 The mechanism MUST support the ability to transport the
metadata in the same SIP dialog as the Recording Session.
o REQ-020 The mechanism MUST support the ability to transport the
metadata outside of the Recording Session SIP dialog.
o REQ-021 Metadata format must be agnostic of the transport protocol. o REQ-021 Metadata format must be agnostic of the transport protocol.
o REQ-022: The mechanism MUST support a means to cancel and discard o REQ-022: The mechanism MUST support a means to cancel and discard
the recording and associated metadata for a Communication Session. the recording and associated metadata for a CS.
o REQ-022bis: The mechanism MUST support a means to cancel and o REQ-022bis: The mechanism MUST support a means to cancel and
discard the recording but not the associated metadata for a discard the recording but not the associated metadata for a CS.
Communication Session.
o REQ-023 The mechanism MUST support a means for a SIP UA involved in
a CS to request, prior to the start of recording, that the CS not be
recorded
o REQ-024 The mechanism MUST provide a means of indicating to the end o REQ-023 The mechanism MUST support a means for an authorized
users of a Communication Session that the session in which they are participant involved in a CS to request, prior to the start of
participating is being recorded. recording, that the CS not be recorded
o REQ-024 The mechanism MUST provide a means of indicating to the
participants involved in a CS that their session is being recorded.
Examples include: inject tones into the Communication Session from Examples include: inject tones into the CS from the SRC, play a
the SRC, play a message at the beginning of a session, a visual message at the beginning of a session, a visual indicator on a
indicator on a display, etc. display, etc.
o REQ-025 The mechanism MUST provide a way for metadata to be o REQ-025 The mechanism MUST provide a way for metadata to be
conveyed to the SRS incrementally. conveyed to the SRS incrementally during the CS.
o REQ-028 The mechanism MUST NOT prevent high availability o REQ-028 The mechanism MUST NOT prevent high availability
deployments. deployments.
SECURITY
o REQ-029 The mechanism MUST support a means of providing security o REQ-029 The mechanism MUST support a means of providing security
(confidentiality, integrity and authentication) for the SIPREC. (confidentiality, integrity and authentication) for the SIPREC.
o REQ-030 The mechanism MUST provide a means for the Recording o REQ-030 The mechanism MUST provide a means for the Recording
Session identifier so that the Recording Session itself is labeled as Session identifier so that the Recording Session itself is labeled as
a SIP session that is established for the purpose of recording. a SIP session that is established for the purpose of recording.
o REQ-031 If the Communication Session is encrypted, the Recording
Session MUST be able to use the same keys.
o REQ-032 If the Communication Session is encrypted, the Recording o REQ-032 If the Communication Session is encrypted, the Recording
Session MUST be able to use different keys. Session MUST be able to use different keys.
o REQ-033 The mechanism SHALL support means to relate Recording o REQ-033 The mechanism SHALL support means to relate Recording
Session(s) with Communication Session(s). Session(s) with Communication Session(s).
7. Security Considerations AUTHENTICATION
o REQ-040 The mechanism SHALL provide means for an SRS to SRC on RS
initiation.
o REQ-041 The mechanism SHALL provide means for an SRC to
authenticate SRS on RS initiation.
AUTHORIZATION
o REQ-050 The mechanism SHALL allow only authorized SRC/SRS to
initiate an RS.
INTEGRITY
o REQ-060 The mechanism SHALL ensure the integrity of the Metadata
sent from SRC to SRS.
o REQ-061 The mechanism SHALL ensure the integrity of the Media sent
from SRC to SRS.
CONFIDENTIALITY
o REQ-070 The mechanism SHALL ensure the confidentiality of the
Metadata sent from SRC to SRS.
o REQ-071 The mechanism SHALL ensure the confidentiality of the Media
sent from SRC to SRS.
o REQ-072 It SHALL be possible to establish an RS without notifying
the CS participants.
o REQ-073 The mechanism SHALL provide means to ensure the
confidentiality of the encryption keys used in CS.
6. Security Considerations
Session recording has substantial security implications, for the SIP Session recording has substantial security implications, for the SIP
UA's being recorded, the SRC, and the SRS. UA's being recorded, the SRC, and the SRS.
For the SIP UA's involved in the Communication Session, the For the SIP UA's involved in the Communication Session, the
requirements in this draft enable the UA to identify that a requirements in this draft enable the UA to identify that a
Communication Session is being recorded and for the UA to request Communication Session is being recorded and for the UA to request
that a given Communication Session is not subject to recording. that a given Communication Session is not subject to recording.
Since humans don't typically look at or know about protocol signaling Since humans don't typically look at or know about protocol signaling
skipping to change at page 14, line 31 skipping to change at page 14, line 45
With regards to security implications of the protocol(s), clearly With regards to security implications of the protocol(s), clearly
there is a need for authentication, authorization, eavesdropping there is a need for authentication, authorization, eavesdropping
protection, and non-repudiation for the solution. The SRC needs to protection, and non-repudiation for the solution. The SRC needs to
know the SRS it is communicating with is legitimate, and vice-versa, know the SRS it is communicating with is legitimate, and vice-versa,
even if they are in different domains. Both the signaling and media even if they are in different domains. Both the signaling and media
for the SIPREC needs the ability to be authenticated and protected for the SIPREC needs the ability to be authenticated and protected
from eavesdropping and non-repudiation. Requirements are detailed in from eavesdropping and non-repudiation. Requirements are detailed in
the requirements section. the requirements section.
8. IANA Considerations 7. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
9. Acknowledgements 8. Acknowledgements
Thanks to Dan Wing, Alan Johnson, Vijay Gurbani, and Cullen Jennings Thanks to Dan Wing, Alan Johnson, Vijay Gurbani, and Cullen Jennings
for their help with this document, and to all the members of the for their help with this document, and to all the members of the
DISPATCH WG mailing list for providing valuable input to this work. DISPATCH WG mailing list for providing valuable input to this work.
10. Contributors 9. Contributors
In addition to the editors, the following people provided substantial In addition to the editors, the following people provided substantial
technical and writing contributions to this document, listed technical and writing contributions to this document, listed
alphabetically: alphabetically:
Hadriel Kaplan Hadriel Kaplan
Acme Packet Acme Packet
71 Third Ave. 71 Third Ave.
Burlington, MA 01803 Burlington, MA 01803
USA USA
hkaplan@acmepacket.com hkaplan@acmepacket.com
Henry Lum Henry Lum
Genesys, Alcatel-Lucent Genesys, Alcatel-Lucent
1380 Rodick Road, Suite 200 1380 Rodick Road, Suite 200
Markham, Ontario L3R 4G5 Markham, Ontario L3R 4G5
Canada Canada
henry.lum@genesyslab.com henry.lum@genesyslab.com
skipping to change at page 15, line 29 skipping to change at page 15, line 44
Sunbury on Thames Middlesex TW16 5DJ Sunbury on Thames Middlesex TW16 5DJ
UK UK
martin.4.palmer@bt.com martin.4.palmer@bt.com
Dave Smith Dave Smith
Genesys, Alcatel-Lucent Genesys, Alcatel-Lucent
2001 Junipero Serra Blvd, Daly City, CA 94014 2001 Junipero Serra Blvd, Daly City, CA 94014
USA USA
dsmith@genesyslab.com dsmith@genesyslab.com
11. Normative References 10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804,
May 2000. May 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
 End of changes. 31 change blocks. 
98 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/