draft-ietf-siprec-protocol-13.txt   draft-ietf-siprec-protocol-14.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: January 4, 2015 Genesys Expires: February 26, 2015 Genesys
C. Eckel C. Eckel
Cisco Cisco
A. Johnston A. Johnston
Avaya Avaya
A. Hutton A. Hutton
Unify Unify
July 3, 2014 August 25, 2014
Session Recording Protocol Session Recording Protocol
draft-ietf-siprec-protocol-13 draft-ietf-siprec-protocol-14
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 January 4, 2015. This Internet-Draft will expire on February 26, 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 19 skipping to change at page 3, line 19
8.1.7.1. Full Intra Request . . . . . . . . . . . . . . . 22 8.1.7.1. Full Intra Request . . . . . . . . . . . . . . . 22
8.1.7.2. Picture Loss Indicator . . . . . . . . . . . . . 22 8.1.7.2. Picture Loss Indicator . . . . . . . . . . . . . 22
8.1.7.3. Temporary Maximum Media Stream Bit Rate Request . 23 8.1.7.3. Temporary Maximum Media Stream Bit Rate Request . 23
8.1.8. Symmetric RTP/RTCP for Sending and Receiving . . . . 23 8.1.8. Symmetric RTP/RTCP for Sending and Receiving . . . . 23
8.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.2.1. SRC acting as an RTP Translator . . . . . . . . . . . 24 8.2.1. SRC acting as an RTP Translator . . . . . . . . . . . 24
8.2.1.1. Forwarding Translator . . . . . . . . . . . . . . 25 8.2.1.1. Forwarding Translator . . . . . . . . . . . . . . 25
8.2.1.2. Transcoding Translator . . . . . . . . . . . . . 25 8.2.1.2. Transcoding Translator . . . . . . . . . . . . . 25
8.2.2. SRC acting as an RTP Mixer . . . . . . . . . . . . . 26 8.2.2. SRC acting as an RTP Mixer . . . . . . . . . . . . . 26
8.2.3. SRC acting as an RTP Endpoint . . . . . . . . . . . . 26 8.2.3. SRC acting as an RTP Endpoint . . . . . . . . . . . . 26
8.3. RTP Session Usage by SRC . . . . . . . . . . . . . . . . 27 8.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 27
8.3.1. SRC Using Multiple m-lines . . . . . . . . . . . . . 27 8.4. RTP Session Usage by SRC . . . . . . . . . . . . . . . . 27
8.3.2. SRC Using Mixing . . . . . . . . . . . . . . . . . . 28 8.4.1. SRC Using Multiple m-lines . . . . . . . . . . . . . 27
8.4. RTP Session Usage by SRS . . . . . . . . . . . . . . . . 29 8.4.2. SRC Using Mixing . . . . . . . . . . . . . . . . . . 28
8.5. RTP Session Usage by SRS . . . . . . . . . . . . . . . . 29
9. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 30 9.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 30
9.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 32 9.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 32
9.2.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . 33 9.2.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . 34
10. Persistent Recording . . . . . . . . . . . . . . . . . . . . 33 10. Persistent Recording . . . . . . . . . . . . . . . . . . . . 34
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
11.1. Registration of Option Tags . . . . . . . . . . . . . . 34 11.1. Registration of Option Tags . . . . . . . . . . . . . . 35
11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . 34 11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . 35
11.1.2. record-aware Option Tag . . . . . . . . . . . . . . 34 11.1.2. record-aware Option Tag . . . . . . . . . . . . . . 35
11.2. Registration of media feature tags . . . . . . . . . . . 34 11.2. Registration of media feature tags . . . . . . . . . . . 35
11.2.1. src feature tag . . . . . . . . . . . . . . . . . . 34 11.2.1. src feature tag . . . . . . . . . . . . . . . . . . 35
11.2.2. srs feature tag . . . . . . . . . . . . . . . . . . 35 11.2.2. srs feature tag . . . . . . . . . . . . . . . . . . 36
11.3. New Content-Disposition Parameter Registrations . . . . 35 11.3. New Content-Disposition Parameter Registrations . . . . 36
11.4. Media Type Registration . . . . . . . . . . . . . . . . 36 11.4. Media Type Registration . . . . . . . . . . . . . . . . 36
11.4.1. Registration of MIME Type application/rs-metadata- 11.4.1. Registration of MIME Type application/rs-metadata-
request . . . . . . . . . . . . . . . . . . . . . . 36 request . . . . . . . . . . . . . . . . . . . . . . 36
11.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 36 11.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 37
11.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . 36 11.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . 37
11.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . 36 11.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . 37
12. Security Considerations . . . . . . . . . . . . . . . . . . . 37 12. Security Considerations . . . . . . . . . . . . . . . . . . . 38
12.1. Authentication and Authorization . . . . . . . . . . . . 37 12.1. Authentication and Authorization . . . . . . . . . . . . 38
12.2. RTP handling . . . . . . . . . . . . . . . . . . . . . . 38 12.2. RTP handling . . . . . . . . . . . . . . . . . . . . . . 39
12.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 39 12.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 40
12.4. Storage and playback . . . . . . . . . . . . . . . . . . 39 12.4. Storage and playback . . . . . . . . . . . . . . . . . . 40
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
14.1. Normative References . . . . . . . . . . . . . . . . . . 39 14.1. Normative References . . . . . . . . . . . . . . . . . . 40
14.2. Informative References . . . . . . . . . . . . . . . . . 40 14.2. Informative References . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
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 [RFC7245],
[I-D.ietf-siprec-architecture], the Session Recording Protocol the Session Recording Protocol specifies the use of SIP, SDP, and RTP
specifies the use of SIP, SDP, and RTP to establish a Recording to establish a Recording Session (RS) between the Session Recording
Session (RS) between the Session Recording Client (SRC), which is on Client (SRC), which is on the path of the CS, and a Session Recording
the path of the CS, and a Session Recording Server (SRS) at the Server (SRS) at the recording device.
recording device.
SIP is also used to deliver metadata to the recording device, as SIP is also used to deliver metadata to the recording device, as
specified in [I-D.ietf-siprec-metadata]. Metadata is information specified in [I-D.ietf-siprec-metadata]. Metadata is information
that describes recorded media and the CS to which they relate. that describes recorded media and the CS to which they relate.
The Session Recording Protocol intends to satisfy the SIP-based Media The Session Recording Protocol intends to satisfy the SIP-based Media
Recording requirements listed in [RFC6341]. Recording requirements listed in [RFC6341].
In addition to the Session Recording Protocol, this document In addition to the Session Recording Protocol, this document
specifies extensions for user agents that are participants in a CS to specifies extensions for user agents that are participants in a CS to
skipping to change at page 4, line 37 skipping to change at page 4, line 38
2. Terminology 2. Terminology
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]. document are to be interpreted as described in [RFC2119].
3. Definitions 3. Definitions
This document refers to the core definitions provided in the This document refers to the core definitions provided in the
architecture document [I-D.ietf-siprec-architecture]. architecture document [RFC7245].
The RTP Handling section uses the definitions provided in "RTP: A The RTP Handling section uses the definitions provided in "RTP: A
Transport Protocol for Real-Time Application" [RFC3550]. Transport Protocol for Real-Time Application" [RFC3550].
4. Scope 4. Scope
The scope of the Session Recording Protocol includes the The scope of the Session Recording Protocol includes the
establishment of the recording sessions and the reporting of the establishment of the recording sessions and the reporting of the
metadata. The scope also includes extensions supported by User metadata. The scope also includes extensions supported by User
Agents participating in the CS such as indication of recording. The Agents participating in the CS such as indication of recording. The
skipping to change at page 5, line 39 skipping to change at page 5, line 39
operations. operations.
Section 6 describes the SIP communication in a recording session Section 6 describes the SIP communication in a recording session
between a SRC and a SRS, and the procedures for recording-aware user between a SRC and a SRS, and the procedures for recording-aware user
agents participating in a CS. Section 7 describes the SDP in a agents participating in a CS. Section 7 describes the SDP in a
recording session, and the procedures for recording indications and recording session, and the procedures for recording indications and
recording preferences. Section 8 describes the RTP handling in a recording preferences. Section 8 describes the RTP handling in a
recording session. Section 9 describes the mechanism to deliver recording session. Section 9 describes the mechanism to deliver
recording metadata from the SRC to the SRS. recording metadata from the SRC to the SRS.
As mentioned in the architecture document As mentioned in the architecture document [RFC7245], there are a
[I-D.ietf-siprec-architecture], there are a number of types of call number of types of call flows based on the location of the Session
flows based on the location of the Session Recording Client. The Recording Client. The following sample call flows provide a quick
following sample call flows provide a quick overview of the overview of the operations between the SRC and the SRS.
operations between the SRC and the SRS.
5.1. Delivering recorded media 5.1. Delivering recorded media
When a SIP Back-to-Back User Agent (B2BUA) with SRC functionality When a SIP Back-to-Back User Agent (B2BUA) with SRC functionality
routes a call from UA(A) to UA(B), the SRC has access to the media routes a call from UA(A) to UA(B), the SRC has access to the media
path between the user agents. When the SRC is aware that it should path between the user agents. When the SRC is aware that it should
be recording the conversation, the SRC can cause the B2BUA to bridge be recording the conversation, the SRC can cause the B2BUA to bridge
the media between UA(A) and UA(B). The SRC then establishes the the media between UA(A) and UA(B). The SRC then establishes the
Recording Session with the SRS and sends replicated media towards the Recording Session with the SRS and sends replicated media towards the
SRS. SRS.
skipping to change at page 10, line 50 skipping to change at page 10, line 50
6.1.2. SIP extensions for recording indication and preference 6.1.2. SIP extensions for recording indication and preference
For the communication session, the SRC MUST provide recording For the communication session, the SRC MUST provide recording
indication to all participants in the CS. A participant UA in a CS indication to all participants in the CS. A participant UA in a CS
can indicate that it is recording-aware by providing the "record- can indicate that it is recording-aware by providing the "record-
aware" option tag, and the SRC MUST provide recording indications in aware" option tag, and the SRC MUST provide recording indications in
the new SDP a=record attribute described in the SDP Handling section. the new SDP a=record attribute described in the SDP Handling section.
In the absence of the "record-aware" option tag, meaning that the In the absence of the "record-aware" option tag, meaning that the
participant UA is not recording-aware, an SRC MUST provide recording participant UA is not recording-aware, an SRC MUST provide recording
indications through other means such as playing a tone inband, if the indications through other means such as playing a tone in-band, if
SRC is required to do so (e.g. based on policies). the SRC is required to do so (e.g. based on policies).
An SRC in the CS may also indicate itself as a session recording An SRC in the CS may also indicate itself as a session recording
client by including the '+sip.src' feature tag. A recording-aware client by including the '+sip.src' feature tag. A recording-aware
participant can learn that a SRC is in the CS, and can set the participant can learn that a SRC is in the CS, and can set the
recording preference for the CS with the new SDP a=recordpref recording preference for the CS with the new SDP a=recordpref
attribute described in the SDP Handling section below. attribute described in the SDP Handling section below.
6.2. Procedures at the SRS 6.2. Procedures at the SRS
When an SRS receives a new INVITE, the SRS MUST only consider the SIP When an SRS receives a new INVITE, the SRS MUST only consider the SIP
skipping to change at page 11, line 52 skipping to change at page 11, line 52
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 in-band 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 in-band.
7. SDP Handling 7. SDP Handling
7.1. Procedures at the SRC 7.1. Procedures at the SRC
The SRC and SRS follows the SDP offer/answer model in [RFC3264]. The The SRC and SRS follows the SDP offer/answer model in [RFC3264]. The
procedures for SRC and SRS describe the conventions used in a procedures for SRC and SRS describe the conventions used in a
recording session. recording session.
7.1.1. SDP handling in RS 7.1.1. SDP handling in RS
skipping to change at page 19, line 10 skipping to change at page 19, line 10
preference to pause the recording. preference to pause the recording.
nopreference: To indicate that the UA has no preference on nopreference: To indicate that the UA has no preference on
recording. 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.
8.1. RTP Mechanisms 8.1. RTP Mechanisms
This section briefly describes important RTP/RTCP constructs and This section briefly describes important RTP/RTCP constructs and
mechanisms that are particularly useful within the content of SIPREC. mechanisms that are particularly useful within the content of SIPREC.
8.1.1. RTCP 8.1.1. RTCP
skipping to change at page 22, line 45 skipping to change at page 22, line 45
instead. instead.
To make sure a common mechanism exists between the SRC and SRS, the 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 SRS MUST support both mechanisms (FIR and SIP INFO), using FIR when
negotiated successfully with the SRC, and using SIP INFO otherwise. 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. [RFC4585] recommends using PLI
from errors is explicitly disallowed, and instead the PLI message instead of FIR to recover from errors. FIR is appropriate only in
SHOULD be used. FIR SHOULD be used only in situations where not situations where not sending a decoder refresh point would render the
sending a decoder refresh point would render the video unusable for video unusable for the users. Examples where sending FIR is
the users. Examples where sending FIR is appropriate include a appropriate include a multipoint conference when a new user joins the
multipoint conference when a new user joins the conference and no conference and no regular decoder refresh point interval is
regular decoder refresh point interval is established, and a video established, and a video switching MCU that changes streams.
switching MCU that changes streams.
8.1.7.3. Temporary Maximum Media Stream Bit Rate Request 8.1.7.3. Temporary Maximum Media Stream Bit Rate Request
A receiver, translator, or mixer uses the Temporary Maximum Media A receiver, translator, or mixer uses the Temporary Maximum Media
Stream Bit Rate Request (TMMBR) to request a sender to limit the Stream Bit Rate Request (TMMBR) to request a sender to limit the
maximum bit rate for a media stream to the provided value. maximum bit rate for a media stream to the provided value.
Appropriate use of TMMBR facilitates rapid adaptation to changes in Appropriate use of TMMBR facilitates rapid adaptation to changes in
available bandwidth. available bandwidth.
8.1.7.3.1. Renegotiation of SDP bandwidth attribute 8.1.7.3.1. Renegotiation of SDP bandwidth attribute
skipping to change at page 27, line 16 skipping to change at page 27, line 16
The use of SRTP between the SRC and the SRS for the RS is independent The use of SRTP between the SRC and the SRS for the RS is independent
of the use of SRTP between the UAs and SRC for the CS. Section 12 of the use of SRTP between the UAs and SRC for the CS. Section 12
provides additional information on SRTP and keying mechanisms. provides additional information on SRTP and keying mechanisms.
If packet loss occurs from the UA to the SRC, the SRC SHOULD detect If packet loss occurs from the UA to the SRC, the SRC SHOULD detect
and attempt to recover from the loss. If packet loss occurs from the and attempt to recover from the loss. If packet loss occurs from the
SRC to the SRS, the SRS SHOULD detect and attempt to recover from the SRC to the SRS, the SRS SHOULD detect and attempt to recover from the
loss. loss.
8.3. RTP Session Usage by SRC 8.3. Packet Loss
If packet loss occurs from the UA to the SRC, the SRC, if acting as
an RTP mixer or RTP endpoint, SHOULD detect and attempt to recover
from the loss. If acting as an RTP translator (either forwarding or
transcoding), the SRC does not detect or attempt to recover from the
loss. It simply forwards the associated RTP and RTCP packets. In
such cases, as well as if packet loss occurs from the SRC to the SRS,
the SRS SHOULD detect and attempt to recover from the loss.
8.4. RTP Session Usage by SRC
There are multiple ways that an SRC may choose to deliver recorded There are multiple ways that an SRC may choose to deliver recorded
media to an SRS. In some cases, it may use a single RTP session for media to an SRS. In some cases, it may use a single RTP session for
all media within the RS, whereas in others it may use multiple RTP all media within the RS, whereas in others it may use multiple RTP
sessions. The following subsections provide examples of basic RTP sessions. The following subsections provide examples of basic RTP
session usage by the SRC, including a discussion of how the RTP session usage by the SRC, including a discussion of how the RTP
constructs and mechanisms covered previously are used. An SRC may constructs and mechanisms covered previously are used. An SRC may
choose to use one or more of the RTP session usages within a single choose to use one or more of the RTP session usages within a single
RS. For the purpose of base interoperability between SRC and SRS, an RS. For the purpose of base interoperability between SRC and SRS, an
SRC MUST support separate m-lines in SDP, one per CS media direction. SRC MUST support separate m-lines in SDP, one per CS media direction.
The set of RTP session usages described is not meant to be The set of RTP session usages described is not meant to be
exhaustive. exhaustive.
8.3.1. SRC Using Multiple m-lines 8.4.1. SRC Using Multiple m-lines
When using multiple m-lines, an SRC includes each m-line in an SDP When using multiple m-lines, an SRC includes each m-line in an SDP
offer to the SRS. The SDP answer from the SRS MUST include all offer to the SRS. The SDP answer from the SRS MUST include all
m-lines, with any rejected m-lines indicated with a zero port, per m-lines, with any rejected m-lines indicated with a zero port, per
[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.
skipping to change at page 28, line 24 skipping to change at page 28, line 36
| | | | | | | |
| | | | | | | |
+---------+ +----------+ +---------+ +---------+ +----------+ +---------+
| |---SSRC Aa-->| SRC |<--SSRC Ba---| | | |---SSRC Aa-->| SRC |<--SSRC Ba---| |
| UA-A | |(CNAME-A, | | UA-B | | UA-A | |(CNAME-A, | | UA-B |
|(CNAME-A)|---SSRC Av-->| CNAME-B) |<--SSRC Bv---|(CNAME-B)| |(CNAME-A)|---SSRC Av-->| CNAME-B) |<--SSRC Bv---|(CNAME-B)|
+---------+ +----------+ +---------+ +---------+ +----------+ +---------+
Figure 9: SRC Using Multiple m-lines Figure 9: SRC Using Multiple m-lines
8.3.2. SRC Using Mixing 8.4.2. SRC Using Mixing
When using mixing, the SRC combines RTP streams from different When using mixing, the SRC combines RTP streams from different
participants and sends them towards the SRS using its own SSRC. The participants and sends them towards the SRS using its own SSRC. The
SSRCs from the contributing participants SHOULD be conveyed as CSRCs SSRCs from the contributing participants SHOULD be conveyed as CSRCs
identifiers. The SRC includes one m-line for each RTP session in an identifiers. The SRC includes one m-line for each RTP session in an
SDP offer to the SRS. The SDP answer from the SRS MUST include all SDP offer to the SRS. The SDP answer from the SRS MUST include all
m-lines, with any rejected m-lines indicated with the zero port, per m-lines, with any rejected m-lines indicated with the zero port, per
[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. to the SRS as indicated in the answer.
skipping to change at page 29, line 23 skipping to change at page 29, line 34
| | | |
+----------+ +----------+
+---------+ | 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 Av-->| 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.5. 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.
Therefore, for an SRS supporting a typical audio call, the SRS has to Therefore, for an SRS supporting a typical audio call, the SRS has to
support receiving at least two audio m-lines. For an SRS supporting support receiving at least two audio m-lines. For an SRS supporting
a typical audio and video call, the SRS has to support receiving at a typical audio and video call, the SRS has to support receiving at
least four total m-lines in the SDP, two audio m-lines and two video least four total m-lines in the SDP, two audio m-lines and two video
m-lines. m-lines.
skipping to change at page 39, line 44 skipping to change at page 40, line 38
Muthu Perumal, Dan Wing, and Magnus Westerlund for their valuable Muthu Perumal, Dan Wing, and Magnus Westerlund for their valuable
comments and inputs to this document. comments and inputs to this document.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-siprec-metadata] [I-D.ietf-siprec-metadata]
R, R., Ravindran, P., and P. Kyzivat, "Session Initiation R, R., Ravindran, P., and P. Kyzivat, "Session Initiation
Protocol (SIP) Recording Metadata", draft-ietf-siprec- Protocol (SIP) Recording Metadata", draft-ietf-siprec-
metadata-15 (work in progress), February 2014. metadata-16 (work in progress), August 2014.
[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.
[RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag
Registration Procedure", BCP 31, RFC 2506, March 1999. Registration Procedure", BCP 31, RFC 2506, March 1999.
[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,
skipping to change at page 40, line 31 skipping to change at page 41, line 26
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
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]
Hutton, A., Portman, L., Jain, R., and K. Rehor, "An
Architecture for Media Recording using the Session
Initiation Protocol", draft-ietf-siprec-architecture-12
(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.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
skipping to change at page 42, line 5 skipping to change at page 42, line 45
Control Protocol (RTCP) Flows", RFC 6263, June 2011. Control Protocol (RTCP) Flows", RFC 6263, June 2011.
[RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use [RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use
Cases and Requirements for SIP-Based Media Recording Cases and Requirements for SIP-Based Media Recording
(SIPREC)", RFC 6341, August 2011. (SIPREC)", RFC 6341, August 2011.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, September 2013. Canonical Names (CNAMEs)", RFC 7022, September 2013.
[RFC7245] Hutton, A., Portman, L., Jain, R., and K. Rehor, "An
Architecture for Media Recording Using the Session
Initiation Protocol", RFC 7245, May 2014.
Authors' Addresses Authors' Addresses
Leon Portman Leon Portman
NICE Systems NICE Systems
22 Zarhin Street 22 Zarhin Street
P.O. Box 690 P.O. Box 690
Ra'anana 4310602 Ra'anana 4310602
Israel Israel
Email: leon.portman@gmail.com Email: leon.portman@gmail.com
 End of changes. 23 change blocks. 
66 lines changed or deleted 73 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/