draft-ietf-siprec-protocol-12.txt   draft-ietf-siprec-protocol-13.txt 
SIPREC L. Portman SIPREC L. Portman
Internet-Draft NICE Systems Internet-Draft NICE Systems
Intended status: Standards Track H. Lum, Ed. Intended status: Standards Track H. Lum, Ed.
Expires: August 18, 2014 Genesys Expires: January 4, 2015 Genesys
C. Eckel C. Eckel
Cisco Cisco
A. Johnston A. Johnston
Avaya Avaya
A. Hutton A. Hutton
Unify Unify
February 14, 2014 July 3, 2014
Session Recording Protocol Session Recording Protocol
draft-ietf-siprec-protocol-12 draft-ietf-siprec-protocol-13
Abstract Abstract
This document specifies the use of the Session Initiation Protocol This document specifies the use of the Session Initiation Protocol
(SIP), the Session Description Protocol (SDP), and the Real Time (SIP), the Session Description Protocol (SDP), and the Real Time
Protocol (RTP) for delivering real-time media and metadata from a Protocol (RTP) for delivering real-time media and metadata from a
Communication Session (CS) to a recording device. The Session Communication Session (CS) to a recording device. The Session
Recording Protocol specifies the use of SIP, SDP, and RTP to Recording Protocol specifies the use of SIP, SDP, and RTP to
establish a Recording Session (RS) between the Session Recording establish a Recording Session (RS) between the Session Recording
Client (SRC), which is on the path of the CS, and a Session Recording Client (SRC), which is on the path of the CS, and a Session Recording
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 August 18, 2014. This Internet-Draft will expire on January 4, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 37 skipping to change at page 3, line 37
10. Persistent Recording . . . . . . . . . . . . . . . . . . . . 33 10. Persistent Recording . . . . . . . . . . . . . . . . . . . . 33
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
11.1. Registration of Option Tags . . . . . . . . . . . . . . 34 11.1. Registration of Option Tags . . . . . . . . . . . . . . 34
11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . 34 11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . 34
11.1.2. record-aware Option Tag . . . . . . . . . . . . . . 34 11.1.2. record-aware Option Tag . . . . . . . . . . . . . . 34
11.2. Registration of media feature tags . . . . . . . . . . . 34 11.2. Registration of media feature tags . . . . . . . . . . . 34
11.2.1. src feature tag . . . . . . . . . . . . . . . . . . 34 11.2.1. src feature tag . . . . . . . . . . . . . . . . . . 34
11.2.2. srs feature tag . . . . . . . . . . . . . . . . . . 35 11.2.2. srs feature tag . . . . . . . . . . . . . . . . . . 35
11.3. New Content-Disposition Parameter Registrations . . . . 35 11.3. New Content-Disposition Parameter Registrations . . . . 35
11.4. Media Type Registration . . . . . . . . . . . . . . . . 36 11.4. Media Type Registration . . . . . . . . . . . . . . . . 36
11.4.1. Registration of MIME Type application/rs-metadata . 36 11.4.1. Registration of MIME Type application/rs-metadata-
11.4.2. Registration of MIME Type application/rs-metadata-
request . . . . . . . . . . . . . . . . . . . . . . 36 request . . . . . . . . . . . . . . . . . . . . . . 36
11.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 36 11.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 36
11.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . 36 11.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . 36
11.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . 37 11.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . 36
12. Security Considerations . . . . . . . . . . . . . . . . . . . 37 12. Security Considerations . . . . . . . . . . . . . . . . . . . 37
12.1. Authentication and Authorization . . . . . . . . . . . . 38 12.1. Authentication and Authorization . . . . . . . . . . . . 37
12.2. RTP handling . . . . . . . . . . . . . . . . . . . . . . 38 12.2. RTP handling . . . . . . . . . . . . . . . . . . . . . . 38
12.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 39 12.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 39
12.4. Storage and playback . . . . . . . . . . . . . . . . . . 39 12.4. Storage and playback . . . . . . . . . . . . . . . . . . 39
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
14.1. Normative References . . . . . . . . . . . . . . . . . . 40 14.1. Normative References . . . . . . . . . . . . . . . . . . 39
14.2. Informative References . . . . . . . . . . . . . . . . . 40 14.2. Informative References . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
This document specifies the mechanism to record a Communication This document specifies the mechanism to record a Communication
Session (CS) by delivering real-time media and metadata from the CS Session (CS) by delivering real-time media and metadata from the CS
to a recording device. In accordance to the architecture to a recording device. In accordance to the architecture
[I-D.ietf-siprec-architecture], the Session Recording Protocol [I-D.ietf-siprec-architecture], the Session Recording Protocol
specifies the use of SIP, SDP, and RTP to establish a Recording specifies the use of SIP, SDP, and RTP to establish a Recording
Session (RS) between the Session Recording Client (SRC), which is on Session (RS) between the Session Recording Client (SRC), which is on
skipping to change at page 11, line 48 skipping to change at page 11, line 48
requesting recording preferences for the call. A recording-aware UA requesting recording preferences for the call. A recording-aware UA
MUST indicate that it can accept reporting of recording indication MUST indicate that it can accept reporting of recording indication
provided by the SRC with a new option tag "record-aware" when provided by the SRC with a new option tag "record-aware" when
initiating or establishing a CS, meaning including the "record-aware" initiating or establishing a CS, meaning including the "record-aware"
tag in the Supported header in the initial INVITE request or tag in the Supported header in the initial INVITE request or
response. response.
A recording-aware UA MUST be prepared to provide a recording A recording-aware UA MUST be prepared to provide a recording
indication to the end user through an appropriate user interface, indication to the end user through an appropriate user interface,
indicating whether recording is on, off, or paused for each medium. indicating whether recording is on, off, or paused for each medium.
Some user agents that are automatons (e.g. IVR, media server, PSTN Some user agents that are automatons (e.g. IVR, media server, PSTN
gateway) may not have a user interface to render recording gateway) may not have a user interface to render recording
indication. When such user agent indicates recording awareness, the indication. When such user agent indicates recording awareness, the
UA SHOULD render recording indication through other means, such as UA SHOULD render recording indication through other means, such as
passing an inband tone on the PSTN gateway, putting the recording passing an inband tone on the PSTN gateway, putting the recording
indication in a log file, or raising an application event in a indication in a log file, or raising an application event in a
VoiceXML dialog. These user agents MAY also choose not to indicate VoiceXML dialog. These user agents MAY also choose not to indicate
recording awareness, thereby relying on whatever mechanism an SRC recording awareness, thereby relying on whatever mechanism an SRC
chooses to indicate recording, such as playing a tone inband. chooses to indicate recording, such as playing a tone inband.
7. SDP Handling 7. SDP Handling
skipping to change at page 14, line 11 skipping to change at page 14, line 11
The SRC can temporarily discontinue streaming and collection of The SRC can temporarily discontinue streaming and collection of
recorded media from the SRC to the SRS for reasons such as masking recorded media from the SRC to the SRS for reasons such as masking
the recording. In this case, the SRC sends a new SDP offer and sets the recording. In this case, the SRC sends a new SDP offer and sets
the media stream to inactive (a=inactive) for each recorded stream to the media stream to inactive (a=inactive) for each recorded stream to
be paused, as per the procedures in [RFC3264]. To resume streaming be paused, as per the procedures in [RFC3264]. To resume streaming
and collection of recorded media, the SRC sends a new SDP offer and and collection of recorded media, the SRC sends a new SDP offer and
sets the media stream to sendonly (a=sendonly). Note that a CS sets the media stream to sendonly (a=sendonly). Note that a CS
itself may change the media stream direction by updating the SDP, for itself may change the media stream direction by updating the SDP, for
example, by setting a=inactive for SDP hold. Media stream direction example, by setting a=inactive for SDP hold. Media stream direction
changes in CS are conveyed in the metadata by the SRC. The SRC MUST changes in CS are conveyed in the metadata by the SRC. When a CS
NOT modify the RS media stream with a=inactive for SDP hold on the CS media stream is changed to/from inactive, the effect on the
since this operation is reserved for pausing the RS media, however, corresponding RS media stream is governed by SRC policy. The SRC MAY
an SRC can have a local policy to pause the RS media when the CS is have a local policy to pause an RS media stream when the
placed on hold. corresponding CS media stream is inactive, or it MAY leave the RS
media stream as sendonly.
7.1.2. Recording indication in CS 7.1.2. Recording indication in CS
While there are existing mechanisms for providing an indication that While there are existing mechanisms for providing an indication that
a CS is being recorded, these mechanisms are usually delivered on the a CS is being recorded, these mechanisms are usually delivered on the
CS media streams such as playing an in-band tone or an announcement CS media streams such as playing an in-band tone or an announcement
to the participants. A new 'record' SDP attribute is introduced to to the participants. A new 'record' SDP attribute is introduced to
allow the SRC to indicate recording state to a recording-aware UA in allow the SRC to indicate recording state to a recording-aware UA in
CS. CS.
skipping to change at page 14, line 44 skipping to change at page 14, line 45
attribute. attribute.
The following is the ABNF of the 'record' attribute: The following is the ABNF of the 'record' attribute:
attribute /= record-attr attribute /= record-attr
; attribute defined in RFC 4566 ; attribute defined in RFC 4566
record-attr = "record:" indication record-attr = "record:" indication
indication = "on" / "off" / "paused" indication = "on" / "off" / "paused"
on Recording is in progress. on: Recording is in progress.
off No recording is in progress. off: No recording is in progress.
paused Recording is in progress but media is paused. paused: Recording is in progress but media is paused.
7.1.3. Recording preference in CS 7.1.3. Recording preference in CS
When the SRC receives the a=recordpref SDP in an SDP offer or answer, When the SRC receives the a=recordpref SDP in an SDP offer or answer,
the SRC chooses to honor the preference to record based on local the SRC chooses to honor the preference to record based on local
policy at the SRC. If the SRC makes a change in recording state, the policy at the SRC. If the SRC makes a change in recording state, the
SRC MUST report the new recording state in the a=record attribute in SRC MUST report the new recording state in the a=record attribute in
the SDP answer or in a subsequent SDP offer. the SDP answer or in a subsequent SDP offer.
7.2. Procedures at the SRS 7.2. Procedures at the SRS
skipping to change at page 18, line 39 skipping to change at page 18, line 39
preference. preference.
The following is the ABNF of the recordpref attribute: The following is the ABNF of the recordpref attribute:
attribute /= recordpref-attr attribute /= recordpref-attr
; attribute defined in RFC 4566 ; attribute defined in RFC 4566
recordpref-attr = "a=recordpref:" pref recordpref-attr = "a=recordpref:" pref
pref = "on" / "off" / "pause" / "nopreference" pref = "on" / "off" / "pause" / "nopreference"
on Sets the preference to record if it has not already been started. on: Sets the preference to record if it has not already been
If the recording is currently paused, the preference is to resume started. If the recording is currently paused, the preference is
recording. to resume recording.
off Sets the preference for no recording. If recording has already off: Sets the preference for no recording. If recording has already
been started, then the preference is to stop the recording. been started, then the preference is to stop the recording.
pause If the recording is currently in progress, sets the preference pause: If the recording is currently in progress, sets the
to pause the recording. preference to pause the recording.
nopreference To indicate that the UA has no preference on recording. nopreference: To indicate that the UA has no preference on
recording.
8. RTP Handling 8. RTP Handling
This section provides recommendations and guidelines for RTP and RTCP This section provides recommendations and guidelines for RTP and RTCP
in the context of SIPREC. In order to communicate most effectively, in the context of SIPREC. In order to communicate most effectively,
the Session Recording Client (SRC), the Session Recording Server the Session Recording Client (SRC), the Session Recording Server
(SRS), and any Recording aware User Agents (UAs) SHOULD utilize the (SRS), and any Recording aware User Agents (UAs) SHOULD utilize the
mechanisms provided by RTP in a well-defined and predicable manner. mechanisms provided by RTP in a well-defined and predicable manner.
It is the goal of this document to make the reader aware of these It is the goal of this document to make the reader aware of these
mechanisms and provide recommendations and guidelines. mechanisms and provide recommendations and guidelines.
skipping to change at page 22, line 37 skipping to change at page 22, line 37
that is significantly longer than the typical picture duration. that is significantly longer than the typical picture duration.
8.1.7.1.1. SIP INFO for FIR 8.1.7.1.1. SIP INFO for FIR
"XML Schema for Media Control" [RFC5168] defines an Extensible Markup "XML Schema for Media Control" [RFC5168] defines an Extensible Markup
Language (XML) Schema for video fast update. Implementations are Language (XML) Schema for video fast update. Implementations are
discouraged from using the method described except for backward discouraged from using the method described except for backward
compatibility purposes. Implementations SHOULD use FIR messages compatibility purposes. Implementations SHOULD use FIR messages
instead. instead.
To make sure a common mechanism exists between the SRC and SRS, the
SRS MUST support both mechanisms (FIR and SIP INFO), using FIR when
negotiated successfully with the SRC, and using SIP INFO otherwise.
8.1.7.2. Picture Loss Indicator 8.1.7.2. Picture Loss Indicator
Picture Loss Indication (PLI), as defined in [RFC4585], informs the Picture Loss Indication (PLI), as defined in [RFC4585], informs the
encoder of the loss of an undefined amount of coded video data encoder of the loss of an undefined amount of coded video data
belonging to one or more pictures. Using the FIR command to recover belonging to one or more pictures. Using the FIR command to recover
from errors is explicitly disallowed, and instead the PLI message from errors is explicitly disallowed, and instead the PLI message
SHOULD be used. FIR SHOULD be used only in situations where not SHOULD be used. FIR SHOULD be used only in situations where not
sending a decoder refresh point would render the video unusable for sending a decoder refresh point would render the video unusable for
the users. Examples where sending FIR is appropriate include a the users. Examples where sending FIR is appropriate include a
multipoint conference when a new user joins the conference and no multipoint conference when a new user joins the conference and no
skipping to change at page 25, line 39 skipping to change at page 25, line 39
If packet loss occurs, either from the UA to the SRC or from the SRC If packet loss occurs, either from the UA to the SRC or from the SRC
to the SRS, the SRS SHOULD detect and attempt to recover from the to the SRS, the SRS SHOULD detect and attempt to recover from the
loss. The SRC does not play a role in this other than forwarding the loss. The SRC does not play a role in this other than forwarding the
associated RTP and RTCP packets. associated RTP and RTCP packets.
8.2.1.2. Transcoding Translator 8.2.1.2. Transcoding Translator
When acting as a transcoding translator, an SRC MAY perform When acting as a transcoding translator, an SRC MAY perform
transcoding (e.g., from one codec to another), and this may result in transcoding (e.g., from one codec to another), and this may result in
a different rate of packets between what the SRC receives and what a different rate of packets between what the SRC receives on the CS
the SRC sends. As when acting as a forwarding translator, RTP and what the SRC sends on the RS. As when acting as a forwarding
received as separate streams from different sources (e.g., from translator, RTP received as separate streams from different sources
different UAs with different SSRCs) cannot be mixed by the SRC and (e.g., from different UAs with different SSRCs) cannot be mixed by
MUST be sent separately to the SRS. All RTCP reports MUST be passed the SRC and MUST be sent separately to the SRS. All RTCP reports
by the SRC between the UAs and the SRS, such that the UAs and SRS are MUST be passed by the SRC between the UAs and the SRS, such that the
able to detect any SSRC collisions. UAs and SRS are able to detect any SSRC collisions.
RTCP Sender Reports generated by a UA sending a stream MUST be RTCP Sender Reports generated by a UA sending a stream MUST be
forwarded to the SRS. RTCP Receiver Reports generated by the SRS forwarded to the SRS. RTCP Receiver Reports generated by the SRS
MUST be forwarded to the relevant UA. The SRC may need to manipulate MUST be forwarded to the relevant UA. The SRC may need to manipulate
the RTCP Receiver Reports to take account of any transcoding that has the RTCP Receiver Reports to take account of any transcoding that has
taken place. taken place.
UAs may receive multiple sets of RTCP Receiver Reports, one or more UAs may receive multiple sets of RTCP Receiver Reports, one or more
from other UAs participating in the CS, and one from the SRS from other UAs participating in the CS, and one from the SRS
participating in the RS. A Recording aware UA SHOULD be prepared to participating in the RS. A Recording aware UA SHOULD be prepared to
skipping to change at page 27, line 45 skipping to change at page 27, line 45
[RFC3264]. Having received the answer, the SRC starts sending media [RFC3264]. Having received the answer, the SRC starts sending media
to the SRS as indicated in the answer. Alternatively, if the SRC to the SRS as indicated in the answer. Alternatively, if the SRC
deems the level of support indicated in the answer to be deems the level of support indicated in the answer to be
unacceptable, it may initiate another SDP offer/answer exchange in unacceptable, it may initiate another SDP offer/answer exchange in
which an alternative RTP session usage is negotiated. which an alternative RTP session usage is negotiated.
In order to preserve the mapping of media to participant within the In order to preserve the mapping of media to participant within the
CSs in the RS, the SRC SHOULD map each unique CNAME within the CSs to CSs in the RS, the SRC SHOULD map each unique CNAME within the CSs to
a unique CNAME within the RS. Additionally, the SRC SHOULD map each a unique CNAME within the RS. Additionally, the SRC SHOULD map each
unique combination of CNAME/SSRC within the CSs to a unique CNAME/ unique combination of CNAME/SSRC within the CSs to a unique CNAME/
SSRC within the RS. In doing to, the SRC may act as an RTP SSRC within the RS. In doing so, the SRC may act as an RTP
translator or as an RTP endpoint. translator or as an RTP endpoint.
The following figure illustrates a case in which each UA represents a The following figure illustrates a case in which each UA represents a
participant contributing two RTP sessions (e.g. one for audio and one participant contributing two RTP sessions (e.g. one for audio and one
for video), each with a single SSRC. The SRC acts as an RTP for video), each with a single SSRC. The SRC acts as an RTP
translator and delivers the media to the SRS using four RTP sessions, translator and delivers the media to the SRS using four RTP sessions,
each with a single SSRC. The CNAME and SSRC values used by the UAs each with a single SSRC. The CNAME and SSRC values used by the UAs
within their media streams are preserved in the media streams from within their media streams are preserved in the media streams from
the SRC to the SRS. the SRC to the SRS.
skipping to change at page 29, line 10 skipping to change at page 29, line 10
The following figure illustrates a case in which each UA represents a The following figure illustrates a case in which each UA represents a
participant contributing two RTP sessions (e.g. one for audio and one participant contributing two RTP sessions (e.g. one for audio and one
for video), each with a single SSRC. The SRC acts as an RTP mixer for video), each with a single SSRC. The SRC acts as an RTP mixer
and delivers the media to the SRS using two RTP sessions, mixing and delivers the media to the SRS using two RTP sessions, mixing
media from each participant into a single RTP session containing a media from each participant into a single RTP session containing a
single SSRC and two CSRCs. single SSRC and two CSRCs.
SSRC Sa +---------+ SSRC Sa +---------+
+-------CSRC Aa,Ba--->| | +-------CSRC Aa,Ba--->| |
| | | | | |
| SSRC Sa | SRS | | SSRC Sv | SRS |
| +---CSRC Av,Bv--->| | | +---CSRC Av,Bv--->| |
| | +---------+ | | +---------+
| | | |
+----------+ +----------+
+---------+ | SRC | +---------+ +---------+ | SRC | +---------+
| |---SSRC Aa-->|(CNAME-S, |<--SSRC Ba---| | | |---SSRC Aa-->|(CNAME-S, |<--SSRC Ba---| |
| UA-A | | CNAME-A, | | UA-B | | UA-A | | CNAME-A, | | UA-B |
|(CNAME-A)|---SSRC Aa-->| CNAME-B) |<--SSRC Bv---|(CNAME-B)| |(CNAME-A)|---SSRC Av-->| CNAME-B) |<--SSRC Bv---|(CNAME-B)|
+---------+ +----------+ +---------+ +---------+ +----------+ +---------+
Figure 10: SRC Using Mixing Figure 10: SRC Using Mixing
8.4. RTP Session Usage by SRS 8.4. RTP Session Usage by SRS
An SRS that supports recording an audio CS MUST support SRC usage of An SRS that supports recording an audio CS MUST support SRC usage of
separate audio m-lines in SDP, one per CS media direction. An SRS separate audio m-lines in SDP, one per CS media direction. An SRS
that supports recording an video CS MUST support SRC usage of that supports recording an video CS MUST support SRC usage of
separate video m-lines in SDP, one per CS media direction. separate video m-lines in SDP, one per CS media direction.
skipping to change at page 35, line 47 skipping to change at page 35, line 47
Recording Client. Recording Client.
Security Considerations: Security considerations for this media Security Considerations: Security considerations for this media
feature tag are discussed in Section 11.1 of RFC 3840. feature tag are discussed in Section 11.1 of RFC 3840.
11.3. New Content-Disposition Parameter Registrations 11.3. New Content-Disposition Parameter Registrations
This document registers a new "disposition-type" value in Content- This document registers a new "disposition-type" value in Content-
Disposition header: recording-session. Disposition header: recording-session.
recording-session the body describes the metadata information about recording-session: The body describes either:
the recording session
11.4. Media Type Registration
11.4.1. Registration of MIME Type application/rs-metadata
This document registers the application/rs-metadata MIME media type
in order to describe the recording session metadata. This media type
is defined by the following information:
Media type name: application
Media subtype name: rs-metadata * metadata about the recording session
Required parameters: none * reason for metadata snapshot request
as determined by the MIME value indicated in the Content-Type.
Options parameters: none 11.4. Media Type Registration
11.4.2. Registration of MIME Type application/rs-metadata-request 11.4.1. Registration of MIME Type application/rs-metadata-request
This document registers the application/rs-metadata-request MIME This document registers the application/rs-metadata-request MIME
media type in order to describe a recording session metadata snapshot media type in order to describe a recording session metadata snapshot
request. This media type is defined by the following information: request. This media type is defined by the following information:
Media type name: application Media type name: application
Media subtype name: rs-metadata-request Media subtype name: rs-metadata-request
Required parameters: none Required parameters: none
Options parameters: none Options parameters: none
11.5. SDP Attributes 11.5. SDP Attributes
This document registers the following new SDP attributes. This document registers the following new SDP attributes.
11.5.1. 'record' SDP Attribute 11.5.1. 'record' SDP Attribute
Contact names: Leon Portman leon.portman@nice.com, Henry Lum Contact names: Leon Portman leon.portman@gmail.com, Henry Lum
henry.lum@genesyslab.com henry.lum@genesyslab.com
Attribute name: record Attribute name: record
Long form attribute name: Recording Indication Long form attribute name: Recording Indication
Type of attribute: session or media level Type of attribute: session or media level
Subject to charset: no Subject to charset: no
This attribute provides the recording indication for the session or This attribute provides the recording indication for the session or
media stream. media stream.
Allowed attribute values: on, off, paused Allowed attribute values: on, off, paused
11.5.2. 'recordpref' SDP Attribute 11.5.2. 'recordpref' SDP Attribute
Contact names: Leon Portman leon.portman@nice.com, Henry Lum Contact names: Leon Portman leon.portman@nice.com, Henry Lum
henry.lum@genesyslab.com henry.lum@genesyslab.com
skipping to change at page 40, line 49 skipping to change at page 40, line 34
14.2. Informative References 14.2. Informative References
[I-D.ietf-avt-srtp-ekt] [I-D.ietf-avt-srtp-ekt]
Wing, D., McGrew, D., and K. Fischer, "Encrypted Key Wing, D., McGrew, D., and K. Fischer, "Encrypted Key
Transport for Secure RTP", draft-ietf-avt-srtp-ekt-03 Transport for Secure RTP", draft-ietf-avt-srtp-ekt-03
(work in progress), October 2011. (work in progress), October 2011.
[I-D.ietf-siprec-architecture] [I-D.ietf-siprec-architecture]
Hutton, A., Portman, L., Jain, R., and K. Rehor, "An Hutton, A., Portman, L., Jain, R., and K. Rehor, "An
Architecture for Media Recording using the Session Architecture for Media Recording using the Session
Initiation Protocol", draft-ietf-siprec-architecture-11 Initiation Protocol", draft-ietf-siprec-architecture-12
(work in progress), December 2013. (work in progress), February 2014.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002. UPDATE Method", RFC 3311, October 2002.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
November 2002. November 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
 End of changes. 31 change blocks. 
56 lines changed or deleted 51 lines changed or added

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