draft-ietf-siprec-protocol-04.txt   draft-ietf-siprec-protocol-05.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: November 9, 2012 Genesys Expires: December 29, 2012 Genesys
C. Eckel C. Eckel
Cisco Cisco
A. Johnston A. Johnston
Avaya Avaya
A. Hutton A. Hutton
Siemens Enterprise Siemens Enterprise
Communications Communications
May 08, 2012 June 27, 2012
Session Recording Protocol Session Recording Protocol
draft-ietf-siprec-protocol-04 draft-ietf-siprec-protocol-05
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 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 9, 2012. This Internet-Draft will expire on December 29, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 24 skipping to change at page 2, line 24
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of operations . . . . . . . . . . . . . . . . . . . . 5 4. Overview of operations . . . . . . . . . . . . . . . . . . . . 5
4.1. Delivering recorded media . . . . . . . . . . . . . . . . 5 4.1. Delivering recorded media . . . . . . . . . . . . . . . . 5
4.2. Delivering recording metadata . . . . . . . . . . . . . . 7 4.2. Delivering recording metadata . . . . . . . . . . . . . . 7
5. Initiating a Recording Session . . . . . . . . . . . . . . . . 8 4.3. Receiving recording indications and providing
5.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 8 recording preferences . . . . . . . . . . . . . . . . . . 8
5.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 9 5. Initiating a Recording Session . . . . . . . . . . . . . . . . 9
6. SDP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 10
6.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 9 5.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 10
6.1.1. Handling media stream updates . . . . . . . . . . . . 11 6. SDP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 11 6.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 11
7. RTP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1.1. Handling media stream updates . . . . . . . . . . . . 12
7.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 13
7.1.1. SRC acting as an RTP Translator . . . . . . . . . . . 13 7. RTP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1.1.1. Forwarding Translator . . . . . . . . . . . . . . 13 7.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1.1.2. Transcoding Translator . . . . . . . . . . . . . . 14 7.1.1. SRC acting as an RTP Translator . . . . . . . . . . . 16
7.1.2. SRC acting as an RTP Mixer . . . . . . . . . . . . . . 15 7.1.1.1. Forwarding Translator . . . . . . . . . . . . . . 16
7.1.3. SRC acting as an RTP Endpoint . . . . . . . . . . . . 15 7.1.1.2. Transcoding Translator . . . . . . . . . . . . . . 17
7.2. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1.2. SRC acting as an RTP Mixer . . . . . . . . . . . . . . 18
7.3. RTP Profile . . . . . . . . . . . . . . . . . . . . . . . 16 7.1.3. SRC acting as an RTP Endpoint . . . . . . . . . . . . 18
7.4. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.2. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.5. CSRC . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.3. RTP Profile . . . . . . . . . . . . . . . . . . . . . . . 19
7.6. SDES . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.4. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.6.1. CNAME . . . . . . . . . . . . . . . . . . . . . . . . 17 7.5. CSRC . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.7. Keepalive . . . . . . . . . . . . . . . . . . . . . . . . 18 7.6. SDES . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.8. RTCP Feedback Messages . . . . . . . . . . . . . . . . . . 18 7.6.1. CNAME . . . . . . . . . . . . . . . . . . . . . . . . 20
7.8.1. Full Intra Request . . . . . . . . . . . . . . . . . . 18 7.7. Keepalive . . . . . . . . . . . . . . . . . . . . . . . . 21
7.8.1.1. SIP INFO for FIR . . . . . . . . . . . . . . . . . 18 7.8. RTCP Feedback Messages . . . . . . . . . . . . . . . . . . 21
7.8.2. Picture Loss Indicator . . . . . . . . . . . . . . . . 18 7.8.1. Full Intra Request . . . . . . . . . . . . . . . . . . 21
7.8.3. Temporary Maximum Media Stream Bit Rate Request . . . 19 7.8.1.1. SIP INFO for FIR . . . . . . . . . . . . . . . . . 21
7.8.3.1. Renegotiation of SDP bandwidth attribute . . . . . 19 7.8.2. Picture Loss Indicator . . . . . . . . . . . . . . . . 21
7.8.3. Temporary Maximum Media Stream Bit Rate Request . . . 22
7.9. Symmetric RTP/RTCP for Sending and Receiving . . . . . . . 19 7.8.3.1. Renegotiation of SDP bandwidth attribute . . . . . 22
8. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.9. Symmetric RTP/RTCP for Sending and Receiving . . . . . . . 22
8.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 20 8. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 21 8.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 23
8.2.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . 23 8.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 24
9. Persistent Recording . . . . . . . . . . . . . . . . . . . . . 23 8.2.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . 26
10. Extensions for Recording-aware User Agents . . . . . . . . . . 23 9. Persistent Recording . . . . . . . . . . . . . . . . . . . . . 26
10.1. Procedures at the record-aware user agent . . . . . . . . 24 10. Extensions for Recording-aware User Agents . . . . . . . . . . 26
10.1.1. Recording preference . . . . . . . . . . . . . . . . . 24 10.1. Procedures at the record-aware user agent . . . . . . . . 27
10.2. Procedures at the SRC . . . . . . . . . . . . . . . . . . 25 10.1.1. Recording preference . . . . . . . . . . . . . . . . . 27
10.2.1. Recording indication . . . . . . . . . . . . . . . . . 25 10.2. Procedures at the SRC . . . . . . . . . . . . . . . . . . 28
10.2.2. Recording preference . . . . . . . . . . . . . . . . . 27 10.2.1. Recording indication . . . . . . . . . . . . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10.2.2. Recording preference . . . . . . . . . . . . . . . . . 29
11.1. Registration of Option Tags . . . . . . . . . . . . . . . 27 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . . 27 11.1. Registration of Option Tags . . . . . . . . . . . . . . . 29
11.1.2. record-aware Option Tag . . . . . . . . . . . . . . . 27 11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . . 29
11.2. Registration of media feature tags . . . . . . . . . . . . 27 11.1.2. record-aware Option Tag . . . . . . . . . . . . . . . 30
11.2.1. src feature tag . . . . . . . . . . . . . . . . . . . 28 11.2. Registration of media feature tags . . . . . . . . . . . . 30
11.2.2. srs feature tag . . . . . . . . . . . . . . . . . . . 28 11.2.1. src feature tag . . . . . . . . . . . . . . . . . . . 30
11.3. New Content-Disposition Parameter Registrations . . . . . 29 11.2.2. srs feature tag . . . . . . . . . . . . . . . . . . . 31
11.4. Media Type Registration . . . . . . . . . . . . . . . . . 29 11.3. New Content-Disposition Parameter Registrations . . . . . 31
11.4.1. Registration of MIME Type application/rs-metadata . . 29 11.4. Media Type Registration . . . . . . . . . . . . . . . . . 31
11.4.1. Registration of MIME Type application/rs-metadata . . 31
11.4.2. Registration of MIME Type 11.4.2. Registration of MIME Type
application/rs-metadata-request . . . . . . . . . . . 29 application/rs-metadata-request . . . . . . . . . . . 32
11.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 29 11.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 32
11.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . . 29 11.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . . 32
11.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . . 30 11.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . . 32
12. Security Considerations . . . . . . . . . . . . . . . . . . . 30 12. Security Considerations . . . . . . . . . . . . . . . . . . . 33
12.1. RTP handling . . . . . . . . . . . . . . . . . . . . . . . 30 12.1. RTP handling . . . . . . . . . . . . . . . . . . . . . . . 33
12.2. Authentication and Authorization . . . . . . . . . . . . . 31 12.2. Authentication and Authorization . . . . . . . . . . . . . 33
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
14.1. Normative References . . . . . . . . . . . . . . . . . . . 31 14.1. Normative References . . . . . . . . . . . . . . . . . . . 34
14.2. Informative References . . . . . . . . . . . . . . . . . . 32 14.2. Informative References . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
This document specifies the mechanism to record a Communication This document specifies the mechanism to record a Communication
Session (CS) by delivering real-time media and metadata from the CS Session (CS) by delivering real-time media and metadata from the CS
to a recording device. In accordance to the architecture to a recording device. In accordance to the architecture
[I-D.ietf-siprec-architecture], the Session Recording Protocol [I-D.ietf-siprec-architecture], the Session Recording Protocol
specifies the use of SIP, SDP, and RTP to establish a Recording specifies the use of SIP, SDP, and RTP to establish a Recording
Session (RS) between the Session Recording Client (SRC), which is on Session (RS) between the Session Recording Client (SRC), which is on
the path of the CS, and a Session Recording Server (SRS) at the the path of the CS, and a Session Recording 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
specifies extensions for user agents that are participants in a CS to
receive recording indications and to provide preferences for
recording.
2. Definitions 2. 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 [I-D.ietf-siprec-architecture].
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].
3. Scope 3. Scope
skipping to change at page 5, line 19 skipping to change at page 5, line 27
o Policies governing how CS users are made aware of recording o Policies governing how CS users are made aware of recording
o Delivering additional recording session metadata through non-SIP o Delivering additional recording session metadata through non-SIP
mechanism mechanism
4. Overview of operations 4. 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 5 provides the procedures for establishing a recording
session between a SRC and a SRS. Section 6 describes the SDP in a
recording session. Section 7 describes the RTP handling in a
recording session. Section 8 descirbes the mechanism to deliver
recording metadata from the SRC to the SRS.
Section 10 descirbes the procedures for user agents partcipating in a
CS to receive recording indications and to provide preferences for
recording.
As mentioned in the architecture document As mentioned in the architecture document
[I-D.ietf-siprec-architecture], there are a number of types of call [I-D.ietf-siprec-architecture], there are a number of types of call
flows based on the location of the Session Recording Client. The flows based on the location of the Session Recording Client. The
following sample call flows provide a quick overview of the following sample call flows provide a quick overview of the
operations between the SRC and the SRS. operations between the SRC and the SRS.
4.1. Delivering recorded media 4.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
skipping to change at page 6, line 5 skipping to change at page 6, line 18
endpoint can send replicated media towards the SRS. endpoint can send replicated media towards the SRS.
The following is a sample call flow that shows the SRC establishing a The following is a sample call flow that shows the SRC establishing a
recording session towards the SRS. The call flow is essentially recording session towards the SRS. The call flow is essentially
identical when the SRC is a B2BUA or as the endpoint itself. Note identical when the SRC is a B2BUA or as the endpoint itself. Note
that the SRC can choose when to establish the Recording Session that the SRC can choose when to establish the Recording Session
independent of the Communication Session, even though the following independent of the Communication Session, even though the following
call flow suggests that the SRC is establishing the Recording Session call flow suggests that the SRC is establishing the Recording Session
(message #5) after the Communication Session is established. (message #5) after the Communication Session is established.
UA A SRC UA B SRS UA A SRC UA B SRS
|(1)CS INVITE | | | |(1)CS INVITE | | |
|------------->| | | |------------->| | |
| |(2)CS INVITE | | | |(2)CS INVITE | |
| |---------------------->| | | |---------------------->| |
| | (3) 200 OK | | | | (3) 200 OK | |
| |<----------------------| | | |<----------------------| |
| (4) 200 OK | | | | (4) 200 OK | | |
|<-------------| | | |<-------------| | |
| |(5)RS INVITE with SDP | | | |(5)RS INVITE with SDP | |
| |--------------------------------------------->| | |--------------------------------------------->|
| | | (6) 200 OK with SDP | | | | (6) 200 OK with SDP |
| |<---------------------------------------------| | |<---------------------------------------------|
|(7)CS RTP | | | |(7)CS RTP | | |
|=============>|======================>| | |=============>|======================>| |
|<=============|<======================| | |<=============|<======================| |
| |(8)RS RTP | | | |(8)RS RTP | |
| |=============================================>| | |=============================================>|
| |=============================================>| | |=============================================>|
|(9)CS BYE | | | |(9)CS BYE | | |
|------------->| | | |------------->| | |
| |(10)CS BYE | | | |(10)CS BYE | |
| |---------------------->| | | |---------------------->| |
| |(11)RS BYE | | | |(11)RS BYE | |
| |--------------------------------------------->| | |--------------------------------------------->|
| | | | | | | |
Figure 1: Basic Recording Call flow Figure 1: Basic recording call flow
The above call flow can also apply to the case of a centralized The above call flow can also apply to the case of a centralized
conference with a mixer. For clarity, ACKs to INVITEs and 200 OKs to conference with a mixer. For clarity, ACKs to INVITEs and 200 OKs to
BYEs are not shown. The conference focus can provide the SRC BYEs are not shown. The conference focus can provide the SRC
functionality since the conference focus has access to all the media functionality since the conference focus has access to all the media
from each conference participant. When a recording is requested, the from each conference participant. When a recording is requested, the
SRC delivers the metadata and the media streams to the SRS. Since SRC delivers the metadata and the media streams to the SRS. Since
the conference focus has access to a mixer, the SRC may choose to mix the conference focus has access to a mixer, the SRC may choose to mix
the media streams from all participants as a single mixed media the media streams from all participants as a single mixed media
stream towards the SRS. stream towards the SRS.
An SRC can use a single recording session to record multiple An SRC can use a single recording session to record multiple
communication sessions. Every time the SRC wants to record a new communication sessions. Every time the SRC wants to record a new
call, the SRC updates the recording session with a new SDP offer to call, the SRC updates the recording session with a new SDP offer to
add new recorded streams to the recording session, and add new recorded streams to the recording session, and
correspondingly also update the metadata for the new call. correspondingly also update the metadata for the new call.
An SRS can also establish a recording session to an SRC, although it
is beyond the scope of this document to define how an SRS would
specify which calls to record.
4.2. Delivering recording metadata 4.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 anytime.
skipping to change at page 7, line 26 skipping to change at page 7, line 41
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 stream
are located in the SDP of the recording session. 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
restart 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
request is transported as content in UPDATE or INVITE sent by the SRS request is transported as content in UPDATE or INVITE sent by the SRS
in the recording session. in the recording session.
SRC SRS SRC SRS
| | | |
|(1) INVITE (metadata snapshot) | |(1) INVITE (metadata snapshot) |
|---------------------------------------------------->| |---------------------------------------------------->|
| (2)200 OK | | (2)200 OK |
|<----------------------------------------------------| |<----------------------------------------------------|
|(3) ACK | |(3) ACK |
|---------------------------------------------------->| |---------------------------------------------------->|
|(4) RTP | |(4) RTP |
|====================================================>| |====================================================>|
|====================================================>| |====================================================>|
|(5) UPDATE (metadata update 1) | |(5) UPDATE (metadata update 1) |
|---------------------------------------------------->| |---------------------------------------------------->|
| (6) 200 OK | | (6) 200 OK |
|<----------------------------------------------------| |<----------------------------------------------------|
|(7) UPDATE (metadata update 2) | |(7) UPDATE (metadata update 2) |
|---------------------------------------------------->| |---------------------------------------------------->|
| (8) 200 OK | | (8) 200 OK |
|<----------------------------------------------------| |<----------------------------------------------------|
| (9) UPDATE (metadata snapshot request) | | (9) UPDATE (metadata snapshot request) |
|<----------------------------------------------------| |<----------------------------------------------------|
| (10) 200 OK | | (10) 200 OK |
|---------------------------------------------------->| |---------------------------------------------------->|
| (11) INVITE (metadata snapshot 2 + SDP offer) | | (11) INVITE (metadata snapshot 2 + SDP offer) |
|---------------------------------------------------->| |---------------------------------------------------->|
| (12) 200 OK (SDP answer) | | (12) 200 OK (SDP answer) |
|<----------------------------------------------------| |<----------------------------------------------------|
| (13) UPDATE (metadata update 1 based on snapshot 2) | | (13) UPDATE (metadata update 1 based on snapshot 2) |
|---------------------------------------------------->| |---------------------------------------------------->|
| (14) 200 OK | | (14) 200 OK |
|<----------------------------------------------------| |<----------------------------------------------------|
Figure 3: Delivering metadata via SIP UPDATE Figure 2: Delivering metadata via SIP UPDATE
4.3. Receiving recording indications and providing recording
preferences
The SRC is responsible to provide recording indications to the
participants in the CS. User agents that are recording-aware
supports receiving recording indications with new SDP attribute
a=record and the recording-aware UA can also set recording preference
in the CS with a new SDP attribute a=recordpref. The recording
attribute is a declaration by the SRC in the CS to indicate whether
recording is taking place. The recording preference attribute is a
declaration by the recording-aware UA in the CS to indicate the
recording preference.
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
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
recording indication from the SRC directly. When UA (B) receives the
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
provide any recording preference, the SDP answer does not contain
a=record nor a=recordpref.
UA A UA B
(SRC) |
| |
| [SRC recording starts] |
|(1) INVITE (SDP offer + a=record:on) |
|---------------------------------------------------->|
| (2) 200 OK (SDP answer) |
|<----------------------------------------------------|
|(3) ACK |
|---------------------------------------------------->|
|(4) RTP |
|<===================================================>|
| |
| [UA B wants to set preference to no recording] |
| (5) INVITE (SDP offer + a=recordpref:off) |
|<----------------------------------------------------|
| [SRC honors the preference and stops recording] |
|(6) 200 OK (SDP answer + a=record:off) |
|---------------------------------------------------->|
| (7) ACK |
|<----------------------------------------------------|
Figure 3: Recording indication and recording preference
After the call is established and recording is in progress, UA (B)
later decides to change the recording preference to no recording and
sends a reINVITE with the a=recordpref attribute. It is up to the
SRC to honor the preference, and in this case SRC decides to stop the
recording and updates the recording indication in the SDP answer.
5. Initiating a Recording Session 5. Initiating a Recording Session
A recording session is a SIP session with specific extensions
applied, and these extensions are listed in the procedures below.
When an SRC or an SRS receives a SIP session that is not a recording
session, it is up to the SRC or the SRS to determine what to do with
the SIP session.
5.1. Procedures at the SRC 5.1. Procedures at the SRC
The SRC can initiate a recording session by sending a SIP INVITE The SRC can initiate a recording session by sending a SIP INVITE
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
skipping to change at page 9, line 19 skipping to change at page 10, line 32
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.
When an SRC receives a new INVITE, the SRC MUST only consider the SIP
session as a recording session when both the '+sip.srs' feature tag
and 'siprec' option tag are included in the INVITE request.
5.2. Procedures at the SRS 5.2. Procedures at the SRS
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
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 MUST include an SRS sends a REGISTER request to a registrar, the SRS MUST include
skipping to change at page 10, line 17 skipping to change at page 11, line 36
each media stream in order to identify the recorded stream with the each media stream in order to identify the recorded stream with the
rest of the metadata. The a=label attribute identifies each recorded rest of the metadata. The a=label attribute identifies each recorded
media stream, and the label name is mapped to the Media Stream media stream, and the label name is mapped to the Media Stream
Reference in the metadata as per [I-D.ietf-siprec-metadata]. The Reference in the metadata as per [I-D.ietf-siprec-metadata]. The
scope of the label name only applies to the same SIP message as the scope of the label name only applies to the same SIP message as the
SDP, meaning that the label name can be reused by another media SDP, meaning that the label name can be reused by another media
stream within the same recording session. Note that a recorded stream within the same recording session. Note that a recorded
stream is distinct from a CS stream; the metadata provides a list of stream is distinct from a CS stream; the metadata provides a list of
participants that contributes to each recorded stream. participants that contributes to each recorded stream.
The following is an example of SDP with both audio and video recorded The following is an example of SDP offer from SRC with both audio and
streams. Note that the following example contain unfolded lines video recorded streams. Note that the following example contain
longer than 72 characters. These are captured between <allOneLine> unfolded lines longer than 72 characters. These are captured between
tags. <allOneLine> tags.
v=0 v=0
o=SRS 2890844526 2890844526 IN IP4 198.51.100.1 o=SRC 2890844526 2890844526 IN IP4 198.51.100.1
s=- s=-
c=IN IP4 198.51.100.1 c=IN IP4 198.51.100.1
t=0 0 t=0 0
m=audio 12240 RTP/AVP 0 4 8 m=audio 12240 RTP/AVP 0 4 8
a=sendonly a=sendonly
a=label:1 a=label:1
m=video 22456 RTP/AVP 98 m=video 22456 RTP/AVP 98
a=rtpmap:98 H264/90000 a=rtpmap:98 H264/90000
<allOneLine> <allOneLine>
a=fmtp:98 profile-level-id=42A01E; a=fmtp:98 profile-level-id=42A01E;
sprop-parameter-sets=Z0IACpZTBYmI,aMljiA== sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
</allOneLine> </allOneLine>
a=sendonly a=sendonly
a=label:2 a=label:2
m=audio 12242 RTP/AVP 0 4 8 m=audio 12242 RTP/AVP 0 4 8
a=sendonly a=sendonly
a=label:3 a=label:3
m=audio 22458 RTP/AVP 98 m=video 22458 RTP/AVP 98
a=rtpmap:98 H264/90000 a=rtpmap:98 H264/90000
<allOneLine> <allOneLine>
a=fmtp:98 profile-level-id=42A01E; a=fmtp:98 profile-level-id=42A01E;
sprop-parameter-sets=Z0IACpZTBYmI,aMljiA== sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
</allOneLine> </allOneLine>
a=sendonly a=sendonly
a=label:4 a=label:4
Figure 4: Sample SDP with audio and video streams Figure 4: Sample SDP offer from SRC with audio and video streams
6.1.1. Handling media stream updates 6.1.1. Handling media stream updates
Over the lifetime of a recording session, the SRC can add and remove Over the lifetime of a recording session, the SRC can add and remove
recorded streams from the recording session for various reasons. For recorded streams from the recording session for various reasons. For
example, when a CS stream is added or removed from the CS, or when a example, when a CS stream is added or removed from the CS, or when a
CS is created or terminated if a recording session handles multiple CS is created or terminated if a recording session handles multiple
CSes. To remove a recorded stream from the recording session, the CSes. To remove a recorded stream from the recording session, the
SRC sends a new SDP offer where the port of the media stream to be SRC sends a new SDP offer where the port of the media stream to be
removed is set to zero, according to the procedures in [RFC3264]. To removed is set to zero, according to the procedures in [RFC3264]. To
skipping to change at page 11, line 43 skipping to change at page 13, line 26
The SRS only receives RTP streams from the SRC, the SDP answer The SRS only receives RTP streams from the SRC, the SDP answer
normally sets each media stream to receive media, by setting them normally sets each media stream to receive media, by setting them
with the a=recvonly attribute, according to the procedures of with the a=recvonly attribute, according to the procedures of
[RFC3264]. When the SRS is not ready to receive a recorded stream, [RFC3264]. When the SRS is not ready to receive a recorded stream,
the SRS sets the media stream as inactive in the SDP offer or answer the SRS sets the media stream as inactive in the SDP offer or answer
by setting it with a=inactive attribute, according to the procedures by setting it with a=inactive attribute, according to the procedures
of [RFC3264]. When the SRS is ready to receive recorded streams, the of [RFC3264]. When the SRS is ready to receive recorded streams, the
SRS sends a new SDP offer and sets the media streams with a=recvonly SRS sends a new SDP offer and sets the media streams with a=recvonly
attribute. attribute.
The following is an example of SDP answer from SRS for the SDP offer
from the above sample. Note that the following example contain
unfolded lines longer than 72 characters. These are captured between
<allOneLine> tags.
v=0
o=SRS 0 0 IN IP4 198.51.100.20
s=-
c=IN IP4 198.51.100.20
t=0 0
m=audio 10000 RTP/AVP 0 4 8
a=recvonly
a=label:1
m=video 10002 RTP/AVP 98
a=rtpmap:98 H264/90000
<allOneLine>
a=fmtp:98 profile-level-id=42A01E;
sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
</allOneLine>
a=recvonly
a=label:2
m=audio 10004 RTP/AVP 0 4 8
a=recvonly
a=label:3
m=video 10006 RTP/AVP 98
a=rtpmap:98 H264/90000
<allOneLine>
a=fmtp:98 profile-level-id=42A01E;
sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
</allOneLine>
a=recvonly
a=label:4
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
SRS sends a new SDP offer. Similarly, when the SRS starts a
recording session, the SRS SHOULD initiate the INVITE without an SDP
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) |
|---------------------------------------------------->| |---------------------------------------------------->|
| [not ready to record] | [not ready to record]
| (2)200 OK with SDP inactive | | (2)200 OK with SDP inactive |
skipping to change at page 12, line 30 skipping to change at page 15, line 30
| (6) ACK | | (6) ACK |
|<----------------------------------------------------| |<----------------------------------------------------|
|(7) RTP | |(7) RTP |
|====================================================>| |====================================================>|
| ... | | ... |
|(8) BYE | |(8) BYE |
|---------------------------------------------------->| |---------------------------------------------------->|
| (9) OK | | (9) OK |
|<----------------------------------------------------| |<----------------------------------------------------|
Figure 5: SRS responding to offer with a=inactive Figure 6: SRS responding to offer with a=inactive
7. RTP Handling 7. 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) and the Session Recording Server the Session Recording Client (SRC) and the Session Recording Server
(SRS) SHOULD utilize the mechanisms provided by RTP in a well defined (SRS) SHOULD utilize the mechanisms provided by RTP in a well defined
and predicable manner. It is the goal of this document to make the and predicable manner. It is the goal of this document to make the
reader aware of these mechanisms and provide recommendations and reader aware of these mechanisms and provide recommendations and
guidelines. guidelines.
skipping to change at page 13, line 13 skipping to change at page 16, line 13
the UAs within a CS, or as a B2BUA between UAs within a CS. the UAs within a CS, or as a B2BUA between UAs within a CS.
SRS SRS
^ ^
| |
RS RS
| |
v v
UA <-- CS --> SRC UA <-- CS --> SRC
Figure 1: UA as SRC Figure 7: UA as SRC
SRS SRS
^ ^
| |
RS RS
| |
v v
UA1 <-- CS --> SRC <-- CS --> UA2 UA1 <-- CS --> SRC <-- CS --> UA2
Figure 2: B2BUA as SRC Figure 8: B2BUA as SRC
The following subsections define a set of roles an SRC may choose to The following subsections define a set of roles an SRC may choose to
play based on its position with respect to a UA within a CS, and an play based on its position with respect to a UA within a CS, and an
SRS within an RS. SRS within an RS.
7.1.1. SRC acting as an RTP Translator 7.1.1. SRC acting as an RTP Translator
The SRC may act as a translator, as defined in [RFC3550]. A defining The SRC may act as a translator, as defined in [RFC3550]. A defining
characteristic of a translator is that it forwards RTP packets with characteristic of a translator is that it forwards RTP packets with
their SSRC identifier intact. There are two types of translators, their SSRC identifier intact. There are two types of translators,
skipping to change at page 14, line 22 skipping to change at page 17, line 22
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.
7.1.1.2. Transcoding Translator 7.1.1.2. Transcoding Translator
When acting as a transcoding translator, an SRC MAY perform When acting as a transcoding translator, an SRC MAY perform
transcoding (e.g., from one codec to another), and this may result in transcoding (e.g., from one codec to another), and this may result in
a different rate of packets between what the SRC receives and what a different rate of packets between what the SRC receives and what
the sends. As when acting as a forwarding translator, RTP received the SRC sends. As when acting as a forwarding translator, RTP
as separate streams from different sources (e.g., from different UAs received as separate streams from different sources (e.g., from
with different SSRCs) cannot be mixed by the SRC and MUST be sent different UAs with different SSRCs) cannot be mixed by the SRC and
separately to the SRS. All RTCP reports MUST passed by the SRC MUST be sent separately to the SRS. All RTCP reports MUST passed by
between the UAs and the SRS, such the UAs and SRS they are able to the SRC between the UAs and the SRS, such the UAs and SRS they are
detect any SSRC collisions. able to detect any SSRC collisions.
RTCP Sender Reports generated by a UA sending a stream MUST be RTCP Sender Reports generated by a UA sending a stream MUST be
forwarded to the SRS. RTCP Receiver Reports generated by the SRS forwarded to the SRS. RTCP Receiver Reports generated by the SRS
MUST be forwarded to the relevant UA. The SRC may need to manipulate MUST be forwarded to the relevant UA. The SRC may need to manipulate
the RTCP Receiver Reports to take account of any transcoding that has the RTCP Receiver Reports to take account of any transcoding that has
taken place. taken place.
UAs may receive multiple sets of RTCP Receiver Reports, one or more UAs may receive multiple sets of RTCP Receiver Reports, one or more
from other UAs participating in the CS, and one from the SRS from other UAs participating in the CS, and one from the SRS
participating in the RS. A SIPREC aware UA SHOULD be prepared to participating in the RS. A SIPREC aware UA SHOULD be prepared to
skipping to change at page 18, line 8 skipping to change at page 21, line 8
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 an SRC and SRS generate CNAMEs appropriately and use important the an SRC and SRS generate CNAMEs appropriately and use
them for this purpose. Guidelines for generating CNAME values are them for this purpose. Guidelines for generating CNAME values are
provided in "Guidelines for Choosing RTP Control Protocol (RTCP) provided in "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)" [RFC6222]. Canonical Names (CNAMEs)" [RFC6222].
7.7. Keepalive 7.7. Keepalive
It is anticipated that media streams in SIPREC may exist in inactive It is anticipated that media streams in SIPREC may exist in inactive
states for extended periods of times for an of a number of valid states for extended periods of times for any number of valid reasons.
reasons. In order for the bindings and any pinholes in NATs/ In order for the bindings and any pinholes in NATs/firewalls to
firewalls to remain active during such intervals, it is RECOMMENDED remain active during such intervals, it is RECOMMENDED to follow the
to follow the keep-alive procedure recommended in "Application keep-alive procedure recommended in "Application Mechanism for
Mechanism for Keeping Alive the NAT Mappings Associated to RTP/RTP Keeping Alive the NAT Mappings Associated to RTP/RTP Control Protocol
Control Protocol (RTCP) Flows" [RFC6263] for all RTP media streams. (RTCP) Flows" [RFC6263] for all RTP media streams.
7.8. RTCP Feedback Messages 7.8. RTCP Feedback Messages
"Codec Control Messages in the RTP Audio-Visual Profile with Feedback "Codec Control Messages in the RTP Audio-Visual Profile with Feedback
(AVPF)" [RFC5104] specifies extensions to the messages defined in (AVPF)" [RFC5104] specifies extensions to the messages defined in
AVPF [RFC4585]. Support for and proper usage of these messages is AVPF [RFC4585]. Support for and proper usage of these messages is
important to SRC and SRS implementations. Note that these messages important to SRC and SRS implementations. Note that these messages
are applicable only when using the AVFP or SAVPF RTP profiles. are applicable only when using the AVFP or SAVPF RTP profiles.
7.8.1. Full Intra Request 7.8.1. Full Intra Request
A Full Intra Request (FIR) Command, when received by the designate A Full Intra Request (FIR) Command, when received by the designated
media sender, requires that the media sender sends a Decoder Refresh media sender, requires that the media sender sends a Decoder Refresh
Point at the earliest opportunity. Using a decoder refresh point Point at the earliest opportunity. Using a decoder refresh point
implies refraining from using any picture sent prior to that point as implies refraining from using any picture sent prior to that point as
a reference for the encoding process of any subsequent picture sent a reference for the encoding process of any subsequent picture sent
in the stream. in the stream.
Decoder refresh points, especially Intra or IDR pictures for H.264 Decoder refresh points, especially Intra or IDR pictures for H.264
video codecs, are in general several times larger in size than video codecs, are in general several times larger in size than
predicted pictures. Thus, in scenarios in which the available bit predicted pictures. Thus, in scenarios in which the available bit
rate is small, the use of a decoder refresh point implies a delay rate is small, the use of a decoder refresh point implies a delay
skipping to change at page 19, line 4 skipping to change at page 22, line 4
compatibility purposes. Implementations SHOULD use FIR messages compatibility purposes. Implementations SHOULD use FIR messages
instead. instead.
7.8.2. Picture Loss Indicator 7.8.2. Picture Loss Indicator
Picture Loss Indication (PLI), as defined in [RFC4585], informs the Picture Loss Indication (PLI), as defined in [RFC4585], informs the
encoder of the loss of an undefined amount of coded video data encoder of the loss of an undefined amount of coded video data
belonging to one or more pictures. Using the FIR command to recover belonging to one or more pictures. Using the FIR command to recover
from errors is explicitly disallowed, and instead the PLI message from errors is explicitly disallowed, and instead the PLI message
SHOULD be used. FIR SHOULD be used only in situations where not SHOULD be used. FIR SHOULD be used only in situations where not
sending a decoder refresh point would render the video usable for the sending a decoder refresh point would render the video unusable for
users. Examples where sending FIR is appropriate include a the users. Examples where sending FIR is appropriate include a
multipoint conference when a new user joins the conference and no multipoint conference when a new user joins the conference and no
regular decoder refresh point interval is established, and a video regular decoder refresh point interval is established, and a video
switching MCU that changes streams. switching MCU that changes streams.
7.8.3. Temporary Maximum Media Stream Bit Rate Request 7.8.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.
7.8.3.1. Renegotiation of SDP bandwidth attribute 7.8.3.1. Renegotiation of SDP bandwidth attribute
If it is likely that the new value indicated by TMMBR will be valid If it is likely that the new value indicated by TMMBR will be valid
for the remainder of the session, the TMMBR sender is expected to for the remainder of the session, the TMMBR sender is expected to
perform a renegotiation of the session upper limit using the session perform a renegotiation of the session upper limit using the session
signaling protocol. Therefore for SIPREC, implementations are signaling protocol. Therefore for SIPREC, implementations are
RECOMMENDED to use TMMBR for temporary changes, and renegotiation of RECOMMENDED to use TMMBR for temporary changes, and renegotiation of
bandwidth via SDP offer/answer of more permanent changes. bandwidth via SDP offer/answer for more permanent changes.
7.9. Symmetric RTP/RTCP for Sending and Receiving 7.9. Symmetric RTP/RTCP for Sending and Receiving
Within an SDP offer/answer exchange, RTP entities choose the RTP and Within an SDP offer/answer exchange, RTP entities choose the RTP and
RTCP transport addresses (i.e., IP addresses and port numbers) on RTCP transport addresses (i.e., IP addresses and port numbers) on
which to receive packets. When sending packets, the RTP entities may which to receive packets. When sending packets, the RTP entities may
use the same source port or a different source port as those signaled use the same source port or a different source port as those signaled
for receiving packets. When the transport address used to send and for receiving packets. When the transport address used to send and
receive RTP is the same, it is termed "symmetric RTP" [RFC4961]. receive RTP is the same, it is termed "symmetric RTP" [RFC4961].
Likewise, when the transport address used to send and receive RTCP is Likewise, when the transport address used to send and receive RTCP is
skipping to change at page 20, line 6 skipping to change at page 23, line 6
normally send RTP, it will send RTCP as well as receive RTP and RTCP. normally send RTP, it will send RTCP as well as receive RTP and RTCP.
Likewise, although an SRC will not normally receive RTP from the SRS, Likewise, although an SRC will not normally receive RTP from the SRS,
it will receive RTCP as well as send RTP and RTCP. it will receive RTCP as well as send RTP and RTCP.
Note: Symmetric RTP and symmetric RTCP are different from RTP/RTCP Note: Symmetric RTP and symmetric RTCP are different from RTP/RTCP
multiplexing [RFC5761]. multiplexing [RFC5761].
8. Metadata 8. Metadata
8.1. Procedures at the SRC 8.1. Procedures at the SRC
The SRC is responsible to deliver metadata to the SRS in a recording The SRC MUST deliver metadata to the SRS in a recording session; the
session. Metadata can be provided by the SRC in the initial INVITE timing of which SRC sends the metadata depends on when the metadata
request when establishing the recording session, and subsequent becomes available. Metadata SHOULD be provided by the SRC in the
metadata updates can be provided by the SRC in reINVITE and UPDATE initial INVITE request when establishing the recording session, and
requests and responses in the recording session. subsequent metadata updates can be provided by the SRC in reINVITE
and UPDATE requests ([RFC3311]) and responses in the recording
session. There are cases that metadata is not available in the
initial INVITE request sent by the SRC, for example, when a recording
session is established in the absence of a communication session, and
the SRC would update the recording session with metadata whenever
metdata becomes available.
Certain metadata attributes are contained in the SDP, and others are Certain metadata attributes are contained in the SDP, and others are
contained in a new content type "application/rs-metadata". The contained in a new content type "application/rs-metadata". The
format of the metadata is described as part of the mechanism in format of the metadata is described as part of the mechanism in
[I-D.ietf-siprec-metadata]. A new "disposition-type" of Content- [I-D.ietf-siprec-metadata]. A new "disposition-type" of Content-
Disposition is defined for the purpose of carrying metadata and the Disposition is defined for the purpose of carrying metadata and the
value is "recording-session". The "recording-session" value value is "recording-session". The "recording-session" value
indicates that the "application/rs-metadata" content contains indicates that the "application/rs-metadata" content contains
metadata to be handled by the SRS, and the disposition can be carried metadata to be handled by the SRS, and the disposition can be carried
in either INVITE or UPDATE requests or responses sent by the SRC. in either INVITE or UPDATE requests or responses sent by the SRC.
Metadata sent by the SRC can be categorized as either a full metadata Metadata sent by the SRC can be categorized as either a full metadata
snapshot or partial update. A full metadata snapshot describes all snapshot or partial update. A full metadata snapshot describes all
the recorded streams and all metadata associated with the recording the recorded streams and all metadata associated with the recording
session. When the SRC sends a full metadata snapshot, the SRC MUST session. When the SRC sends a full metadata snapshot, the SRC MUST
send an INVITE or an UPDATE request with an SDP offer and the send an INVITE or an UPDATE request ([RFC3311]) with an SDP offer and
"recording-session" disposition. A partial update represents an the "recording-session" disposition. A partial update represents an
incremental update since the last metadata update sent by the SRC. A incremental update since the last metadata update sent by the SRC. A
partial update sent by the SRC can be an INVITE request or response partial update sent by the SRC can be an INVITE request or response
with an SDP offer, or an INVITE/UPDATE request or response containing with an SDP offer, or an INVITE/UPDATE request or response containing
a "recording-session" disposition, or an INVITE request containing a "recording-session" disposition, or an INVITE request containing
both an SDP offer and the "recording-session" disposition. both an SDP offer and the "recording-session" disposition.
The following is an example of a full metadata snapshot sent by the The following is an example of a full metadata snapshot sent by the
SRC in the initial INVITE request: SRC in the initial INVITE request:
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
skipping to change at page 21, line 37 skipping to change at page 24, line 37
m=audio 12240 RTP/AVP 0 4 8 m=audio 12240 RTP/AVP 0 4 8
a=sendonly a=sendonly
a=label:1 a=label:1
--foobar --foobar
Content-Type: application/rs-metadata Content-Type: application/rs-metadata
Content-Disposition: recording-session Content-Disposition: recording-session
[metadata content] [metadata content]
Figure 6: Sample INVITE request for the recording session Figure 9: Sample INVITE request for the recording session
8.2. Procedures at the SRS 8.2. Procedures at the SRS
The SRS receives metadata updates from the SRC in INVITE and UPDATE The SRS receives metadata updates from the SRC in INVITE and UPDATE
requests. Since the SRC can send partial updates based on the requests. Since the SRC can send partial updates based on the
previous update, the SRS needs to keep track of the sequence of previous update, the SRS needs to keep track of the sequence of
updates from the SRC. updates from the SRC.
In the case of an internal failure at the SRS, the SRS may fail to In the case of an internal failure at the SRS, the SRS may fail to
recognize a partial update from the SRC. The SRS may be able to recognize a partial update from the SRC. The SRS may be able to
recover from the internal failure by requesting for a full metadata recover from the internal failure by requesting for a full metadata
snapshot from the SRC. Certain errors, such syntax errors or snapshot from the SRC. Certain errors, such as syntax errors or
semantic errors in the metadata information, are likely caused by an semantic errors in the metadata information, are likely caused by an
error on the SRC side, and it is likely the same error will occur error on the SRC side, and it is likely the same error will occur
again even when a full metadata snapshot is requested. In order to again even when a full metadata snapshot is requested. In order to
avoid repeating the same error, the SRS can simply terminate the avoid repeating the same error, the SRS can simply terminate the
recording session when a syntax error or semantic error is detected recording session when a syntax error or semantic error is detected
in the metadata. in the metadata.
When the SRS explicitly requests for a full metadata snapshot, the When the SRS explicitly requests for a full metadata snapshot, the
SRS MUST send an UPDATE request without an SDP offer. A metadata SRS MUST send an UPDATE request without an SDP offer. A metadata
snapshot request contains a content with the content disposition type snapshot request contains a content with the content disposition type
skipping to change at page 22, line 34 skipping to change at page 25, line 35
Max-Forwards: 70 Max-Forwards: 70
Require: siprec Require: siprec
Contact: <sip:recorder@srs.example.com>;+sip.srs Contact: <sip:recorder@srs.example.com>;+sip.srs
Accept: appliation/sdp, application/rs-metadata Accept: appliation/sdp, application/rs-metadata
Content-Disposition: recording-session Content-Disposition: recording-session
Content-Type: application/rs-metadata-request Content-Type: application/rs-metadata-request
Content-Length: [length] Content-Length: [length]
SRS internal error SRS internal error
Figure 7: Metadata Request Figure 10: Metadata Request
The SRS MAY include the reason why a metadata snapshot request is The SRS MAY include the reason why a metadata snapshot request is
being made to the SRC in the reason line. This reason line is free being made to the SRC in the reason line. This reason line is free
form text, mainly designed for logging purposes on the SRC side. The form text, mainly designed for logging purposes on the SRC side. The
processing of the content by the SRC is entirely optional since the processing of the content by the SRC is entirely optional since the
content is for logging only, and the snapshot request itself is content is for logging only, and the snapshot request itself is
indicated by the use of the application/rs-metadata-request content indicated by the use of the application/rs-metadata-request content
type. type.
When the SRC receives the request for a metadata snapshot, the SRC When the SRC receives the request for a metadata snapshot, the SRC
skipping to change at page 24, line 7 skipping to change at page 27, line 7
10. Extensions for Recording-aware User Agents 10. Extensions for Recording-aware User Agents
The following sections describe the SIP and SDP extensions for The following sections describe the SIP and SDP extensions for
recording-aware user agents. A recording-aware user agent is a recording-aware user agents. A recording-aware user agent is a
participant in the CS that supports the SIP and SDP extensions for participant in the CS that supports the SIP and SDP extensions for
receiving recording indication and for requesting recording receiving recording indication and for requesting recording
preferences for the call. preferences for the call.
10.1. Procedures at the record-aware user agent 10.1. Procedures at the record-aware user agent
A recording-aware UA SHOULD indicate that it can accept reporting of A recording-aware UA MUST indicate that it can accept reporting of
recording indication provided by the SRC. A new option tag "record- recording indication provided by the SRC with a new option tag
aware" is introduced to indicate such awareness. The recording-aware "record-aware" when initiating or establishing a CS, meaning
UA SHOULD include the "record-aware" option tag in the Supported including the "record-aware" tag in the Supported header in the
header when initiating or establishing a CS. A recording-aware UA initial INVITE request or response. A recording-aware UA that has
that has indicated recording awareness MUST provide at recording indicated recording awareness MUST provide at recording indication to
indication to the end user through an appropriate user interface an the end user through an appropriate user interface an indication
indication whether recording is on or off for a given medium based on whether recording is on or off for a given medium based on the most
the most recently received a=record SDP attribute for that medium. recently received a=record SDP attribute for that medium.
Some user agents that are automatons (eg. IVR, media server, PSTN Some user agents that are automatons (eg. IVR, media server, PSTN
gateway) may not have a user interface to render recording gateway) may not have a user interface to render recording
indication. When such user agent indicates recording awareness, the indication. When such user agent indicates recording awareness, the
UA SHOULD render recording indication through other means, such as UA SHOULD render recording indication through other means, such as
passing an inband tone on the PSTN gateway, putting the recording passing an inband tone on the PSTN gateway, putting the recording
indication in a log file, or raising an application event in a indication in a log file, or raising an application event in a
VoiceXML dialog. These user agents MAY also choose not to indicate VoiceXML dialog. These user agents MAY also choose not to indicate
recording awareness, thereby relying on whatever mechanism an SRC recording awareness, thereby relying on whatever mechanism an SRC
chooses to indicate recording, such as playing a tone inband. chooses to indicate recording, such as playing a tone inband.
10.1.1. Recording preference 10.1.1. Recording preference
A recording-aware UA involved in a CS MAY request the CS to be A participant in a CS MAY set the recording preference in the CS to
recorded or not recorded. This indication of recording preference be recorded or not recorded at session establishment or during the
can be sent at session establishment time or during the session. session. The recording-aware UA sets the indication of recording
preference in a new SDP attribute a=recordpref in the CS in any SDP
offer/answer. This indication of recording preference can be sent at
session establishment time or during the session. The SRC is not
required to honor the recording preference from a participant based
on local policies at the SRC; the partcipant gets the recording
indication through the a=record SDP attribute described in the next
section.
A new SDP attribute "recordpref" is introduced. The SDP attribute The SDP a=recordpref attribute can appear at the media level or
appears at the media level or session level and can appear in an SDP session level and can appear in an SDP offer or answer. When the
offer or answer. The recording indication applies to the specified attribute is applied at the session level, the recording preference
media stream only. The following is the ABNF of the recordpref applies to all media stream in the SDP. When the attribute is
attribute: applied at the media level, the recording preference applies to the
media stream only, and that overrides the recording preference if
also set at the session level. The user agent can change the
recording preference by changing the a=recordpref attribute in
subsequent SDP offer or answer. If the a=recordpref attribute is
omitted, then the recording preference would be assumed to be the
recording preference set in a previous SDP offer or answer.
The following is the ABNF of the recordpref attribute:
attribute /= recordpref-attr
; 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 Request for recording if it has not already been started. If the on Sets the preference to record if it has not already been started.
recording is currently paused, request to resume recording. If the recording is currently paused, the preference is to resume
off Request for no recording. If recording has already been
started, then this preference indicates a request to stop
recording. recording.
pause Request to pause recording if recording is currently in off Sets the preference for no recording. If recording has already
progress. been started, then the preference is to stop the recording.
pause If the recording is currently in progress, sets the preference
to pause the recording.
nopreference To indicate that the UA has no preference on recording. nopreference To indicate that the UA has no preference on recording.
While the absence of this attribute indirectly implies the lack of
preference, using this value allows the UA to explicitly state no
preference to being recorded.
10.2. Procedures at the SRC 10.2. Procedures at the SRC
When a UA has indicated that it is recording-aware through the The SRC MUST provide recording indication to all participants in the
CS. When a UA has indicated that it is recording-aware through the
"record-aware" option tag, the SRC MUST provide recording indications "record-aware" option tag, the SRC MUST provide recording indications
in a new SDP attribute described in the following section. In the in the new SDP a=record attribute described in the following section.
absence of the "record-aware" option tag, meaning that the UA is not In the absence of the "record-aware" option tag, meaning that the UA
recording-aware, an SRC MUST provide recording indications, where SRC is not recording-aware, an SRC MUST provide recording indications
is required to do so based on policies, through other means such as through other means such as playing a tone inband, if the SRC is
playing a tone inband. required to do so (eg. based on policies).
10.2.1. Recording indication 10.2.1. Recording indication
While there are existing mechanisms for providing an indication that While there are existing mechanisms for providing an indication that
a CS is being recorded, these mechanisms are usually delivered on the a CS is being recorded, these mechanisms are usually delivered on the
CS media streams such as playing an in-band tone or an announcement CS media streams such as playing an in-band tone or an announcement
to the participants. A new SDP attribute is introduced to allow a to the participants. A new SDP attribute is introduced to allow a
recording-aware UA to render recording indication at the user recording-aware UA to render recording indication at the user
interface. interface.
The 'record' SDP attribute appears at the media level or session The 'record' SDP attribute appears at the media level or session
level in either SDP offer or answer. The recording indication level in either SDP offer or answer. When the attribute is applied
applies to the specified media stream only, for example, only the at the session level, the indication applies to all media streams in
audio portion of the call is recorded in an audio/video call. The the SDP. When the attribute is applied at the media level, the
following is the ABNF of the 'record' attribute: indication applies to the media stream only, and that overrides the
indication if also set at the session level. Whenever the recording
indication needs to change, such as termination of recording, then
the SRC MUST initiate a reINVITE or UPDATE to update the SDP a=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 by media is paused. paused Recording is in progress by media is paused.
The recording attribute is a declaration by the SRC in the CS to
indicate whether recording is taking place. For example, if a UA (A)
is initiating 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 offer with a=record:on. When UA (B) receives
the SDP offer, UA (B) will see that recording is happening on the
other endpoint of this session. If UA (B) does not wish to perform
recording itself, UA (B) provides the recording indication as
a=record:off in the SDP answer.
Whenever the recording indication needs to change, such as
termination of recording, then the UA MUST initiate a reINVITE or
UPDATE to update the SDP attribute to a=record:off. The following
call flow shows an example of the offer/answer with the recording
indication attribute.
UA A UA B
(SRC) |
| |
| [SRC recording starts] |
|(1) INVITE (SDP offer + a=record:on) |
|---------------------------------------------------->|
| 200 OK (SDP answer) |
|<----------------------------------------------------|
|(3) ACK |
|---------------------------------------------------->|
|(4) RTP |
|<===================================================>|
| [SRC stops recording] |
|(5) re-INVITE (SDP + a=record:off) |
|---------------------------------------------------->|
| (6) 200 OK (SDP + a=record:off)|
|<----------------------------------------------------|
| (6) ACK |
|---------------------------------------------------->|
Figure 8: Recording indication example
If a call is traversed through one or more SIP B2BUA, and it happens If a call is traversed through one or more SIP B2BUA, and it happens
that there are more than one SRC in the call path, the recording that there are more than one SRC in the call path, the recording
indication attribute does not provide any hint as to which SRC is indication attribute does not provide any hint as to which SRC is
performing the recording, meaning the endpoint only knows that the performing the recording, meaning the endpoint only knows that the
call is being recorded. This attribute is also not used as an call is being recorded. This attribute is also not used as an
indication to negotiate which SRC in the call path will perform indication to negotiate which SRC in the call path will perform
recording and is not used as a request to start/stop recording if recording and is not used as a request to start/stop recording if
there are multiple SRCs in the call path. there are multiple SRCs in the call path.
10.2.2. Recording preference 10.2.2. Recording preference
When the SRC receives the a=recordpref SDP in an SDP offer or answer, When the SRC receives the a=recordpref SDP in an SDP offer or answer,
the SRC chooses to honor such request to record the request based on the SRC chooses to honor the preference to record based on local
local policy on the SRC. When the SRC honors the request, the SRC policy at the SRC. When the SRC honors the preference, the SRC MUST
MUST also update the recording indication to reflect the current also update the a=record attribute to indicate the current state of
state of the recording (on/off/paused). the recording (on/off/paused).
11. IANA Considerations 11. IANA Considerations
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
skipping to change at page 30, line 27 skipping to change at page 33, line 4
Contact names: Leon Portman leon.portman@nice.com, Henry Lum Contact names: Leon Portman leon.portman@nice.com, Henry Lum
henry.lum@genesyslab.com henry.lum@genesyslab.com
Attribute name: recordpref Attribute name: recordpref
Long form attribute name: Recording Preference Long form attribute name: Recording Preference
Type of attribute: session or media level Type of attribute: session or media level
Subject to charset: no Subject to charset: no
This attribute provides the recording preference for the session or
This attribute provides the recording indication for the session or
media stream. media stream.
Allowed attribute values: on, off, pause, nopreference Allowed attribute values: on, off, pause, nopreference
12. Security Considerations 12. Security Considerations
The recording session is fundamentally a standard SIP dialog The recording session is fundamentally a standard SIP dialog
[RFC3261], therefore, the recording session can reuse any of the [RFC3261], therefore, the recording session can reuse any of the
existing SIP security mechanism available for securing the recorded existing SIP security mechanism available for securing the recorded
media as well as metadata. Other security considerations are media as well as metadata. Other security considerations are
skipping to change at page 31, line 19 skipping to change at page 33, line 42
and 407 SIP responses as well as other SIP header fields for carrying and 407 SIP responses as well as other SIP header fields for carrying
challenges and credentials. challenges and credentials.
The SRS may have its own set of recording policies to authorize The SRS may have its own set of recording policies to authorize
recording requests from the SRC. The use of recording policies is recording requests from the SRC. The use of recording policies is
outside the scope of the Session Recording Protocol. outside the scope of the Session Recording Protocol.
13. Acknowledgements 13. Acknowledgements
We want to thank John Elwell, Paul Kyzivat, Partharsarathi R, Ram We want to thank John Elwell, Paul Kyzivat, Partharsarathi R, Ram
Mohan R, Charles Eckel, Hadriel Kaplan, Adam Roach, Miguel Garcia for Mohan R, Charles Eckel, Hadriel Kaplan, Adam Roach, Miguel Garcia,
their valuable comments and inputs to this document. Thomas Stach for their valuable comments and inputs to this document.
We also want to thank Andrew Hutton, Ram Mohan, Muthu Perumal, John We also want to thank Andrew Hutton, Ram Mohan, Muthu Perumal, John
Elwell, Dan Wing, Hadriel Kaplan, Paul Kyzivat, and Magnus Westerlund Elwell, Dan Wing, Hadriel Kaplan, Paul Kyzivat, and Magnus Westerlund
for their valuable contributions to the RTP Handling portion. for their valuable contributions to the RTP Handling portion.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-siprec-metadata] [I-D.ietf-siprec-metadata]
skipping to change at page 32, line 30 skipping to change at page 35, line 10
[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.
14.2. Informative References 14.2. Informative References
[I-D.ietf-siprec-architecture] [I-D.ietf-siprec-architecture]
Hutton, A., Portman, L., Jain, R., and K. Rehor, "An Hutton, A., Portman, L., Jain, R., and K. Rehor, "An
Architecture for Media Recording using the Session Architecture for Media Recording using the Session
Initiation Protocol", draft-ietf-siprec-architecture-04 Initiation Protocol", draft-ietf-siprec-architecture-05
(work in progress), March 2012. (work in progress), May 2012.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 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
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
skipping to change at page 34, line 4 skipping to change at page 36, line 26
Authors' Addresses Authors' Addresses
Leon Portman Leon Portman
NICE Systems NICE Systems
8 Hapnina 8 Hapnina
Ra'anana 43017 Ra'anana 43017
Israel Israel
Email: leon.portman@nice.com Email: leon.portman@nice.com
Henry Lum (editor) Henry Lum (editor)
Genesys Genesys
1380 Rodick Road, Suite 200 1380 Rodick Road, Suite 201
Markham, Ontario L3R4G5 Markham, Ontario L3R4G5
Canada Canada
Email: henry.lum@genesyslab.com Email: henry.lum@genesyslab.com
Charles Eckel Charles Eckel
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
United States United States
 End of changes. 52 change blocks. 
248 lines changed or deleted 369 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/