draft-ietf-siprec-req-05.txt   draft-ietf-siprec-req-06.txt 
DISPATCH K. Rehor, Ed. DISPATCH K. Rehor, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational L. Portman, Ed. Intended status: Informational L. Portman, Ed.
Expires: June 12, 2011 NICE Systems Expires: July 4, 2011 NICE Systems
A. Hutton A. Hutton
Siemens Enterprise Communications Siemens Enterprise Communications
R. Jain R. Jain
IPC Systems IPC Systems
December 9, 2010 December 31, 2010
Requirements for SIP-based Media Recording (SIPREC) Requirements for SIP-based Media Recording (SIPREC)
draft-ietf-siprec-req-05 draft-ietf-siprec-req-06
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 June 12, 2011. This Internet-Draft will expire on July 4, 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 12 skipping to change at page 3, line 12
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. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 14 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Normative References . . . . . . . . . . . . . . . . . . . . . 15
11. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
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 4, line 35 skipping to change at page 4, line 35
centers typically only record a subset of the calls, and calls must centers typically only record a subset of the calls, and calls must
not fail regardless of the availability of the recording device. not fail regardless of the availability of the recording device.
Respecting the privacy rights and wishes of users engaged in a call Respecting the privacy rights and wishes of users engaged in a call
is of paramount importance. In many jurisdictions participants have is of paramount importance. In many jurisdictions participants have
a right to know that the session is being recorded or might be a right to know that the session is being recorded or might be
recorded, and have a right to opt out, either by terminating the call recorded, and have a right to opt out, either by terminating the call
or by demanding that the call not be recorded. Therefore this or by demanding that the call not be recorded. Therefore this
document contains requirements for being able to notify users that a document contains requirements for being able to notify users that a
call is being recorded and for users to be able to request that a call is being recorded and for users to be able to request that a
call not be recorded. In addition, lawful intercept is outside the call not be recorded. Use cases where users participating in a call
scope of this document. are not informed that the call is or might be recorded are outside
the scope of this document. In particular, lawful intercept is
outside the scope of this document.
Furthermore, the scale and cost burdens vary widely, in all markets, Furthermore, the scale and cost burdens vary widely, in all markets,
where the different needs for solution capabilities such as media where the different needs for solution capabilities such as media
injection, transcoding, and security-related needs do not conform injection, transcoding, and security-related needs do not conform
well to a one-size-fits-all model. If a standardized solution well to a one-size-fits-all model. If a standardized solution
supports all of the requirements from every recording market, but supports all of the requirements from every recording market, but
doing so would be expensive for markets with lesser needs, then doing so would be expensive for markets with lesser needs, then
proprietary solutions for those markets will continue to propagate. proprietary solutions for those markets will continue to propagate.
Care must be taken, therefore, to make a standards-based solution Care must be taken, therefore, to make a standards-based solution
support optionality and flexibility. support optionality and flexibility.
skipping to change at page 5, line 24 skipping to change at page 5, line 26
DTMF (as defined by [RFC4733]), video, and text (as defined by DTMF (as defined by [RFC4733]), video, and text (as defined by
[RFC4103]). [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.
delivery are specified separately [draft-ram-siprec-metadata-00]).
This document only considers active recording, where the Session This document only considers active recording, where the Session
Recording Client purposefully streams media to a Session Recording Recording Client purposefully streams media to a Session Recording
Server. Passive recording, where a recording device detects media Server. Passive recording, where a recording device detects media
directly from the network, is outside the scope of this document. directly from the network, is outside the scope of this document.
3. Definitions 3. Definitions
Session Recording Server (SRS): A Session Recording Server (SRS) is a Session Recording Server (SRS): A Session Recording Server (SRS) is a
SIP User Agent (UA) that is a specialized media server or collector SIP User Agent (UA) that is a specialized media server or collector
skipping to change at page 6, line 43 skipping to change at page 6, line 44
| Session | | Session |
| Recording | | Recording |
| Server | | 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
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 transmission and collection of RS media temporarily discontinuing the transmission and collection of RS media
Resume: The action of recommencing the transmission and collection of Resume: The action of recommencing the transmission and collection of
RS media RS media
4. Use Cases 4. 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.
skipping to change at page 11, line 28 skipping to change at page 11, line 28
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.
5. 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-001 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-002 The mechanism MUST support the ability to record all CSs in
their entirety. their entirety.
o REQ-002 The mechanism MUST support the ability to record selected o REQ-003 The mechanism MUST support the ability to record selected
CSs in their entirety, according to policy. CSs in their entirety, according to policy.
o REQ-003 The mechanism MUST support the ability to record selected o REQ-004 The mechanism MUST support the ability to record selected
parts of selected CSs. parts of selected CSs.
o REQ-004 The mechanism MUST support the ability to record a CS o REQ-005 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-006 The mechanism MUST support the recording of IVR sessions.
o REQ-008 The mechanism MUST support the recording of RTP media types o REQ-007 The mechanism MUST support the recording of RTP media types
voice, DTMF (as defined by [RFC4733]), video, and text (as defined by voice, DTMF (as defined by [RFC4733]), video, and text (as defined by
[RFC4103]). [RFC4103]).
o REQ-012 The mechanism MUST support the ability for an SRC to o REQ-008 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.
o REQ-012bis: The mechanism MUST support the ability for an SRC to o REQ-009: The mechanism MUST support the ability for an SRC to
deliver mixed audio streams from different parties of a given deliver mixed audio streams from different parties of a given
Communication Session to an SRS. Communication Session to an SRS.
o REQ-013 The mechanism MUST support the ability to deliver multiple o REQ-010 The mechanism MUST support the ability to deliver to the
media streams for a given Communication Session over separate SRS multiple media streams for a given CS.
Recording Sessions to the SRS.
o REQ-014 The mechanism MUST support the ability to deliver multiple
media streams for a given Communication Session over a single
Recording Session to the SRS.
o REQ-015 The mechanism MUST support the ability to pause and resume o REQ-011 The mechanism MUST support the ability to pause and resume
the transmission and collection of RS media. the transmission and collection of RS media.
o REQ-017 The mechanism MUST provide the SRS with metadata describing o REQ-012 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-013 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-021 Metadata format must be agnostic of the transport protocol. o REQ-014 Metadata format must be agnostic of the transport protocol.
o REQ-022: The mechanism MUST support a means to cancel and discard o REQ-015: The mechanism MUST support a means to cancel and discard
the recording and associated metadata for a CS. the recording and associated metadata for a CS.
o REQ-022bis: The mechanism MUST support a means to cancel and o REQ-016: The mechanism MUST support a means to cancel and discard
discard the recording but not the associated metadata for a CS. the recording but not the associated metadata for a CS.
o REQ-023 The mechanism MUST support a means for an authorized o REQ-017 The mechanism MUST support a means for an authorized
participant involved in a CS to request, prior to the start of participant involved in a CS to request, prior to the start of
recording, that the CS not be recorded recording, that the CS not be recorded
o REQ-024 The mechanism MUST provide a means of indicating to the o REQ-018 The mechanism MUST provide a means of indicating to the
participants involved in a CS that their session is being recorded. participants involved in a CS that their session is being recorded.
Examples include: inject tones into the CS from the SRC, play a Examples include: inject tones into the CS from the SRC, play a
message at the beginning of a session, a visual indicator on a message at the beginning of a session, a visual indicator on a
display, etc. display, etc.
o REQ-025 The mechanism MUST provide a way for metadata to be o REQ-019 The mechanism MUST provide a way for metadata to be
conveyed to the SRS incrementally during the CS. conveyed to the SRS incrementally during the CS.
o REQ-028 The mechanism MUST NOT prevent high availability o REQ-020 The mechanism MUST NOT prevent high availability
deployments. deployments.
o REQ-033 The mechanism SHALL support means to relate Recording o REQ-021 The mechanism MUST support means to relate Recording
Session(s) with Communication Session(s). Session(s) with Communication Session(s).
o REQ-035 The mechanism MUST provide the SRS the starting clock time o REQ-022 The mechanism MUST provide the SRS the starting wall clock
for each RS media stream corresponding to the CS participant media. time for each RS media stream corresponding to the CS participant
media.
o REQ-036 The mechanism MUST provide the SRS the clock time when the
Recording Session is paused and resumed.
SECURITY
o REQ-032 The mechanism MUST support functionality such that if the
CS is encrypted, the RS may use different encryption keys.
AUTHENTICATION o REQ-023 The mechanism MUST provide the SRS the wall clock time when
the Recording Session is paused and resumed.
o REQ-040 The mechanism SHALL provide means for an SRS to o REQ-024 The mechanism MUST support functionality such that if the
authenticate the SRC on RS initiation. CS is encrypted, the RS may use the same or different encryption
keys.
o REQ-041 The mechanism SHALL provide means for an SRC to o REQ-025 The mechanism MUST provide means for an SRS to authenticate
authenticate the SRS on RS initiation. the SRC on RS initiation.
INTEGRITY o REQ-026 The mechanism MUST provide means for an SRC to authenticate
the SRS on RS initiation.
o REQ-060 The mechanism SHALL ensure that the integrity of the o REQ-027 The mechanism MUST ensure that the integrity of the
metadata sent from SRC to SRS is an accurate representation of the metadata sent from SRC to SRS is an accurate representation of the
original CS metadata. original CS metadata.
o REQ-061 The mechanism SHALL ensure that the integrity of the media o REQ-028 The mechanism MUST ensure that the integrity of the media
sent from SRC to SRS is an accurate representation of the original CS sent from SRC to SRS is an accurate representation of the original CS
media. media.
CONFIDENTIALITY o REQ-029 The mechanism MUST ensure the confidentiality of the
o REQ-070 The mechanism SHALL ensure the confidentiality of the
Metadata sent from SRC to SRS. Metadata sent from SRC to SRS.
o REQ-071 The mechanism MUST provide a means to support RS o REQ-030 The mechanism MUST provide a means to support RS
confidentiality. confidentiality.
6. Privacy Considerations 6. Privacy Considerations
Respecting the privacy rights and wishes of users engaged in a call
is of paramount importance. In many jurisdictions participants have
a right to know that the session is being recorded or might be
recorded, and have a right to opt out, either by terminating the call
or by demanding that the call not be recorded. Therefore this
document contains requirements for being able to notify users that a
call is being recorded and for users to be able to request that a
call not be recorded. Use cases where users participating in a call
are not informed that the call is or might be recorded are outside
the scope of this document. In particular, lawful intercept is
outside the scope of this document.
Requirements for participant notification of recording varies widely Requirements for participant notification of recording varies widely
by jurisdiction. In a given deployment, not all users will be by jurisdiction. In a given deployment, not all users will be
authorized to stop the recording of a CS (although any user can authorized to stop the recording of a CS (although any user can
terminate a CS). Typically users within the domain that is carrying terminate a CS). Typically users within the domain that is carrying
out the recording will be subject to policies of that domain out the recording will be subject to policies of that domain
concerning whether CSs are recorded. For example, in a call centre, concerning whether CSs are recorded. For example, in a call centre,
agents will be subject to policies of the call centre and may or may agents will be subject to policies of the call centre and may or may
not have the right to prevent the recording of a CS or part of a CS. not have the right to prevent the recording of a CS or part of a CS.
Users calling into the call centre, on the other hand, will typically Users calling into the call centre, on the other hand, will typically
have to ask the agent not to record the CS. If the agent is unable have to ask the agent not to record the CS. If the agent is unable
skipping to change at page 14, line 40 skipping to change at page 14, line 43
or in a different domain. Taking the call centre example again, or in a different domain. Taking the call centre example again,
agents might be made aware of call centre policy regarding retention agents might be made aware of call centre policy regarding retention
and use of recordings as part of their employment contract, and and use of recordings as part of their employment contract, and
callers from outside the call centre might be given some information callers from outside the call centre might be given some information
about policy when notified that a CS will be recorded (e.g., through about policy when notified that a CS will be recorded (e.g., through
an announcement that says that calls may be recorded for quality an announcement that says that calls may be recorded for quality
purposes). purposes).
This document does not specify any requirements for a user engaged in This document does not specify any requirements for a user engaged in
a CS to be able to dictate policy for what happens to a recording, or a CS to be able to dictate policy for what happens to a recording, or
for such information to be conveyed from an SRC to an SRS, since for such information to be conveyed from an SRC to an SRS. It is
typical deployments would not need this. Instead, it is assumed that assumed that the SRS has access to policy applicable to its
the SRS has access to policy applicable to its environment and can environment and can ensure that recordings are stored and used in
ensure that recordings are stored and used appropriately." accordance with that policy.
7. Security Considerations 7. 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.
skipping to change at page 15, line 22 skipping to change at page 15, line 23
a PSTN Gateway without any ability to pass on in-signaling a PSTN Gateway without any ability to pass on in-signaling
indications of recording, users can be notified of recording in the indications of recording, users can be notified of recording in the
media itself through voice announcements, a visual indicator on the media itself through voice announcements, a visual indicator on the
endpoint, or other means. endpoint, or other means.
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 Recording Session need the ability to be authenticated and
from eavesdropping and non-repudiation. Requirements are detailed in protected from eavesdropping and non-repudiation. Requirements are
the requirements section. detailed in the requirements section.
8. IANA Considerations 8. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
9. Acknowledgements 9. Acknowledgements
Thanks to Dan Wing, Alan Johnson, Vijay Gurbani, and Cullen Jennings Thanks to Dan Wing, Alan Johnson, Vijay Gurbani, Cullen Jennings,
for their help with this document, and to all the members of the Hadriel Kaplan, Henry Lum, Dave Smith, Martin Palmer, Alissa Cooper,
DISPATCH WG mailing list for providing valuable input to this work. Deepanshu Gautam, Paul Kyzivat, Parthasarathi R, and Ram Mohan R for
their significant contributions and assistance with this document and
10. Contributors Working Group, and to all the members of the DISPATCH WG and SIPREC
WG mailing lists for providing valuable input to this work.
In addition to the editors, the following people provided substantial
technical and writing contributions to this document, listed
alphabetically:
Hadriel Kaplan
Acme Packet
71 Third Ave.
Burlington, MA 01803
USA
hkaplan@acmepacket.com
Henry Lum
Genesys, Alcatel-Lucent
1380 Rodick Road, Suite 200
Markham, Ontario L3R 4G5
Canada
henry.lum@genesyslab.com
Martin Palmer
BT Global Services
Annandale House,1 Hanworth Road,
Sunbury on Thames Middlesex TW16 5DJ
UK
martin.4.palmer@bt.com
Dave Smith
Genesys, Alcatel-Lucent
2001 Junipero Serra Blvd, Daly City, CA 94014
USA
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. 44 change blocks. 
108 lines changed or deleted 76 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/