draft-ietf-siprec-protocol-15.txt   draft-ietf-siprec-protocol-16.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 24, 2015 Genesys Expires: November 2, 2015 Genesys
C. Eckel C. Eckel
Cisco Cisco
A. Johnston A. Johnston
Avaya Avaya
A. Hutton A. Hutton
Unify Unify
February 20, 2015 May 1, 2015
Session Recording Protocol Session Recording Protocol
draft-ietf-siprec-protocol-15 draft-ietf-siprec-protocol-16
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
Server (SRS) at the recording device. Server (SRS) at the recording device. This document considers only
active recording, where the SRC purposefully streams media to an SRS
and all participating user agents are notified of the recording.
Passive recording, where a recording device detects media directly
from the network (e.g., using port-mirroring techniques), is outside
the scope of this document. In addition, lawful intercept is outside
the scope of this document.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 November 2, 2015.
This Internet-Draft will expire on August 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 2, line 31 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Overview of operations . . . . . . . . . . . . . . . . . . . 5 5. Overview of operations . . . . . . . . . . . . . . . . . . . 5
5.1. Delivering recorded media . . . . . . . . . . . . . . . . 5 5.1. Delivering recorded media . . . . . . . . . . . . . . . . 5
5.2. Delivering recording metadata . . . . . . . . . . . . . . 7 5.2. Delivering recording metadata . . . . . . . . . . . . . . 7
5.3. Receiving recording indications and providing recording 5.3. Receiving recording indications and providing recording
preferences . . . . . . . . . . . . . . . . . . . . . . . 8 preferences . . . . . . . . . . . . . . . . . . . . . . . 8
6. SIP Handling . . . . . . . . . . . . . . . . . . . . . . . . 9 6. SIP Handling . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 10 6.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 10
6.1.1. Initiating a Recording Session . . . . . . . . . . . 10 6.1.1. Initiating a Recording Session . . . . . . . . . . . 10
6.1.2. SIP extensions for recording indication and 6.1.2. SIP extensions for recording indication and
preference . . . . . . . . . . . . . . . . . . . . . 10 preference . . . . . . . . . . . . . . . . . . . . . 10
6.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 11 6.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 11
6.3. Procedures for Recording-aware User Agents . . . . . . . 11 6.3. Procedures for Recording-aware User Agents . . . . . . . 11
7. SDP Handling . . . . . . . . . . . . . . . . . . . . . . . . 12 7. SDP Handling . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 12 7.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 12
7.1.1. SDP handling in RS . . . . . . . . . . . . . . . . . 12 7.1.1. SDP handling in RS . . . . . . . . . . . . . . . . . 12
7.1.1.1. Handling media stream updates . . . . . . . . . . 13 7.1.1.1. Handling media stream updates . . . . . . . . . . 13
skipping to change at page 3, line 13 skipping to change at page 3, line 15
8.1.3. SSRC . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1.3. SSRC . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1.4. CSRC . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1.4. CSRC . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1.5. SDES . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1.5. SDES . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1.5.1. CNAME . . . . . . . . . . . . . . . . . . . . . . 21 8.1.5.1. CNAME . . . . . . . . . . . . . . . . . . . . . . 21
8.1.6. Keepalive . . . . . . . . . . . . . . . . . . . . . . 21 8.1.6. Keepalive . . . . . . . . . . . . . . . . . . . . . . 21
8.1.7. RTCP Feedback Messages . . . . . . . . . . . . . . . 22 8.1.7. RTCP Feedback Messages . . . . . . . . . . . . . . . 22
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.2.1. SRC acting as an RTP Translator . . . . . . . . . . . 24 8.2.1. SRC acting as an RTP Translator . . . . . . . . . . . 25
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 . . . . . . . . . . . . 27
8.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 27 8.3. RTP Session Usage by SRC . . . . . . . . . . . . . . . . 27
8.4. RTP Session Usage by SRC . . . . . . . . . . . . . . . . 27 8.3.1. SRC Using Multiple m-lines . . . . . . . . . . . . . 27
8.4.1. SRC Using Multiple m-lines . . . . . . . . . . . . . 27 8.3.2. SRC Using Mixing . . . . . . . . . . . . . . . . . . 28
8.4.2. SRC Using Mixing . . . . . . . . . . . . . . . . . . 28 8.4. RTP Session Usage by SRS . . . . . . . . . . . . . . . . 29
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 . . . . . . . . . . . . . . . . . . . . 34 9.2.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . 34
10. Persistent Recording . . . . . . . . . . . . . . . . . . . . 34 10. Persistent Recording . . . . . . . . . . . . . . . . . . . . 34
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
11.1. Registration of Option Tags . . . . . . . . . . . . . . 35 11.1. Registration of Option Tags . . . . . . . . . . . . . . 35
11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . 35 11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . 35
11.1.2. record-aware Option Tag . . . . . . . . . . . . . . 35 11.1.2. record-aware Option Tag . . . . . . . . . . . . . . 35
11.2. Registration of media feature tags . . . . . . . . . . . 35 11.2. Registration of media feature tags . . . . . . . . . . . 35
skipping to change at page 4, line 15 skipping to change at page 4, line 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 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 [RFC7245], to a recording device. In accordance to the architecture [RFC7245],
the Session Recording Protocol specifies the use of SIP, SDP, and RTP the Session Recording Protocol specifies the use of SIP, SDP, and RTP
to establish a Recording Session (RS) between the Session Recording to 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
Server (SRS) at the recording device. Server (SRS) at the recording device. SIP is also used to deliver
metadata to the recording device, as specified in
SIP is also used to deliver metadata to the recording device, as [I-D.ietf-siprec-metadata]. Metadata is information that describes
specified in [I-D.ietf-siprec-metadata]. Metadata is information recorded media and the CS to which they relate. The Session
that describes recorded media and the CS to which they relate. Recording Protocol intends to satisfy the SIP-based Media Recording
requirements listed in [RFC6341]. In addition to the Session
The Session Recording Protocol intends to satisfy the SIP-based Media Recording Protocol, this document specifies extensions for user
Recording requirements listed in [RFC6341]. agents that are participants in a CS to receive recording indications
and to provide preferences for recording.
In addition to the Session Recording Protocol, this document This document considers only active recording, where the SRC
specifies extensions for user agents that are participants in a CS to purposefully streams media to an SRS and all participating user
receive recording indications and to provide preferences for agents are notified of the recording. Passive recording, where a
recording. recording device detects media directly from the network (e.g., using
port-mirroring techniques), is outside the scope of this document.
In addition, lawful intercept is outside the scope of this document,
in accordance with [RFC2804].
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
skipping to change at page 5, line 32 skipping to change at page 5, line 35
o Delivering additional recording session metadata through non-SIP o Delivering additional recording session metadata through non-SIP
mechanism mechanism
5. Overview of operations 5. Overview of operations
This section is informative and provides a description of recording This section is informative and provides a description of recording
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 an SRC and an SRS, and the procedures for recording-aware
agents participating in a CS. Section 7 describes the SDP in a user 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 [RFC7245], there are a As mentioned in the architecture document [RFC7245], there are a
number of types of call flows based on the location of the Session number of types of call flows based on the location of the Session
Recording Client. The following sample call flows provide a quick Recording Client. The following sample call flows provide a quick
overview of the operations between the SRC and the SRS. overview of the operations between the SRC and the SRS.
skipping to change at page 7, line 28 skipping to change at page 7, line 33
specify which calls to record. specify which calls to record.
5.2. Delivering recording metadata 5.2. Delivering recording metadata
The SRC is responsible for the delivery of metadata to the SRS. The The SRC is responsible for the delivery of metadata to the SRS. The
SRC may provide an initial metadata snapshot about recorded media SRC may provide an initial metadata snapshot about recorded media
streams in the initial INVITE content in the recording session. streams in the initial INVITE content in the recording session.
Subsequent metadata updates can be represented as a stream of events Subsequent metadata updates can be represented as a stream of events
in UPDATE or reINVITE requests sent by the SRC. These metadata in UPDATE or reINVITE requests sent by the SRC. These metadata
updates are normally incremental updates to the initial metadata updates are normally incremental updates to the initial metadata
snapshot to optimize on the size of updates, however, the SRC may snapshot to optimize on the size of updates. However, the SRC may
also decide to send a new metadata snapshot anytime. also decide to send a new metadata snapshot any time.
Metadata is transported in the body of INVITE or UPDATE messages. Metadata is transported in the body of INVITE or UPDATE messages.
Certain metadata, such as the attributes of the recorded media stream Certain metadata, such as the attributes of the recorded media
are located in the SDP of the recording session. stream, are located in the SDP of the recording session.
The SRS has the ability to send a request to the SRC to request for a The SRS has the ability to send a request to the SRC to request for a
new metadata snapshot update from the SRC. This can happen when the new metadata snapshot update from the SRC. This can happen when the
SRS fails to understand the current stream of incremental updates for SRS fails to understand the current stream of incremental updates for
whatever reason, for example, when SRS loses the current state due to whatever reason, for example, when SRS loses the current state due to
internal failure. The SRS may optionally attach a reason along with internal failure. The SRS may optionally attach a reason along with
the snapshot request. This request allows both SRC and SRS to the snapshot request. This request allows both SRC and SRS to
synchronize the states with a new metadata snapshot so that further synchronize the states with a new metadata snapshot so that further
metadata incremental updates will be based on the latest metadata metadata incremental updates will be based on the latest metadata
snapshot. Similar to the metadata content, the metadata snapshot snapshot. Similar to the metadata content, the metadata snapshot
skipping to change at page 8, line 49 skipping to change at page 8, line 49
5.3. Receiving recording indications and providing recording 5.3. Receiving recording indications and providing recording
preferences preferences
The SRC is responsible to provide recording indications to the The SRC is responsible to provide recording indications to the
participants in the CS. A recording-aware UA supports receiving participants in the CS. A recording-aware UA supports receiving
recording indications via the SDP attribute a=record, and it can recording indications via the SDP attribute a=record, and it can
specify a recording preference in the CS by including the SDP specify a recording preference in the CS by including the SDP
attribute a=recordpref. The recording attribute is a declaration by attribute a=recordpref. The recording attribute is a declaration by
the SRC in the CS to indicate whether recording is taking place. The the SRC in the CS to indicate whether recording is taking place. The
recording preference attribute is a declaration by the recording- recording preference attribute is a declaration by the recording-
aware UA in the CS to indicate the recording preference. aware UA in the CS to indicate its recording preference. A UA that
does not want to be recorded may still be notified recording is
occurring for a number of reasons (e.g. it was not capable of
indicating its preference, its preference was ignored, etc.) If this
occurs, the UA's only mechanism to avoid being recorded is to
terminate its participation in the session.
To illustrate how the attributes are used, if a UA (A) is initiating To illustrate how the attributes are used, if a UA (A) is initiating
a call to UA (B) and UA (A) is also an SRC that is performing the a call to UA (B) and UA (A) is also an SRC that is performing the
recording, then UA (A) provides the recording indication in the SDP recording, then UA (A) provides the recording indication in the SDP
offer with a=record:on. Since UA (A) is the SRC, UA (A) receives the offer with a=record:on. Since UA (A) is the SRC, UA (A) receives the
recording indication from the SRC directly. When UA (B) receives the recording indication from the SRC directly. When UA (B) receives the
SDP offer, UA (B) will see that recording is happening on the other SDP offer, UA (B) will see that recording is happening on the other
endpoint of this session. Since UA (B) is not an SRC and does not endpoint of this session. Since UA (B) is not an SRC and does not
provide any recording preference, the SDP answer does not contain provide any recording preference, the SDP answer does not contain
a=record nor a=recordpref. a=record nor a=recordpref.
skipping to change at page 10, line 25 skipping to change at page 10, line 28
request to the SRS. The SRC and the SRS are identified in the From request to the SRS. The SRC and the SRS are identified in the From
and To headers, respectively. and To headers, respectively.
The SRC MUST include the '+sip.src' feature tag in the Contact URI, The SRC MUST include the '+sip.src' feature tag in the Contact URI,
defined in this specification as an extension to [RFC3840], for all defined in this specification as an extension to [RFC3840], for all
recording sessions. An SRS uses the presence of the '+sip.src' recording sessions. An SRS uses the presence of the '+sip.src'
feature tag in dialog creating and modifying requests and responses feature tag in dialog creating and modifying requests and responses
to confirm that the dialog being created is for the purpose of a to confirm that the dialog being created is for the purpose of a
Recording Session. In addition, when an SRC sends a REGISTER request Recording Session. In addition, when an SRC sends a REGISTER request
to a registrar, the SRC MAY include the '+sip.src' feature tag to to a registrar, the SRC MAY include the '+sip.src' feature tag to
indicate the that it is a SRC. indicate the that it is an SRC.
Since SIP Caller Preferences extensions are optional to implement for Since SIP Caller Preferences extensions are optional to implement for
routing proxies, there is no guarantee that a recording session will routing proxies, there is no guarantee that a recording session will
be routed to an SRC or SRS. A new options tag is introduced: be routed to an SRC or SRS. A new options tag is introduced:
"siprec". As per [RFC3261], only an SRC or an SRS can accept this "siprec". As per [RFC3261], only an SRC or an SRS can accept this
option tag in a recording session. An SRC MUST include the "siprec" option tag in a recording session. An SRC MUST include the "siprec"
option tag in the Require header when initiating a Recording Session option tag in the Require header when initiating a Recording Session
so that UA's which do not support the session recording protocol so that UA's which do not support the session recording protocol
extensions will simply reject the INVITE request with a 420 Bad extensions will simply reject the INVITE request with a 420 Bad
Extension. Extension.
skipping to change at page 10, line 50 skipping to change at page 11, line 4
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 in-band, if indications through other means, such as playing a tone in-band,
the SRC is required to do so (e.g. based on policies). having a signed participant contract in place, etc.
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 an 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
session as a recording session when both the '+sip.src' feature tag session as a recording session when both the '+sip.src' feature tag
and 'siprec' option tag are included in the INVITE request. and 'siprec' option tag are included in the INVITE request.
The SRS can initiate a recording session by sending a SIP INVITE The SRS can initiate a recording session by sending a SIP INVITE
request to the SRC. The SRS and the SRC are identified in the From request to the SRC. The SRS and the SRC are identified in the From
and To headers, respectively. and To headers, respectively.
The SRS MUST include the '+sip.srs' feature tag in the Contact URI, The SRS MUST include the '+sip.srs' feature tag in the Contact URI,
as per [RFC3840], for all recording sessions. An SRC uses the as per [RFC3840], for all recording sessions. An SRC uses the
presence of this feature tag in dialog creating and modifying presence of this feature tag in dialog creating and modifying
requests and responses to confirm that the dialog being created is requests and responses to confirm that the dialog being created is
for the purpose of a Recording Session (REQ-30). In addition, when for the purpose of a Recording Session (REQ-30). In addition, when
an SRS sends a REGISTER request to a registrar, the SRS SHOULD an SRS sends a REGISTER request to a registrar, the SRS SHOULD
include the '+sip.srs' feature tag to indicate that it is a SRS. include the '+sip.srs' feature tag to indicate that it is an SRS.
An SRS MUST include the "siprec" option tag in the Require header as An SRS MUST include the "siprec" option tag in the Require header as
per [RFC3261] when initiating a Recording Session so that UA's which per [RFC3261] when initiating a Recording Session so that UA's which
do not support the session recording protocol extensions will simply do not support the session recording protocol extensions will simply
reject the INVITE request with a 420 Bad Extension. reject the INVITE request with a 420 Bad Extension.
6.3. Procedures for Recording-aware User Agents 6.3. Procedures for Recording-aware User Agents
A recording-aware user agent is a participant in the CS that supports A recording-aware user agent is a participant in the CS that supports
the SIP and SDP extensions for receiving recording indication and for the SIP and SDP extensions for receiving recording indication and for
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 provide a recording indication to the end
indication to the end user through an appropriate user interface, user through an appropriate user interface, indicating whether
indicating whether recording is on, off, or paused for each medium. recording is on, off, or paused for each medium. Appropriate user
Some user agents that are automatons (e.g. IVR, media server, PSTN interfaces may include real-time notification or previously
gateway) may not have a user interface to render recording established agreements that use of the device is subject to
indication. When such user agent indicates recording awareness, the recording. Some user agents that are automatons (e.g. IVR, media
UA SHOULD render recording indication through other means, such as server, PSTN gateway) may not have a user interface to render
passing an in-band tone on the PSTN gateway, putting the recording recording indication. When such user agent indicates recording
indication in a log file, or raising an application event in a awareness, the UA SHOULD render recording indication through other
VoiceXML dialog. These user agents MAY also choose not to indicate means, such as passing an in-band tone on the PSTN gateway, putting
recording awareness, thereby relying on whatever mechanism an SRC the recording indication in a log file, or raising an application
chooses to indicate recording, such as playing a tone in-band. event in a VoiceXML dialog. These user agents MAY also choose not to
indicate recording awareness, thereby relying on whatever mechanism
an SRC 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 14, line 39 skipping to change at page 14, line 39
at the session level, the indication applies to all media streams in at the session level, the indication applies to all media streams in
the SDP. When the attribute is applied at the media level, the the SDP. When the attribute is applied at the media level, the
indication applies to the media stream only, and that overrides the indication applies to the media stream only, and that overrides the
indication if also set at the session level. Whenever the recording indication if also set at the session level. Whenever the recording
indication needs to change, such as termination of recording, then indication needs to change, such as termination of recording, then
the SRC MUST initiate a reINVITE or UPDATE to update the SDP a=record the SRC MUST initiate a reINVITE or UPDATE to update the SDP a=record
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.
skipping to change at page 16, line 41 skipping to change at page 16, line 41
a=label:4 a=label:4
Figure 5: Sample SDP answer from SRS with audio and video streams Figure 5: Sample SDP answer from SRS with audio and video streams
Over the lifetime of a recording session, the SRS can remove recorded Over the lifetime of a recording session, the SRS can remove recorded
streams from the recording session for various reasons. To remove a streams from the recording session for various reasons. To remove a
recorded stream from the recording session, the SRS sends a new SDP recorded stream from the recording session, the SRS sends a new SDP
offer where the port of the media stream to be removed is set to offer where the port of the media stream to be removed is set to
zero, according to the procedures in [RFC3264]. zero, according to the procedures in [RFC3264].
The SRS SHOULD NOT add recorded streams in the recording session when The SRS MUST NOT add recorded streams in the recording session when
SRS sends a new SDP offer. Similarly, when the SRS starts a SRS sends a new SDP offer. Similarly, when the SRS starts a
recording session, the SRS SHOULD initiate the INVITE without an SDP recording session, the SRS MUST initiate the INVITE without an SDP
offer to let the SRC generate the SDP offer with recorded streams. offer to let the SRC generate the SDP offer with recorded streams.
The following sequence diagram shows an example where the SRS is The following sequence diagram shows an example where the SRS is
initially not ready to receive recorded streams, and later updates initially not ready to receive recorded streams, and later updates
the recording session when the SRS is ready to record. the recording session when the SRS is ready to record.
SRC SRS SRC SRS
| | | |
|(1) INVITE (SDP offer) | |(1) INVITE (SDP offer) |
|---------------------------------------------------->| |---------------------------------------------------->|
skipping to change at page 18, line 33 skipping to change at page 18, line 33
applied at the media level, the recording preference applies to the applied at the media level, the recording preference applies to the
media stream only, and that overrides the recording preference if media stream only, and that overrides the recording preference if
also set at the session level. The user agent can change the also set at the session level. The user agent can change the
recording preference by changing the a=recordpref attribute in recording preference by changing the a=recordpref attribute in
subsequent SDP offer or answer. The absence of the a=recordpref subsequent SDP offer or answer. The absence of the a=recordpref
attribute in the SDP indicates that the UA has no recording attribute in the SDP indicates that the UA has no recording
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 on: Sets the preference to record if it has not already been
started. If the recording is currently paused, the preference is started. If the recording is currently paused, the preference is
to resume 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
skipping to change at page 20, line 12 skipping to change at page 20, line 12
Synchronization of media streams is also facilitated by the NTP and Synchronization of media streams is also facilitated by the NTP and
RTP timestamps included in RTCP packets by data senders. RTP timestamps included in RTCP packets by data senders.
8.1.2. RTP Profile 8.1.2. RTP Profile
The RECOMMENDED RTP profiles for the SRC, SRS, and Recording aware The RECOMMENDED RTP profiles for the SRC, SRS, and Recording aware
UAs are "Extended Secure RTP Profile for Real-time Transport Control UAs are "Extended Secure RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/SAVPF)", [RFC5124] when using Protocol (RTCP)-Based Feedback (RTP/SAVPF)", [RFC5124] when using
encrypted RTP streams, and "Extended RTP Profile for Real-time encrypted RTP streams, and "Extended RTP Profile for Real-time
Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)",
[RFC4585] when using non encrypted media streams. However, as this [RFC4585] when using non encrypted media streams. However, as these
is not a requirement, some implementations may use "The Secure Real- are not requirements, some implementations may use "The Secure Real-
time Transport Protocol (SRTP)", [RFC3711] and "RTP Profile for Audio time Transport Protocol (SRTP)", [RFC3711] and "RTP Profile for Audio
and Video Conferences with Minimal Control", AVP [RFC3551]. and Video Conferences with Minimal Control", AVP [RFC3551].
Therefore, it is RECOMMENDED that the SRC, SRS, and Recording aware Therefore, it is RECOMMENDED that the SRC, SRS, and Recording aware
UAs not rely entirely on SAVPF or AVPF for core functionality that UAs not rely entirely on SAVPF or AVPF for core functionality that
may be at least partially achievable using SAVP and AVP. may be at least partially achievable using SAVP and AVP.
AVPF and SAVPF provide an improved RTCP timer model that allows more AVPF and SAVPF provide an improved RTCP timer model that allows more
flexible transmission of RTCP packets in response to events, rather flexible transmission of RTCP packets in response to events, rather
than strictly according to bandwidth. AVPF based codec control than strictly according to bandwidth. AVPF based codec control
messages provide efficient mechanisms for an SRC, SRS, and Recording messages provide efficient mechanisms for an SRC, SRS, and Recording
skipping to change at page 21, line 12 skipping to change at page 21, line 12
the change. The CNAME values carried in RTCP facilitate this the change. The CNAME values carried in RTCP facilitate this
identification. identification.
8.1.4. CSRC 8.1.4. CSRC
The contributing source (CSRC), as defined in [RFC3550], identifies The contributing source (CSRC), as defined in [RFC3550], identifies
the source of a stream of RTP packets that has contributed to the the source of a stream of RTP packets that has contributed to the
combined stream produced by an RTP mixer. The mixer inserts a list combined stream produced by an RTP mixer. The mixer inserts a list
of the SSRC identifiers of the sources that contributed to the of the SSRC identifiers of the sources that contributed to the
generation of a particular packet into the RTP header of that packet. generation of a particular packet into the RTP header of that packet.
This list is called the CSRC list. It is RECOMMENDED that a SRC or This list is called the CSRC list. It is RECOMMENDED that an SRC or
Recording aware UA, when acting a mixer, sets the CSRC list Recording aware UA, when acting as a mixer, sets the CSRC list
accordingly, and that the SRC and SRS interpret the CSRC list accordingly, and that the SRC and SRS interpret the CSRC list
appropriately when received. appropriately when received.
8.1.5. SDES 8.1.5. SDES
The Source Description (SDES), as defined in [RFC3550], contains an The Source Description (SDES), as defined in [RFC3550], contains an
SSRC/CSRC identifier followed by a list of zero or more items, which SSRC/CSRC identifier followed by a list of zero or more items, which
carry information about the SSRC/CSRC. End systems send one SDES carry information about the SSRC/CSRC. End systems send one SDES
packet containing their own source identifier (the same as the SSRC packet containing their own source identifier (the same as the SSRC
in the fixed RTP header). A mixer sends one SDES packet containing a in the fixed RTP header). A mixer sends one SDES packet containing a
chunk for each contributing source from which it is receiving SDES chunk for each contributing source from which it is receiving SDES
information, or multiple complete SDES packets if there are more than information, or multiple complete SDES packets if there are more than
31 such sources. 31 such sources.
The ability to identify individual contributing sources is important
in the content of SIPREC. Metadata [I-D.ietf-siprec-metadata]
provides a mechanism to achieve this at the signaling level. SDES
provides a mechanism at the RTP level.
8.1.5.1. CNAME 8.1.5.1. CNAME
The Canonical End-Point Identifier (CNAME), as defined in [RFC3550], The Canonical End-Point Identifier (CNAME), as defined in [RFC3550],
provides the binding from the SSRC identifier to an identifier for provides the binding from the SSRC identifier to an identifier for
the source (sender or receiver) that remains constant. It is the source (sender or receiver) that remains constant. It is
important the SRC and Recording aware UAs generate CNAMEs important the SRC and Recording aware UAs generate CNAMEs
appropriately and that the SRC and SRS interpret and use them for appropriately and that the SRC and SRS interpret and use them for
this purpose. Guidelines for generating CNAME values are provided in this purpose. Guidelines for generating CNAME values are provided in
"Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names
(CNAMEs)" [RFC7022]. (CNAMEs)" [RFC7022].
skipping to change at page 23, line 5 skipping to change at page 23, line 7
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. [RFC4585] recommends using PLI belonging to one or more pictures. [RFC4585] recommends using PLI
instead of FIR to recover from errors. FIR is appropriate only in instead of FIR to recover from errors. FIR is appropriate only in
situations where not sending a decoder refresh point would render the situations where not sending a decoder refresh point would render the
video unusable for the users. Examples where sending FIR is video unusable for the users. Examples where sending FIR is
appropriate include a multipoint conference when a new user joins the appropriate include a multipoint conference when a new user joins the
conference and no regular decoder refresh point interval is conference and no regular decoder refresh point interval is
established, and a video switching MCU that changes streams. established, and a video switching MCU that changes streams.
Appropriate use of PLI and FIR is important to ensure with minimum
overhead that the recorded video is usable (e.g. the necessary
reference frames exist for a player to render the recorded video).
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 25, line 20 skipping to change at page 25, line 28
separately to the SRS. All RTCP reports MUST be passed by the SRC separately to the SRS. All RTCP reports MUST be passed by the SRC
between the UAs and the SRS, such that the UAs and SRS are able to between the UAs and the SRS, such that the UAs and SRS are able to
detect any SSRC collisions. 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. MUST be forwarded to the relevant UA.
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 UA SHOULD process the RTCP Receiver
process the RTCP Receiver Reports from the SRS, whereas a recording Reports from the SRS if it is recording-aware.
unaware UA may discard such RTCP packets as not of relevance.
If SRTP is used on both the CS and the RS, decryption and/or re- If SRTP is used on both the CS and the RS, decryption and/or re-
encryption may occur. For example, if different keys are used, it encryption may occur. For example, if different keys are used, it
will occur. If the same keys are used, it need not occur. will occur. If the same keys are used, it need not occur.
Section 12 provides additional information on SRTP and keying Section 12 provides additional information on SRTP and keying
mechanisms. mechanisms.
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
skipping to change at page 26, line 25 skipping to change at page 26, line 31
mechanisms. mechanisms.
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.2. SRC acting as an RTP Mixer 8.2.2. SRC acting as an RTP Mixer
In the case of the SRC acting as a RTP mixer, as defined in In the case of the SRC acting as a RTP mixer, as defined in
[RFC3550], the SRC combines RTP streams from different UA and sends [RFC3550], the SRC combines RTP streams from different UAs and sends
them towards the SRS using its own SSRC. The SSRCs from the them towards the SRS using its own SSRC. The SSRCs from the
contributing UA SHOULD be conveyed as CSRCs identifiers within this contributing UA SHOULD be conveyed as CSRCs identifiers within this
stream. The SRC may make timing adjustments among the received stream. The SRC may make timing adjustments among the received
streams and generate its own timing on the stream sent to the SRS. streams and generate its own timing on the stream sent to the SRS.
Optionally an SRC acting as a mixer can perform transcoding, and can Optionally an SRC acting as a mixer can perform transcoding, and can
even cope with different codings received from different UAs. RTCP even cope with different codings received from different UAs. RTCP
Sender Reports and Receiver Reports are not forwarded by an SRC Sender Reports and Receiver Reports are not forwarded by an SRC
acting as mixer, but there are requirements for forwarding RTCP acting as mixer, but there are requirements for forwarding RTCP
Source Description (SDES) packets. The SRC generates its own RTCP Source Description (SDES) packets. The SRC generates its own RTCP
Sender and Receiver reports toward the associated UAs and SRS. Sender and Receiver reports toward the associated UAs and SRS.
skipping to change at page 27, line 16 skipping to change at page 27, line 24
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. Packet Loss 8.3. RTP Session Usage by SRC
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.4.1. SRC Using Multiple m-lines 8.3.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 36 skipping to change at page 28, line 31
| | | | | | | |
| | | | | | | |
+---------+ +----------+ +---------+ +---------+ +----------+ +---------+
| |---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.4.2. SRC Using Mixing 8.3.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.
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. The SRC MUST avoid SSRC collisions, rewriting SSRC within the RS. The SRC MUST avoid SSRC collisions, rewriting
SSRCs if necessary when used as CSRCs in the RS. In doing to, the SSRCs if necessary when used as CSRCs in the RS. In doing so, the
SRC acts as an RTP mixer. SRC acts as an RTP mixer.
In the event the SRS does not support this usage of CSRC values, it In the event the SRS does not support this usage of CSRC values, it
relies entirely on the SIPREC metadata to determine the participants relies entirely on the SIPREC metadata to determine the participants
included within each mixed stream. included within each mixed stream.
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
skipping to change at page 29, line 34 skipping to change at page 29, line 32
| | | |
+----------+ +----------+
+---------+ | 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.5. 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 a video CS MUST support SRC usage of separate
separate video m-lines in SDP, one per CS media direction. video m-lines in SDP, one per CS media direction. Therefore, for an
Therefore, for an SRS supporting a typical audio call, the SRS has to SRS supporting a typical audio call, the SRS has to support receiving
support receiving at least two audio m-lines. For an SRS supporting at least two audio m-lines. For an SRS supporting a typical audio
a typical audio and video call, the SRS has to support receiving at and video call, the SRS has to support receiving at least four total
least four total m-lines in the SDP, two audio m-lines and two video m-lines in the SDP, two audio m-lines and two video m-lines.
m-lines.
These requirements allow an SRS to be implemented that supports video These requirements allow an SRS to be implemented that supports video
only, without requiring support for audio recording. They also allow only, without requiring support for audio recording. They also allow
an SRS to be implemented that supports recording only one direction an SRS to be implemented that supports recording only one direction
of one stream in a CS; for example, an SRS designed to record of one stream in a CS; for example, an SRS designed to record
security monitoring cameras that only send (not receive) video security monitoring cameras that only send (not receive) video
without any audio. These requirements were not written to prevent without any audio. These requirements were not written to prevent
other modes being implemented and used, such as using a single m-line other modes being implemented and used, such as using a single m-line
and mixing the separate audio streams together. Rather, the and mixing the separate audio streams together. Rather, the
requirements were written to provide a common base mode to implement requirements were written to provide a common base mode to implement
skipping to change at page 34, line 37 skipping to change at page 34, line 37
in the absence of a communication session. The SRC continuously in the absence of a communication session. The SRC continuously
records media in a recording session to the SRS even in the absence records media in a recording session to the SRS even in the absence
of a CS for all user agents that are part of persistent recording. of a CS for all user agents that are part of persistent recording.
By allocating recorded streams and continuously sending recorded By allocating recorded streams and continuously sending recorded
media to the SRS, the SRC does not have to prepare new recorded media to the SRS, the SRC does not have to prepare new recorded
streams with new SDP offer when a new communication session is streams with new SDP offer when a new communication session is
created and also does not impact the timing of the CS. The SRC only created and also does not impact the timing of the CS. The SRC only
needs to update the metadata when new communication sessions are needs to update the metadata when new communication sessions are
created. created.
When there is no communication sessions running on the devices with When there is no communication session running on the devices with
persistent recording, there is no recorded media to stream from the persistent recording, there is no recorded media to stream from the
SRC to the SRS. In certain environments where Network Address SRC to the SRS. In certain environments where Network Address
Translator (NAT) is used, typically a minimum of flow activity is Translator (NAT) is used, typically a minimum of flow activity is
required to maintain the NAT binding for each port opened. Agents required to maintain the NAT binding for each port opened. Agents
that support Interactive Connectivity Establishment (ICE) solves this that support Interactive Connectivity Establishment (ICE) solves this
problem. For non-ICE agents, in order not to lose the NAT bindings problem. For non-ICE agents, in order not to lose the NAT bindings
for the RTP/RTCP ports opened for the recorded streams, the SRC and for the RTP/RTCP ports opened for the recorded streams, the SRC and
SRS SHOULD follow the recommendations provided in [RFC6263] to SRS SHOULD follow the recommendations provided in [RFC6263] to
maintain the NAT bindings. maintain the NAT bindings.
skipping to change at page 35, line 14 skipping to change at page 35, line 14
11.1. Registration of Option Tags 11.1. Registration of Option Tags
This specification registers two option tags. The required This specification registers two option tags. The required
information for this registration, as specified in [RFC3261], is as information for this registration, as specified in [RFC3261], is as
follows. follows.
11.1.1. siprec Option Tag 11.1.1. siprec Option Tag
Name: siprec Name: siprec
Description: This option tag is for identifying the SIP session Description: This option tag is for identifying the SIP session is
for the purpose of recording session only. This is typically not for the purpose of a recording session. This is typically not
used in a Supported header. When present in a Require header in a used in a Supported header. When present in a Require header in a
request, it indicates that the UAS MUST be either a SRC or SRS request, it indicates that the UAS is either an SRC or SRS capable
capable of handling the contexts of a recording session. of handling a recording session.
11.1.2. record-aware Option Tag 11.1.2. record-aware Option Tag
Name: record-aware Name: record-aware
Description: This option tag is to indicate the ability for the Description: This option tag is to indicate the ability for the
user agent to receive recording indicators in media level or user agent to receive recording indicators in media level or
session level SDP. When present in a Supported header, it session level SDP. When present in a Supported header, it
indicates that the UA can receive recording indicators in media indicates that the UA can receive recording indicators in media
level or session level SDP. level or session level SDP.
skipping to change at page 41, line 26 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.
[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May
2000.
[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
 End of changes. 39 change blocks. 
90 lines changed or deleted 105 lines changed or added

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