draft-ietf-siprec-protocol-01.txt   draft-ietf-siprec-protocol-02.txt 
SIPREC L. Portman, Ed. SIPREC L. Portman, Ed.
Internet-Draft NICE Systems Internet-Draft NICE Systems
Intended status: Standards Track H. Lum, Ed. Intended status: Standards Track H. Lum, Ed.
Expires: April 28, 2012 Genesys, Alcatel-Lucent Expires: May 3, 2012 Genesys, Alcatel-Lucent
A. Johnston A. Johnston
Avaya Avaya
A. Hutton A. Hutton
Siemens Enterprise Siemens Enterprise
Communications Communications
October 26, 2011 October 31, 2011
Session Recording Protocol Session Recording Protocol
draft-ietf-siprec-protocol-01 draft-ietf-siprec-protocol-02
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 to a recording device. Communication Session (CS) to a recording device. The Session
Recording Protocol specifies the use of SIP, SDP, and RTP to
establish a Recording Session (RS) from the Session Recording Client
(SRC), which is on the path of the CS, to a Session Recording Server
(SRS) at the recording device.
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 April 28, 2012. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 21 skipping to change at page 2, line 26
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 5. Initiating a Recording Session . . . . . . . . . . . . . . . . 8
5.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 8 5.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 8
5.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 9 5.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 9
6. SDP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. SDP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 10 6.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 10
6.1.1. Handling media stream updates . . . . . . . . . . . . 11 6.1.1. Handling media stream updates . . . . . . . . . . . . 11
6.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 12 6.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 12
7. RTP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. RTP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 13 8.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 13
8.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 14 8.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 15
8.2.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . 16 8.2.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . 17
9. Persistent Recording . . . . . . . . . . . . . . . . . . . . . 16 9. Persistent Recording . . . . . . . . . . . . . . . . . . . . . 17
10. Extensions for Recording-aware User Agents . . . . . . . . . . 16 10. Extensions for Recording-aware User Agents . . . . . . . . . . 17
10.1. Procedures at the record-aware user agent . . . . . . . . 17 10.1. Procedures at the record-aware user agent . . . . . . . . 17
10.1.1. Recording preference . . . . . . . . . . . . . . . . . 17 10.1.1. Recording preference . . . . . . . . . . . . . . . . . 18
10.2. Procedures at the SRC . . . . . . . . . . . . . . . . . . 18 10.2. Procedures at the SRC . . . . . . . . . . . . . . . . . . 19
10.2.1. Recording indication . . . . . . . . . . . . . . . . . 18 10.2.1. Recording indication . . . . . . . . . . . . . . . . . 19
10.2.2. Recording preference . . . . . . . . . . . . . . . . . 20 10.2.2. Recording preference . . . . . . . . . . . . . . . . . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11.1. Registration of Option Tags . . . . . . . . . . . . . . . 20 11.1. Registration of Option Tags . . . . . . . . . . . . . . . 21
11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . . 20 11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . . 21
11.1.2. record-aware Option Tag . . . . . . . . . . . . . . . 20 11.1.2. record-aware Option Tag . . . . . . . . . . . . . . . 21
11.2. Registration of media feature tags . . . . . . . . . . . . 20 11.2. Registration of media feature tags . . . . . . . . . . . . 21
11.2.1. src feature tag . . . . . . . . . . . . . . . . . . . 20 11.2.1. src feature tag . . . . . . . . . . . . . . . . . . . 21
11.2.2. srs feature tag . . . . . . . . . . . . . . . . . . . 21 11.2.2. srs feature tag . . . . . . . . . . . . . . . . . . . 22
11.3. New Content-Disposition Parameter Registrations . . . . . 21 11.3. New Content-Disposition Parameter Registrations . . . . . 22
11.4. Media Type Registration . . . . . . . . . . . . . . . . . 22 11.4. Media Type Registration . . . . . . . . . . . . . . . . . 22
11.4.1. Registration of MIME Type application/rs-metadata . . 22 11.4.1. Registration of MIME Type application/rs-metadata . . 22
11.4.2. Registration of MIME Type 11.4.2. Registration of MIME Type
application/rs-metadata-request . . . . . . . . . . . 22 application/rs-metadata-request . . . . . . . . . . . 23
11.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 22 11.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 23
11.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . . 22 11.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . . 23
11.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . . 23 11.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . . 23
12. Security Considerations . . . . . . . . . . . . . . . . . . . 23 12. Security Considerations . . . . . . . . . . . . . . . . . . . 24
12.1. Authentication and Authorization . . . . . . . . . . . . . 23 12.1. Authentication and Authorization . . . . . . . . . . . . . 24
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
14.1. Normative References . . . . . . . . . . . . . . . . . . . 24 14.1. Normative References . . . . . . . . . . . . . . . . . . . 24
14.2. Informative References . . . . . . . . . . . . . . . . . . 25 14.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
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) from the Session Recording Client (SRC), which is on the Session (RS) from the Session Recording Client (SRC), which is on the
path of the CS, to a Session Recording Server (SRS) at the recording path of the CS, to a Session Recording Server (SRS) at the recording
device. 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]. specified in [I-D.ietf-siprec-metadata]. Metadata is information
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].
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].
3. Scope 3. Scope
skipping to change at page 4, line 42 skipping to change at page 4, line 43
Agents participating in the CS such as indication of recording. The Agents participating in the CS such as indication of recording. The
user agents need not be recording-aware in order to participate in a user agents need not be recording-aware in order to participate in a
CS being recorded. CS being recorded.
The following items, which are not an exhaustive list, do not The following items, which are not an exhaustive list, do not
represent the protocol itself and are considered out of the scope of represent the protocol itself and are considered out of the scope of
the Session Recording Protocol: the Session Recording Protocol:
o Delivering recorded media in real-time as the CS media o Delivering recorded media in real-time as the CS media
o Specifications of criteria to select specific CS to be recorded or o Specifications of criteria to select a specific CS to be recorded
triggers to record certain CS in the future or triggers to record a certain CS in the future
o Recording policies that determine whether the CS should be o Recording policies that determine whether the CS should be
recorded and whether parts of the CS are to be recorded recorded and whether parts of the CS are to be recorded
o Retention policies that determine how long a recording is stored o Retention policies that determine how long a recording is stored
o Searching and accessing the recorded media and metadata o Searching and accessing the recorded media and metadata
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.
As mentioned in the architecture document As mentioned in the architecture document
[I-D.ietf-siprec-architecture], there are a couple 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 B2BUA with SRC functionality routes a call from UA(A) to When a SIP Back-to-back User Agent (B2BUA) with SRC functionality
UA(B), the SRC has access to the media path between the user agents. routes a call from UA(A) to UA(B), the SRC has access to the media
When the SRC is aware that it should be recording the conversation, path between the user agents. When the SRC is aware that it should
the SRC can cause the B2BUA to bridge the media between UA(A) and be recording the conversation, the SRC can cause the B2BUA to bridge
UA(B). The SRC then establishes the Recording Session with the SRS the media between UA(A) and UA(B). The SRC then establishes the
and sends replicated media towards the SRS. Recording Session with the SRS and sends replicated media towards the
SRS.
An endpoint may also have SRC functionality, where the endpoint An endpoint may also have SRC functionality, where the endpoint
itself establishes the Recording Session to the SRS. Since the itself establishes the Recording Session to the SRS. Since the
endpoint has access to the media in the Communication Session, the endpoint has access to the media in the Communication Session, the
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)OK | | | | (3) 200 OK | |
| |<----------------------| | | |<----------------------| |
| (4)OK | | | | (4) 200 OK | | |
|<-------------| | | |<-------------| | |
| |(5)RS INVITE with SDP | | | |(5)RS INVITE with SDP | |
| |--------------------------------------------->| | |--------------------------------------------->|
| | | (6)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. The conference focus can provide the SRC conference with a mixer. For clarity, ACKs to INVITEs and 200 OKs to
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 record a new call, communication sessions. Every time the SRC wants record a new call,
the SRC updates the recording session with a new SDP offer to add new the SRC updates the recording session with a new SDP offer to add new
recorded streams to the recording session, and correspondingly also recorded streams to the recording session, and correspondingly also
update the metadata for the new call. update the metadata for the new call.
4.2. Delivering recording metadata 4.2. Delivering recording metadata
The SRC is responsible to deliver metadata to the SRS. The SRC may The SRC is responsible for the delivery of metadata to the SRS. The
provide an initial metadata snapshot about recorded media streams in SRC may provide an initial metadata snapshot about recorded media
the initial INVITE content in the recording session. Subsequent streams in the initial INVITE content in the recording session.
metadata updates can be represented as a stream of events in UPDATE Subsequent metadata updates can be represented as a stream of events
or reINVITE requests sent by the SRC. These metadata updates are in UPDATE or reINVITE requests sent by the SRC. These metadata
normally incremental updates to the initial metadata snapshot to updates are normally incremental updates to the initial metadata
optimize on the size of updates, however, the SRC may also decide to snapshot to optimize on the size of updates, however, the SRC may
send a new metadata snapshot anytime. also decide to send a new metadata snapshot anytime.
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
skipping to change at page 8, line 15 skipping to change at page 8, line 15
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) |
|<----------------------------------------------------| |<----------------------------------------------------|
skipping to change at page 8, line 48 skipping to change at page 8, line 49
5. Initiating a Recording Session 5. Initiating a Recording 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. In this case, the From header MUST contain the request to the SRS. In this case, the From header MUST contain the
identity of the SRC, and the To header MUST contain the identity of identity of the SRC, and the To header MUST contain the identity of
the SRS. Participants information is not recorded in the From or To the SRS. Participants information is not recorded in the From or To
header; they are included in the metadata. header; they are included in the metadata.
The SRC MUST include the 'src' feature tag in the Contact URI, as per The SRC MUST include the 'src' feature tag in the Contact URI,
[RFC3840], for all recording sessions. An SRS uses the presence of defined in this specification as an extension to [RFC3840], for all
the 'src' feature tag in dialog creating and modifying requests and recording sessions. An SRS uses the presence of the 'src' feature
responses to confirm that the dialog being created is for the purpose tag in dialog creating and modifying requests and responses to
of a Recording Session. In addition, a registrar could discover that confirm that the dialog being created is for the purpose of a
a UA is an SRC based on the presence of this feature tag in a Recording Session. In addition, a registrar could discover that a UA
is an SRC based on the presence of this feature tag in a
registration. Other SIP Recording extensions and behaviors can be registration. Other SIP Recording extensions and behaviors can be
triggered by the presence of this feature tag. triggered by the presence of this feature tag.
To ensure a recording session is redirected to an SRS, an SRC can
utilize the SIP Caller Preferences extensions, defined in [RFC3841].
The presence of a Accept-Contact: *;sip.srs allows a UA to request
that the INVITE be routed to an SRS. Note that to be completely
sure, the SRC would need to include a Require: prefs header field in
the request.
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 SHOULD include the option tag in a recording session. An SRC SHOULD include the
"siprec" option tag in the Require header when initiating a Recording "siprec" option tag in the Require header when initiating a Recording
Session so that other types of user agents can simply reject the Session so that other types of user agents can simply reject the
INVITE request with a 420 Bad Extension. INVITE request with a 420 Bad Extension.
5.2. Procedures at the SRS 5.2. Procedures at the SRS
skipping to change at page 9, line 42 skipping to change at page 9, line 37
The SRS MUST include the 'srs' feature tag in the Contact URI, as per The SRS MUST include the 'srs' feature tag in the Contact URI, as per
[RFC3840], for all recording sessions. An SRC uses the presence of [RFC3840], for all recording sessions. An SRC uses the presence of
this feature tag in dialog creating and modifying requests and this feature tag in dialog creating and modifying requests and
responses to confirm that the dialog being created is for the purpose responses to confirm that the dialog being created is for the purpose
of a Recording Session (REQ-30). In addition, a registrar could of a Recording Session (REQ-30). In addition, a registrar could
discover that a UA is an SRS based on the presence of this feature discover that a UA is an SRS based on the presence of this feature
tag in a registration. Other SIP Recording extensions and behaviors tag in a registration. Other SIP Recording extensions and behaviors
can be triggered by the presence of this feature tag. can be triggered by the presence of this feature tag.
To ensure a recording session is redirected to an SRC, an SRS can
utilize the SIP Caller Preferences extensions, defined in [RFC3841].
The presence of a Accept-Contact: *;sip.src allows a UA to request
that the INVITE be routed to an SRC. Note that to be completely
sure, the SRS would need to include a Require: prefs header field in
the request.
An SRS SHOULD include the "siprec" option tag in the Require header An SRS SHOULD include the "siprec" option tag in the Require header
as per [RFC3261] when initiating a Recording Session so that other as per [RFC3261] when initiating a Recording Session so that other
types of user agents can simply reject the INVITE request with a 420 types of user agents can simply reject the INVITE request with a 420
Bad Extension. Bad Extension.
6. SDP Handling 6. SDP Handling
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
rest of this section describes conventions used in a recording rest of this section describes conventions used in a recording
session. session.
skipping to change at page 10, line 29 skipping to change at page 10, line 22
The SRC sends recorded streams of participants to the SRS, and the The SRC sends recorded streams of participants to the SRS, and the
SRC MUST provide a label attribute (a=label), as per [RFC4574], on SRC MUST provide a label attribute (a=label), as per [RFC4574], on
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 in [I-D.ietf-siprec-metadata]. Note that a Reference in the metadata in [I-D.ietf-siprec-metadata]. Note that a
recorded stream is different than a CS stream; the metadata provides recorded stream is different than a CS stream; the metadata provides
a list of participants that contributes to each recorded stream. a list of 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 with both audio and video recorded
streams. streams. Note that the following example contain unfolded lines
longer than 72 characters. These are captured between <allOneLine>
tags.
v=0 v=0
o=SRS 2890844526 2890844526 IN IP4 198.51.100.1 o=SRS 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>
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>
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=audio 22458 RTP/AVP 98
a=rtpmap:98 H264/90000 a=rtpmap:98 H264/90000
<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>
a=sendonly a=sendonly
a=label:4 a=label:4
Figure 4: Sample SDP with audio and video streams Figure 4: Sample SDP 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
skipping to change at page 14, line 5 skipping to change at page 15, line 5
disposition. A partial update represents an incremental update since disposition. A partial update represents an incremental update since
the last metadata update sent by the SRC. A partial update sent by the last metadata update sent by the SRC. A partial update sent by
the SRC can be an INVITE request or response with an SDP offer, or an the SRC can be an INVITE request or response with an SDP offer, or an
INVITE/UPDATE request or response containing a "recording-session" INVITE/UPDATE request or response containing a "recording-session"
disposition, or an INVITE request containing both an SDP offer and disposition, or an INVITE request containing both an SDP offer and
the "recording-session" disposition. 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:97753210@10.240.3.10:5060 SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
From: <sip:2000@10.226.240.3>;tag=35e195d2-947d-4585-946f-098392474 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
To: <sip:Recorder@10.240.3.10> From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-098392474
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a@10.226.240.3 To: <sip:recorder@example.com>
CSeq: 101 INVITE Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Date: Thu, 26 Nov 2009 02:38:49 GMT CSeq: 101 INVITE
Supported: timer Max-Forwards: 70
Max-Forwards: 70 Require: siprec
Min-SE: 90 Accept: application/sdp, application/rs-metadata,
Session-Expires: 1800 application/rs-metadata-request
Require: siprec Contact: <sip:2000@src.example.com>;src
Contact: <sip:2000@10.226.240.3:5060;transport=tcp>;src Content-Type: multipart/mixed;boundary=foobar
Via: SIP/2.0/TCP 10.226.240.3:5060;branch=z9hG4bKdf6b622b648d9 Content-Length: [length]
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar --foobar
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=SRS 2890844526 2890844526 IN IP4 198.51.100.1 o=SRS 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
--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 6: 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
skipping to change at page 15, line 20 skipping to change at page 16, line 17
is detected in the metadata. is detected in the metadata.
When the SRS requires a full metadata snapshot, the SRS sends a When the SRS requires a full metadata snapshot, the SRS sends a
metadata snapshot request to the SRC in an INVITE/UPDATE request or metadata snapshot request to the SRC in an INVITE/UPDATE request or
in an INVITE/UPDATE response. The metadata snapshot request is in an INVITE/UPDATE response. The metadata snapshot request is
contained the content with the disposition type "recording-session". contained the content with the disposition type "recording-session".
The format of the content is "application/rs-metadata-request", and The format of the content is "application/rs-metadata-request", and
the body format is chosen to be a simple text-based format. The the body format is chosen to be a simple text-based format. The
following shows an example: following shows an example:
UPDATE sip:2000@10.226.240.3:5060 SIP/2.0 UPDATE sip:2000@src.exmaple.com SIP/2.0
To: <sip:2000@10.226.240.3>;tag=35e195d2-947d-4585-946f-098392474 Via: SIP/2.0/UDP srs.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:Recorder@10.240.3.10>;tag=1234567890 To: <sip:2000@exmaple.com>;tag=35e195d2-947d-4585-946f-098392474
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a@10.226.240.3 From: <sip:recorder@example.com>;tag=1234567890
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
CSeq: 1 UPDATE CSeq: 1 UPDATE
Supported: timer
Max-Forwards: 70 Max-Forwards: 70
Min-SE: 90
Session-Expires: 1800
Require: siprec Require: siprec
Contact: <sip:Recorder@10.240.3.10:5060>;srs Contact: <sip:recorder@srs.example.com>;srs
Via: SIP/2.0/UDP 10.240.3.10:5060;branch=z9hG4bKdf6b622b648d9 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 7: 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
skipping to change at page 17, line 34 skipping to change at page 18, line 28
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 recording-aware UA involved in a CS MAY request the CS to be
recorded or not recorded. This indication of recording preference recorded or not recorded. This indication of recording preference
can be sent at session establishment time or during the session. can be sent at session establishment time or during the session.
A new SDP attribute "recordpref" is introduced. The SDP attribute A new SDP attribute "recordpref" is introduced. The SDP attribute
appears at the media level and can only appear in an SDP offer. The appears at the media level and can appear in an SDP offer or answer.
recording indication applies to the specified media stream only. The The recording indication applies to the specified media stream only.
following is the ABNF of the recordpref attribute: The following is the ABNF of the recordpref attribute:
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 Request for recording if it has not already been started. If the
recording is currently paused, request to resume recording. recording is currently paused, request to resume recording.
off Request for no recording. If recording has already been off Request for no recording. If recording has already been
started, then this preference indicates a request to stop started, then this preference indicates a request to stop
skipping to change at page 19, line 22 skipping to change at page 20, line 17
update the SDP attribute to a=record:off. The following call flow update the SDP attribute to a=record:off. The following call flow
shows an example of the offer/answer with the recording indication shows an example of the offer/answer with the recording indication
attribute. attribute.
UA A UA B UA A UA B
(SRC) | (SRC) |
| | | |
| [SRC recording starts] | | [SRC recording starts] |
|(1) INVITE (SDP offer + a=record:on) | |(1) INVITE (SDP offer + a=record:on) |
|---------------------------------------------------->| |---------------------------------------------------->|
| 200 OK (SDP answer + a=record:off) | | 200 OK (SDP answer) |
|<----------------------------------------------------| |<----------------------------------------------------|
|(3) ACK | |(3) ACK |
|---------------------------------------------------->| |---------------------------------------------------->|
|(4) RTP | |(4) RTP |
|<===================================================>| |<===================================================>|
| [SRC stops recording] | | [SRC stops recording] |
|(5) re-INVITE (SDP + a=record:off) | |(5) re-INVITE (SDP + a=record:off) |
|---------------------------------------------------->| |---------------------------------------------------->|
| (6) 200 OK (SDP + a=record:off)| | (6) 200 OK (SDP + a=record:off)|
|<----------------------------------------------------| |<----------------------------------------------------|
skipping to change at page 24, line 12 skipping to change at page 24, line 45
Mohan R, Charles Eckel, Hadriel Kaplan, Adam Roach, Miguel Garcia for Mohan R, Charles Eckel, Hadriel Kaplan, Adam Roach, Miguel Garcia for
their valuable comments and inputs to this document. their valuable comments and inputs to this document.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-siprec-metadata] [I-D.ietf-siprec-metadata]
R, R., Ravindran, P., and P. Kyzivat, "Session Initiation R, R., Ravindran, P., and P. Kyzivat, "Session Initiation
Protocol (SIP) Recording Metadata", Protocol (SIP) Recording Metadata",
draft-ietf-siprec-metadata-04 (work in progress), draft-ietf-siprec-metadata-05 (work in progress),
September 2011. October 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag
Registration Procedure", BCP 31, RFC 2506, March 1999. Registration Procedure", BCP 31, RFC 2506, March 1999.
 End of changes. 43 change blocks. 
116 lines changed or deleted 113 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/