idnits 2.17.1 draft-ietf-siprec-protocol-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The SRC can temporarily discontinue streaming and collection of recorded media from the SRC to the SRS for reason such as masking the recording. In this case, the SRC sends a new SDP offer and sets the media stream to inactive (a=inactive) for each recorded stream to be paused, as per the procedures in [RFC3264]. To resume streaming and collection of recorded media, the SRC sends a new SDP offer and sets the media streams with a=sendonly attribute. Note that when a CS stream is muted/unmuted, this information is conveyed in the metadata by the SRC. The SRC SHOULD not modify the media stream with a=inactive for mute since this operation is reserved for pausing the RS media. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When the SRS explicitly requests for a full metadata snapshot, the SRS MUST send an UPDATE request without an SDP offer. A metadata snapshot request contains a content with the content disposition type "recording-session". Note that the SRS MAY generate an INVITE request without an SDP offer but this MUST not include a metadata snapshot request. The format of the content is "application/ rs-metadata-request", and the body format is chosen to be a simple text-based format. The following shows an example: -- The document date (June 27, 2012) is 4318 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TEXT-UTF8-TRIM' is mentioned on line 1121, but not defined == Unused Reference: 'RFC2119' is defined on line 1491, but no explicit reference was found in the text == Unused Reference: 'RFC2804' is defined on line 1500, but no explicit reference was found in the text == Unused Reference: 'RFC3841' is defined on line 1516, but no explicit reference was found in the text == Unused Reference: 'RFC4508' is defined on line 1550, but no explicit reference was found in the text == Unused Reference: 'RFC4579' is defined on line 1554, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-siprec-metadata-06 ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Downref: Normative reference to an Informational RFC: RFC 2804 ** Downref: Normative reference to an Informational RFC: RFC 6341 == Outdated reference: A later version (-12) exists of draft-ietf-siprec-architecture-05 -- Obsolete informational reference (is this intentional?): RFC 6222 (Obsoleted by RFC 7022) Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPREC L. Portman 3 Internet-Draft NICE Systems 4 Intended status: Standards Track H. Lum, Ed. 5 Expires: December 29, 2012 Genesys 6 C. Eckel 7 Cisco 8 A. Johnston 9 Avaya 10 A. Hutton 11 Siemens Enterprise 12 Communications 13 June 27, 2012 15 Session Recording Protocol 16 draft-ietf-siprec-protocol-05 18 Abstract 20 This document specifies the use of the Session Initiation Protocol 21 (SIP), the Session Description Protocol (SDP), and the Real Time 22 Protocol (RTP) for delivering real-time media and metadata from a 23 Communication Session (CS) to a recording device. The Session 24 Recording Protocol specifies the use of SIP, SDP, and RTP to 25 establish a Recording Session (RS) between the Session Recording 26 Client (SRC), which is on the path of the CS, and a Session Recording 27 Server (SRS) at the recording device. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 29, 2012. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Overview of operations . . . . . . . . . . . . . . . . . . . . 5 67 4.1. Delivering recorded media . . . . . . . . . . . . . . . . 5 68 4.2. Delivering recording metadata . . . . . . . . . . . . . . 7 69 4.3. Receiving recording indications and providing 70 recording preferences . . . . . . . . . . . . . . . . . . 8 71 5. Initiating a Recording Session . . . . . . . . . . . . . . . . 9 72 5.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 10 73 5.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 10 74 6. SDP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 6.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 11 76 6.1.1. Handling media stream updates . . . . . . . . . . . . 12 77 6.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 13 78 7. RTP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 7.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 7.1.1. SRC acting as an RTP Translator . . . . . . . . . . . 16 81 7.1.1.1. Forwarding Translator . . . . . . . . . . . . . . 16 82 7.1.1.2. Transcoding Translator . . . . . . . . . . . . . . 17 83 7.1.2. SRC acting as an RTP Mixer . . . . . . . . . . . . . . 18 84 7.1.3. SRC acting as an RTP Endpoint . . . . . . . . . . . . 18 85 7.2. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 7.3. RTP Profile . . . . . . . . . . . . . . . . . . . . . . . 19 87 7.4. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 7.5. CSRC . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 7.6. SDES . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 90 7.6.1. CNAME . . . . . . . . . . . . . . . . . . . . . . . . 20 91 7.7. Keepalive . . . . . . . . . . . . . . . . . . . . . . . . 21 92 7.8. RTCP Feedback Messages . . . . . . . . . . . . . . . . . . 21 93 7.8.1. Full Intra Request . . . . . . . . . . . . . . . . . . 21 94 7.8.1.1. SIP INFO for FIR . . . . . . . . . . . . . . . . . 21 95 7.8.2. Picture Loss Indicator . . . . . . . . . . . . . . . . 21 96 7.8.3. Temporary Maximum Media Stream Bit Rate Request . . . 22 97 7.8.3.1. Renegotiation of SDP bandwidth attribute . . . . . 22 98 7.9. Symmetric RTP/RTCP for Sending and Receiving . . . . . . . 22 99 8. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 100 8.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 23 101 8.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 24 102 8.2.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . 26 103 9. Persistent Recording . . . . . . . . . . . . . . . . . . . . . 26 104 10. Extensions for Recording-aware User Agents . . . . . . . . . . 26 105 10.1. Procedures at the record-aware user agent . . . . . . . . 27 106 10.1.1. Recording preference . . . . . . . . . . . . . . . . . 27 107 10.2. Procedures at the SRC . . . . . . . . . . . . . . . . . . 28 108 10.2.1. Recording indication . . . . . . . . . . . . . . . . . 28 109 10.2.2. Recording preference . . . . . . . . . . . . . . . . . 29 110 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 111 11.1. Registration of Option Tags . . . . . . . . . . . . . . . 29 112 11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . . 29 113 11.1.2. record-aware Option Tag . . . . . . . . . . . . . . . 30 114 11.2. Registration of media feature tags . . . . . . . . . . . . 30 115 11.2.1. src feature tag . . . . . . . . . . . . . . . . . . . 30 116 11.2.2. srs feature tag . . . . . . . . . . . . . . . . . . . 31 117 11.3. New Content-Disposition Parameter Registrations . . . . . 31 118 11.4. Media Type Registration . . . . . . . . . . . . . . . . . 31 119 11.4.1. Registration of MIME Type application/rs-metadata . . 31 120 11.4.2. Registration of MIME Type 121 application/rs-metadata-request . . . . . . . . . . . 32 122 11.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 32 123 11.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . . 32 124 11.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . . 32 125 12. Security Considerations . . . . . . . . . . . . . . . . . . . 33 126 12.1. RTP handling . . . . . . . . . . . . . . . . . . . . . . . 33 127 12.2. Authentication and Authorization . . . . . . . . . . . . . 33 128 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 129 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 130 14.1. Normative References . . . . . . . . . . . . . . . . . . . 34 131 14.2. Informative References . . . . . . . . . . . . . . . . . . 35 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 134 1. Introduction 136 This document specifies the mechanism to record a Communication 137 Session (CS) by delivering real-time media and metadata from the CS 138 to a recording device. In accordance to the architecture 139 [I-D.ietf-siprec-architecture], the Session Recording Protocol 140 specifies the use of SIP, SDP, and RTP to establish a Recording 141 Session (RS) between the Session Recording Client (SRC), which is on 142 the path of the CS, and a Session Recording Server (SRS) at the 143 recording device. 145 SIP is also used to deliver metadata to the recording device, as 146 specified in [I-D.ietf-siprec-metadata]. Metadata is information 147 that describes recorded media and the CS to which they relate. 149 The Session Recording Protocol intends to satisfy the SIP-based Media 150 Recording requirements listed in [RFC6341]. 152 In addition to the Session Recording Protocol, this document 153 specifies extensions for user agents that are participants in a CS to 154 receive recording indications and to provide preferences for 155 recording. 157 2. Definitions 159 This document refers to the core definitions provided in the 160 architecture document [I-D.ietf-siprec-architecture]. 162 The RTP Handling section uses the definitions provided in "RTP: A 163 Transport Protocol for Real-Time Application" [RFC3550]. 165 3. Scope 167 The scope of the Session Recording Protocol includes the 168 establishment of the recording sessions and the reporting of the 169 metadata. The scope also includes extensions supported by User 170 Agents participating in the CS such as indication of recording. The 171 user agents need not be recording-aware in order to participate in a 172 CS being recorded. 174 The following items, which are not an exhaustive list, do not 175 represent the protocol itself and are considered out of the scope of 176 the Session Recording Protocol: 178 o Delivering recorded media in real-time as the CS media 180 o Specifications of criteria to select a specific CS to be recorded 181 or triggers to record a certain CS in the future 183 o Recording policies that determine whether the CS should be 184 recorded and whether parts of the CS are to be recorded 186 o Retention policies that determine how long a recording is stored 188 o Searching and accessing the recorded media and metadata 190 o Policies governing how CS users are made aware of recording 192 o Delivering additional recording session metadata through non-SIP 193 mechanism 195 4. Overview of operations 197 This section is informative and provides a description of recording 198 operations. 200 Section 5 provides the procedures for establishing a recording 201 session between a SRC and a SRS. Section 6 describes the SDP in a 202 recording session. Section 7 describes the RTP handling in a 203 recording session. Section 8 descirbes the mechanism to deliver 204 recording metadata from the SRC to the SRS. 206 Section 10 descirbes the procedures for user agents partcipating in a 207 CS to receive recording indications and to provide preferences for 208 recording. 210 As mentioned in the architecture document 211 [I-D.ietf-siprec-architecture], there are a number of types of call 212 flows based on the location of the Session Recording Client. The 213 following sample call flows provide a quick overview of the 214 operations between the SRC and the SRS. 216 4.1. Delivering recorded media 218 When a SIP Back-to-back User Agent (B2BUA) with SRC functionality 219 routes a call from UA(A) to UA(B), the SRC has access to the media 220 path between the user agents. When the SRC is aware that it should 221 be recording the conversation, the SRC can cause the B2BUA to bridge 222 the media between UA(A) and UA(B). The SRC then establishes the 223 Recording Session with the SRS and sends replicated media towards the 224 SRS. 226 An endpoint may also have SRC functionality, where the endpoint 227 itself establishes the Recording Session to the SRS. Since the 228 endpoint has access to the media in the Communication Session, the 229 endpoint can send replicated media towards the SRS. 231 The following is a sample call flow that shows the SRC establishing a 232 recording session towards the SRS. The call flow is essentially 233 identical when the SRC is a B2BUA or as the endpoint itself. Note 234 that the SRC can choose when to establish the Recording Session 235 independent of the Communication Session, even though the following 236 call flow suggests that the SRC is establishing the Recording Session 237 (message #5) after the Communication Session is established. 239 UA A SRC UA B SRS 240 |(1)CS INVITE | | | 241 |------------->| | | 242 | |(2)CS INVITE | | 243 | |---------------------->| | 244 | | (3) 200 OK | | 245 | |<----------------------| | 246 | (4) 200 OK | | | 247 |<-------------| | | 248 | |(5)RS INVITE with SDP | | 249 | |--------------------------------------------->| 250 | | | (6) 200 OK with SDP | 251 | |<---------------------------------------------| 252 |(7)CS RTP | | | 253 |=============>|======================>| | 254 |<=============|<======================| | 255 | |(8)RS RTP | | 256 | |=============================================>| 257 | |=============================================>| 258 |(9)CS BYE | | | 259 |------------->| | | 260 | |(10)CS BYE | | 261 | |---------------------->| | 262 | |(11)RS BYE | | 263 | |--------------------------------------------->| 264 | | | | 266 Figure 1: Basic recording call flow 268 The above call flow can also apply to the case of a centralized 269 conference with a mixer. For clarity, ACKs to INVITEs and 200 OKs to 270 BYEs are not shown. The conference focus can provide the SRC 271 functionality since the conference focus has access to all the media 272 from each conference participant. When a recording is requested, the 273 SRC delivers the metadata and the media streams to the SRS. Since 274 the conference focus has access to a mixer, the SRC may choose to mix 275 the media streams from all participants as a single mixed media 276 stream towards the SRS. 278 An SRC can use a single recording session to record multiple 279 communication sessions. Every time the SRC wants to record a new 280 call, the SRC updates the recording session with a new SDP offer to 281 add new recorded streams to the recording session, and 282 correspondingly also update the metadata for the new call. 284 An SRS can also establish a recording session to an SRC, although it 285 is beyond the scope of this document to define how an SRS would 286 specify which calls to record. 288 4.2. Delivering recording metadata 290 The SRC is responsible for the delivery of metadata to the SRS. The 291 SRC may provide an initial metadata snapshot about recorded media 292 streams in the initial INVITE content in the recording session. 293 Subsequent metadata updates can be represented as a stream of events 294 in UPDATE or reINVITE requests sent by the SRC. These metadata 295 updates are normally incremental updates to the initial metadata 296 snapshot to optimize on the size of updates, however, the SRC may 297 also decide to send a new metadata snapshot anytime. 299 Metadata is transported in the body of INVITE or UPDATE messages. 300 Certain metadata, such as the attributes of the recorded media stream 301 are located in the SDP of the recording session. 303 The SRS has the ability to send a request to the SRC to request for a 304 new metadata snapshot update from the SRC. This can happen when the 305 SRS fails to understand the current stream of incremental updates for 306 whatever reason, for example, when SRS loses the current state due to 307 internal failure. The SRS may optionally attach a reason along with 308 the snapshot request. This request allows both SRC and SRS to 309 synchronize the states with a new metadata snapshot so that further 310 metadata incremental updates will be based on the latest metadata 311 snapshot. Similar to the metadata content, the metadata snapshot 312 request is transported as content in UPDATE or INVITE sent by the SRS 313 in the recording session. 315 SRC SRS 316 | | 317 |(1) INVITE (metadata snapshot) | 318 |---------------------------------------------------->| 319 | (2)200 OK | 320 |<----------------------------------------------------| 321 |(3) ACK | 322 |---------------------------------------------------->| 323 |(4) RTP | 324 |====================================================>| 325 |====================================================>| 326 |(5) UPDATE (metadata update 1) | 327 |---------------------------------------------------->| 328 | (6) 200 OK | 329 |<----------------------------------------------------| 330 |(7) UPDATE (metadata update 2) | 331 |---------------------------------------------------->| 332 | (8) 200 OK | 333 |<----------------------------------------------------| 334 | (9) UPDATE (metadata snapshot request) | 335 |<----------------------------------------------------| 336 | (10) 200 OK | 337 |---------------------------------------------------->| 338 | (11) INVITE (metadata snapshot 2 + SDP offer) | 339 |---------------------------------------------------->| 340 | (12) 200 OK (SDP answer) | 341 |<----------------------------------------------------| 342 | (13) UPDATE (metadata update 1 based on snapshot 2) | 343 |---------------------------------------------------->| 344 | (14) 200 OK | 345 |<----------------------------------------------------| 347 Figure 2: Delivering metadata via SIP UPDATE 349 4.3. Receiving recording indications and providing recording 350 preferences 352 The SRC is responsible to provide recording indications to the 353 participants in the CS. User agents that are recording-aware 354 supports receiving recording indications with new SDP attribute 355 a=record and the recording-aware UA can also set recording preference 356 in the CS with a new SDP attribute a=recordpref. The recording 357 attribute is a declaration by the SRC in the CS to indicate whether 358 recording is taking place. The recording preference attribute is a 359 declaration by the recording-aware UA in the CS to indicate the 360 recording preference. 362 To illustrate how the attributes are used, if a UA (A) is initiating 363 a call to UA (B) and UA (A) is also an SRC that is performing the 364 recording, then UA (A) provides the recording indication in the SDP 365 offer with a=record:on. Since UA (A) is the SRC, UA (A) receives the 366 recording indication from the SRC directly. When UA (B) receives the 367 SDP offer, UA (B) will see that recording is happening on the other 368 endpoint of this session. Since UA (B) is not an SRC and does not 369 provide any recording preference, the SDP answer does not contain 370 a=record nor a=recordpref. 372 UA A UA B 373 (SRC) | 374 | | 375 | [SRC recording starts] | 376 |(1) INVITE (SDP offer + a=record:on) | 377 |---------------------------------------------------->| 378 | (2) 200 OK (SDP answer) | 379 |<----------------------------------------------------| 380 |(3) ACK | 381 |---------------------------------------------------->| 382 |(4) RTP | 383 |<===================================================>| 384 | | 385 | [UA B wants to set preference to no recording] | 386 | (5) INVITE (SDP offer + a=recordpref:off) | 387 |<----------------------------------------------------| 388 | [SRC honors the preference and stops recording] | 389 |(6) 200 OK (SDP answer + a=record:off) | 390 |---------------------------------------------------->| 391 | (7) ACK | 392 |<----------------------------------------------------| 394 Figure 3: Recording indication and recording preference 396 After the call is established and recording is in progress, UA (B) 397 later decides to change the recording preference to no recording and 398 sends a reINVITE with the a=recordpref attribute. It is up to the 399 SRC to honor the preference, and in this case SRC decides to stop the 400 recording and updates the recording indication in the SDP answer. 402 5. Initiating a Recording Session 404 A recording session is a SIP session with specific extensions 405 applied, and these extensions are listed in the procedures below. 406 When an SRC or an SRS receives a SIP session that is not a recording 407 session, it is up to the SRC or the SRS to determine what to do with 408 the SIP session. 410 5.1. Procedures at the SRC 412 The SRC can initiate a recording session by sending a SIP INVITE 413 request to the SRS. The SRC and the SRS are identified in the From 414 and To headers, respectively. 416 The SRC MUST include the '+sip.src' feature tag in the Contact URI, 417 defined in this specification as an extension to [RFC3840], for all 418 recording sessions. An SRS uses the presence of the '+sip.src' 419 feature tag in dialog creating and modifying requests and responses 420 to confirm that the dialog being created is for the purpose of a 421 Recording Session. In addition, when an SRC sends a REGISTER request 422 to a registrar, the SRC MUST include the '+sip.src' feature tag to 423 indicate the that it is a SRC. 425 Since SIP Caller Preferences extensions are optional to implement for 426 routing proxies, there is no guarantee that a recording session will 427 be routed to an SRC or SRS. A new options tag is introduced: 428 "siprec". As per [RFC3261], only an SRC or an SRS can accept this 429 option tag in a recording session. An SRC MUST include the "siprec" 430 option tag in the Require header when initiating a Recording Session 431 so that UA's which do not support the session recording protocol 432 extensions will simply reject the INVITE request with a 420 Bad 433 Extension. 435 When an SRC receives a new INVITE, the SRC MUST only consider the SIP 436 session as a recording session when both the '+sip.srs' feature tag 437 and 'siprec' option tag are included in the INVITE request. 439 5.2. Procedures at the SRS 441 When an SRS receives a new INVITE, the SRS MUST only consider the SIP 442 session as a recording session when both the '+sip.src' feature tag 443 and 'siprec' option tag are included in the INVITE request. 445 The SRS can initiate a recording session by sending a SIP INVITE 446 request to the SRC. The SRS and the SRC are identified in the From 447 and To headers, respectively. 449 The SRS MUST include the '+sip.srs' feature tag in the Contact URI, 450 as per [RFC3840], for all recording sessions. An SRC uses the 451 presence of this feature tag in dialog creating and modifying 452 requests and responses to confirm that the dialog being created is 453 for the purpose of a Recording Session (REQ-30). In addition, when 454 an SRS sends a REGISTER request to a registrar, the SRS MUST include 455 the '+sip.srs' feature tag to indicate that it is a SRS. 457 An SRS MUST include the "siprec" option tag in the Require header as 458 per [RFC3261] when initiating a Recording Session so that UA's which 459 do not support the session recording protocol extensions will simply 460 reject the INVITE request with a 420 Bad Extension. 462 6. SDP Handling 464 The SRC and SRS follows the SDP offer/answer model in [RFC3264]. The 465 rest of this section describes conventions used in a recording 466 session. 468 6.1. Procedures at the SRC 470 Since the SRC does not expect to receive media from the SRS, the SRC 471 typically sets each media stream of the SDP offer to only send media, 472 by qualifying them with the a=sendonly attribute, according to the 473 procedures in [RFC3264]. 475 The SRC sends recorded streams of participants to the SRS, and the 476 SRC MUST provide a label attribute (a=label), as per [RFC4574], on 477 each media stream in order to identify the recorded stream with the 478 rest of the metadata. The a=label attribute identifies each recorded 479 media stream, and the label name is mapped to the Media Stream 480 Reference in the metadata as per [I-D.ietf-siprec-metadata]. The 481 scope of the label name only applies to the same SIP message as the 482 SDP, meaning that the label name can be reused by another media 483 stream within the same recording session. Note that a recorded 484 stream is distinct from a CS stream; the metadata provides a list of 485 participants that contributes to each recorded stream. 487 The following is an example of SDP offer from SRC with both audio and 488 video recorded streams. Note that the following example contain 489 unfolded lines longer than 72 characters. These are captured between 490 tags. 492 v=0 493 o=SRC 2890844526 2890844526 IN IP4 198.51.100.1 494 s=- 495 c=IN IP4 198.51.100.1 496 t=0 0 497 m=audio 12240 RTP/AVP 0 4 8 498 a=sendonly 499 a=label:1 500 m=video 22456 RTP/AVP 98 501 a=rtpmap:98 H264/90000 502 503 a=fmtp:98 profile-level-id=42A01E; 504 sprop-parameter-sets=Z0IACpZTBYmI,aMljiA== 505 506 a=sendonly 507 a=label:2 508 m=audio 12242 RTP/AVP 0 4 8 509 a=sendonly 510 a=label:3 511 m=video 22458 RTP/AVP 98 512 a=rtpmap:98 H264/90000 513 514 a=fmtp:98 profile-level-id=42A01E; 515 sprop-parameter-sets=Z0IACpZTBYmI,aMljiA== 516 517 a=sendonly 518 a=label:4 520 Figure 4: Sample SDP offer from SRC with audio and video streams 522 6.1.1. Handling media stream updates 524 Over the lifetime of a recording session, the SRC can add and remove 525 recorded streams from the recording session for various reasons. For 526 example, when a CS stream is added or removed from the CS, or when a 527 CS is created or terminated if a recording session handles multiple 528 CSes. To remove a recorded stream from the recording session, the 529 SRC sends a new SDP offer where the port of the media stream to be 530 removed is set to zero, according to the procedures in [RFC3264]. To 531 add a recorded stream to the recording session, the SRC sends a new 532 SDP offer by adding a new media stream description or by reusing an 533 old media stream which had been previously disabled, according to the 534 procedures in [RFC3264]. 536 The SRC can temporarily discontinue streaming and collection of 537 recorded media from the SRC to the SRS for reason such as masking the 538 recording. In this case, the SRC sends a new SDP offer and sets the 539 media stream to inactive (a=inactive) for each recorded stream to be 540 paused, as per the procedures in [RFC3264]. To resume streaming and 541 collection of recorded media, the SRC sends a new SDP offer and sets 542 the media streams with a=sendonly attribute. Note that when a CS 543 stream is muted/unmuted, this information is conveyed in the metadata 544 by the SRC. The SRC SHOULD not modify the media stream with 545 a=inactive for mute since this operation is reserved for pausing the 546 RS media. 548 6.2. Procedures at the SRS 550 The SRS only receives RTP streams from the SRC, the SDP answer 551 normally sets each media stream to receive media, by setting them 552 with the a=recvonly attribute, according to the procedures of 553 [RFC3264]. When the SRS is not ready to receive a recorded stream, 554 the SRS sets the media stream as inactive in the SDP offer or answer 555 by setting it with a=inactive attribute, according to the procedures 556 of [RFC3264]. When the SRS is ready to receive recorded streams, the 557 SRS sends a new SDP offer and sets the media streams with a=recvonly 558 attribute. 560 The following is an example of SDP answer from SRS for the SDP offer 561 from the above sample. Note that the following example contain 562 unfolded lines longer than 72 characters. These are captured between 563 tags. 565 v=0 566 o=SRS 0 0 IN IP4 198.51.100.20 567 s=- 568 c=IN IP4 198.51.100.20 569 t=0 0 570 m=audio 10000 RTP/AVP 0 4 8 571 a=recvonly 572 a=label:1 573 m=video 10002 RTP/AVP 98 574 a=rtpmap:98 H264/90000 575 576 a=fmtp:98 profile-level-id=42A01E; 577 sprop-parameter-sets=Z0IACpZTBYmI,aMljiA== 578 579 a=recvonly 580 a=label:2 581 m=audio 10004 RTP/AVP 0 4 8 582 a=recvonly 583 a=label:3 584 m=video 10006 RTP/AVP 98 585 a=rtpmap:98 H264/90000 586 587 a=fmtp:98 profile-level-id=42A01E; 588 sprop-parameter-sets=Z0IACpZTBYmI,aMljiA== 589 590 a=recvonly 591 a=label:4 593 Figure 5: Sample SDP answer from SRS with audio and video streams 595 Over the lifetime of a recording session, the SRS can remove recorded 596 streams from the recording session for various reasons. To remove a 597 recorded stream from the recording session, the SRS sends a new SDP 598 offer where the port of the media stream to be removed is set to 599 zero, according to the procedures in [RFC3264]. 601 The SRS SHOULD NOT add recorded streams in the recording session when 602 SRS sends a new SDP offer. Similarly, when the SRS starts a 603 recording session, the SRS SHOULD initiate the INVITE without an SDP 604 offer to let the SRC generate the SDP offer with recorded streams. 606 The following sequence diagram shows an example where the SRS is 607 initially not ready to receive recorded streams, and later updates 608 the recording session when the SRS is ready to record. 610 SRC SRS 611 | | 612 |(1) INVITE (SDP offer) | 613 |---------------------------------------------------->| 614 | [not ready to record] 615 | (2)200 OK with SDP inactive | 616 |<----------------------------------------------------| 617 |(3) ACK | 618 |---------------------------------------------------->| 619 | ... | 620 | [ready to record] 621 | (4) re-INVITE with SDP recvonly | 622 |<----------------------------------------------------| 623 |(5)200 OK with SDP sendonly | 624 |---------------------------------------------------->| 625 | (6) ACK | 626 |<----------------------------------------------------| 627 |(7) RTP | 628 |====================================================>| 629 | ... | 630 |(8) BYE | 631 |---------------------------------------------------->| 632 | (9) OK | 633 |<----------------------------------------------------| 635 Figure 6: SRS responding to offer with a=inactive 637 7. RTP Handling 639 This section provides recommendations and guidelines for RTP and RTCP 640 in the context of SIPREC. In order to communicate most effectively, 641 the Session Recording Client (SRC) and the Session Recording Server 642 (SRS) SHOULD utilize the mechanisms provided by RTP in a well defined 643 and predicable manner. It is the goal of this document to make the 644 reader aware of these mechanisms and provide recommendations and 645 guidelines. 647 7.1. Roles 649 An SRC has the task of gathering media from the various UAs in a 650 Communication Session (CS) and forwarding the information to the SRS 651 within the context of a Recording Session (RS). There are numerous 652 ways in which an SRC may do this is, including appearing as one of 653 the UAs within a CS, or as a B2BUA between UAs within a CS. 655 SRS 656 ^ 657 | 658 RS 659 | 660 v 661 UA <-- CS --> SRC 663 Figure 7: UA as SRC 665 SRS 666 ^ 667 | 668 RS 669 | 670 v 671 UA1 <-- CS --> SRC <-- CS --> UA2 673 Figure 8: B2BUA as SRC 675 The following subsections define a set of roles an SRC may choose to 676 play based on its position with respect to a UA within a CS, and an 677 SRS within an RS. 679 7.1.1. SRC acting as an RTP Translator 681 The SRC may act as a translator, as defined in [RFC3550]. A defining 682 characteristic of a translator is that it forwards RTP packets with 683 their SSRC identifier intact. There are two types of translators, 684 one that simply forwards, and another that performs transcoding 685 (e.g., from one codec to another) in addition to forwarding. 687 7.1.1.1. Forwarding Translator 689 When acting as a forwarding translator, RTP received as separate 690 streams from different sources (e.g., from different UAs with 691 different SSRCs) cannot be mixed by the SRC and MUST be sent 692 separately to the SRS. All RTCP reports MUST be passed by the SRC 693 between the UAs and the SRS, such that the UAs and SRS are able to 694 detect any SSRC collisions. 696 RTCP Sender Reports generated by a UA sending a stream MUST be 697 forwarded to the SRS. RTCP Receiver Reports generated by the SRS 698 MUST be forwarded to the relevant UA. 700 UAs may receive multiple sets of RTCP Receiver Reports, one or more 701 from other UAs participating in the CS, and one from the SRS 702 participating in the RS. A SIPREC aware UA SHOULD be prepared to 703 process the RTCP Receiver Reports from the SRS, whereas a SIPREC 704 unaware UA may discard such RTCP packets as not of relevance. 706 If SRTP is used on both the CS and the RS, decryption and/or re- 707 encryption may occur. For example, if different keys are used, it 708 will occur. If the same keys are used, it need not occur. 710 If packet loss occurs, either from the UA to the SRC or from the SRC 711 to the SRS, the SRS SHOULD detect and attempt to recover from the 712 loss. The SRC does not play a role in this other than forwarding the 713 associated RTP and RTCP packets. 715 7.1.1.2. Transcoding Translator 717 When acting as a transcoding translator, an SRC MAY perform 718 transcoding (e.g., from one codec to another), and this may result in 719 a different rate of packets between what the SRC receives and what 720 the SRC sends. As when acting as a forwarding translator, RTP 721 received as separate streams from different sources (e.g., from 722 different UAs with different SSRCs) cannot be mixed by the SRC and 723 MUST be sent separately to the SRS. All RTCP reports MUST passed by 724 the SRC between the UAs and the SRS, such the UAs and SRS they are 725 able to detect any SSRC collisions. 727 RTCP Sender Reports generated by a UA sending a stream MUST be 728 forwarded to the SRS. RTCP Receiver Reports generated by the SRS 729 MUST be forwarded to the relevant UA. The SRC may need to manipulate 730 the RTCP Receiver Reports to take account of any transcoding that has 731 taken place. 733 UAs may receive multiple sets of RTCP Receiver Reports, one or more 734 from other UAs participating in the CS, and one from the SRS 735 participating in the RS. A SIPREC aware UA SHOULD be prepared to 736 process the RTCP Receiver Reports from the SRS, whereas a SIPREC 737 unaware UA may discard such RTCP packets as not of relevance. 739 If SRTP is used on both the CS and the RS, decryption and/or re- 740 encryption may occur. For example, if different keys are used, it 741 will occur. If the same keys are used, it need not occur. 743 If packet loss occurs, either from the UA to the SRC or from the SRC 744 to the SRS, the SRS SHOULD detect and attempt to recover from the 745 loss. The SRC does not play a role in this other than forwarding the 746 associated RTP and RTCP packets. 748 7.1.2. SRC acting as an RTP Mixer 750 In the case of the SRC acting as a RTP mixer, as defined in 751 [RFC3550], the SRC combines RTP streams from different UA and sends 752 them towards the SRS using its own SSRC. The SSRCs from the 753 contributing UA SHOULD be conveyed as CSRCs identifiers within this 754 stream. The SRC may make timing adjustments among the received 755 streams and generate its own timing on the stream sent to the SRS. 756 Optionally an SRC acting as a mixer can perform transcoding, and can 757 even cope with different codings received from different UAs. RTCP 758 Sender Reports and Receiver Reports are not forwarded by an SRC 759 acting as mixer, but there are requirements for forwarding RTCP 760 Source Description (SDES) packets. The SRC generates its own RTCP 761 Sender and Receiver reports toward the associated UAs and SRS. The 762 use of SRTP between the SRC and the SRS for the RS is independent of 763 the use of SRTP between the UAs and SRC for the CS. 765 If packet loss occurs from the UA to the SRC, the SRC SHOULD detect 766 and attempt to recover from the loss. If packet loss occurs from the 767 SRC to the SRS, the SRS SHOULD detect and attempt to recover from the 768 loss. 770 7.1.3. SRC acting as an RTP Endpoint 772 The case of the SRC acting as an RTP endpoint, as defined in 773 [RFC3550], is similar to the mixer case, except that the RTP session 774 between the SRC and the SRS is considered completely independent from 775 the RTP session that is part of the CS. The SRC can, but need not, 776 mix RTP streams from different participants prior to sending to the 777 SRS. RTCP between the SRC and the SRS is completely independent of 778 RTCP on the CS. The use of SRTP between the SRC and the SRS is 779 independent of the use of SRTP on the CS. 781 If packet loss occurs from the UA to the SRC, the SRC SHOULD detect 782 and attempt to recover from the loss. If packet loss occurs from the 783 SRC to the SRS, the SRS SHOULD detect and attempt to recover from the 784 loss. 786 7.2. RTCP 788 The RTP data transport is augmented by a control protocol (RTCP) to 789 allow monitoring of the data delivery. RTCP, as defined in 790 [RFC3550], is based on the periodic transmission of control packets 791 to all participants in the RTP session, using the same distribution 792 mechanism as the data packets. Support for RTCP is REQUIRED, per 793 [RFC3550], and it provides, among other things, the following 794 important functionality in relation to SIPREC: 796 1) Feedback on the quality of the data distribution 798 This feedback from the receivers may be used to diagnose faults in 799 the distribution. As such, RTCP is a well defined and efficient 800 mechanism for the SRS to inform the SRC of issues that arise with 801 respect to its reception of media that is to be recorded. 803 2) Carries a persistent transport-level identifier for an RTP source 804 called the canonical name or CNAME 806 The SSRC identifier may change if a conflict is discovered or a 807 program is restarted; in which case receivers can use the CNAME to 808 keep track of each participant. Receivers may also use the CNAME to 809 associate multiple data streams from a given participant in a set of 810 related RTP sessions, for example to synchronize audio and video. 811 Synchronization of media streams is also facilitated by the NTP and 812 RTP timestamps included in RTCP packets by data senders. 814 7.3. RTP Profile 816 The RECOMMENDED RTP profiles for both the SRC and SRS are "Extended 817 Secure RTP Profile for Real-time Transport Control Protocol (RTCP)- 818 Based Feedback (RTP/SAVPF)", [RFC5124] when using encrypted RTP 819 streams, and "Extended RTP Profile for Real-time Transport Control 820 Protocol (RTCP)-Based Feedback (RTP/AVPF)", [RFC4585] when using non 821 encrypted media streams. However, as this is not a requirement, some 822 implementations may use "The Secure Real-time Transport Protocol 823 (SRTP)", [RFC3711] and "RTP Profile for Audio and Video Conferences 824 with Minimal Control", AVP [RFC3551]. Therefore, it is RECOMMENDED 825 that the SRC and SRS not rely entirely on SAVPF or AVPF for core 826 functionality that may be at least partially achievable using SAVP 827 and AVP. 829 AVPF and SAVPF provide an improved RTCP timer model that allows more 830 flexible transmission of RTCP packets as response to events, rather 831 than strictly according to bandwidth. AVPF based codec control 832 messages provide efficient mechanisms for an SRC and SRS to handle 833 events such as scene changes, error recovery, and dynamic bandwidth 834 adjustments. These messages are discussed in more detail later in 835 this document. 837 SAVP and SAVPF provide media encryption, integrity protection, replay 838 protection, and a limited form of source authentication. They do not 839 contain or require a specific keying mechanism. 841 7.4. SSRC 843 The synchronization source (SSRC), as defined in [RFC3550], is 844 carried in the RTP header and in various fields of RTCP packets. It 845 is a random 32-bit number that is required to be globally unique 846 within an RTP session. It is crucial that the number be chosen with 847 care in order that participants on the same network or starting at 848 the same time are not likely to choose the same number. Guidelines 849 regarding SSRC value selection and conflict resolution are provided 850 in [RFC3550]. 852 The SSRC may also be used to separate different sources of media 853 within a single RTP session. For this reason as well as for conflict 854 resolution, it is important that the SRC and SRS handle changes in 855 SSRC values and properly identify the reason of the change. The 856 CNAME values carried in RTCP facilitate this identification. 858 7.5. CSRC 860 The contributing source (CSRC), as defined in [RFC3550], identifies 861 the source of a stream of RTP packets that has contributed to the 862 combined stream produced by an RTP mixer. The mixer inserts a list 863 of the SSRC identifiers of the sources that contributed to the 864 generation of a particular packet into the RTP header of that packet. 865 This list is called the CSRC list. It is RECOMMENDED that a SRC, 866 when acting a mixer, sets the CSRC list accordingly, and that the SRS 867 interprets the CSRC list appropriately when received. 869 7.6. SDES 871 The Source Description (SDES), as defined in [RFC3550], contains an 872 SSRC/CSRC identifier followed by a list of zero or more items, which 873 carry information about the SSRC/CSRC. End systems send one SDES 874 packet containing their own source identifier (the same as the SSRC 875 in the fixed RTP header). A mixer sends one SDES packet containing a 876 chunk for each contributing source from which it is receiving SDES 877 information, or multiple complete SDES packets if there are more than 878 31 such sources. 880 7.6.1. CNAME 882 The Canonical End-Point Identifier (CNAME), as defined in [RFC3550], 883 provides the binding from the SSRC identifier to an identifier for 884 the source (sender or receiver) that remains constant. It is 885 important the an SRC and SRS generate CNAMEs appropriately and use 886 them for this purpose. Guidelines for generating CNAME values are 887 provided in "Guidelines for Choosing RTP Control Protocol (RTCP) 888 Canonical Names (CNAMEs)" [RFC6222]. 890 7.7. Keepalive 892 It is anticipated that media streams in SIPREC may exist in inactive 893 states for extended periods of times for any number of valid reasons. 894 In order for the bindings and any pinholes in NATs/firewalls to 895 remain active during such intervals, it is RECOMMENDED to follow the 896 keep-alive procedure recommended in "Application Mechanism for 897 Keeping Alive the NAT Mappings Associated to RTP/RTP Control Protocol 898 (RTCP) Flows" [RFC6263] for all RTP media streams. 900 7.8. RTCP Feedback Messages 902 "Codec Control Messages in the RTP Audio-Visual Profile with Feedback 903 (AVPF)" [RFC5104] specifies extensions to the messages defined in 904 AVPF [RFC4585]. Support for and proper usage of these messages is 905 important to SRC and SRS implementations. Note that these messages 906 are applicable only when using the AVFP or SAVPF RTP profiles. 908 7.8.1. Full Intra Request 910 A Full Intra Request (FIR) Command, when received by the designated 911 media sender, requires that the media sender sends a Decoder Refresh 912 Point at the earliest opportunity. Using a decoder refresh point 913 implies refraining from using any picture sent prior to that point as 914 a reference for the encoding process of any subsequent picture sent 915 in the stream. 917 Decoder refresh points, especially Intra or IDR pictures for H.264 918 video codecs, are in general several times larger in size than 919 predicted pictures. Thus, in scenarios in which the available bit 920 rate is small, the use of a decoder refresh point implies a delay 921 that is significantly longer than the typical picture duration. 923 7.8.1.1. SIP INFO for FIR 925 "XML Schema for Media Control" [RFC5168] defines an Extensible Markup 926 Language (XML) Schema for video fast update. Implementations are 927 discouraged from using the method described except for backward 928 compatibility purposes. Implementations SHOULD use FIR messages 929 instead. 931 7.8.2. Picture Loss Indicator 933 Picture Loss Indication (PLI), as defined in [RFC4585], informs the 934 encoder of the loss of an undefined amount of coded video data 935 belonging to one or more pictures. Using the FIR command to recover 936 from errors is explicitly disallowed, and instead the PLI message 937 SHOULD be used. FIR SHOULD be used only in situations where not 938 sending a decoder refresh point would render the video unusable for 939 the users. Examples where sending FIR is appropriate include a 940 multipoint conference when a new user joins the conference and no 941 regular decoder refresh point interval is established, and a video 942 switching MCU that changes streams. 944 7.8.3. Temporary Maximum Media Stream Bit Rate Request 946 A receiver, translator, or mixer uses the Temporary Maximum Media 947 Stream Bit Rate Request (TMMBR) to request a sender to limit the 948 maximum bit rate for a media stream to the provided value. 949 Appropriate use of TMMBR facilitates rapid adaptation to changes in 950 available bandwidth. 952 7.8.3.1. Renegotiation of SDP bandwidth attribute 954 If it is likely that the new value indicated by TMMBR will be valid 955 for the remainder of the session, the TMMBR sender is expected to 956 perform a renegotiation of the session upper limit using the session 957 signaling protocol. Therefore for SIPREC, implementations are 958 RECOMMENDED to use TMMBR for temporary changes, and renegotiation of 959 bandwidth via SDP offer/answer for more permanent changes. 961 7.9. Symmetric RTP/RTCP for Sending and Receiving 963 Within an SDP offer/answer exchange, RTP entities choose the RTP and 964 RTCP transport addresses (i.e., IP addresses and port numbers) on 965 which to receive packets. When sending packets, the RTP entities may 966 use the same source port or a different source port as those signaled 967 for receiving packets. When the transport address used to send and 968 receive RTP is the same, it is termed "symmetric RTP" [RFC4961]. 969 Likewise, when the transport address used to send and receive RTCP is 970 the same, it is termed "symmetric RTCP" [RFC4961]. 972 When sending RTP, it is REQUIRED to use symmetric RTP. When sending 973 RTCP, it is REQUIRED to use symmetric RTCP. Although an SRS will not 974 normally send RTP, it will send RTCP as well as receive RTP and RTCP. 975 Likewise, although an SRC will not normally receive RTP from the SRS, 976 it will receive RTCP as well as send RTP and RTCP. 978 Note: Symmetric RTP and symmetric RTCP are different from RTP/RTCP 979 multiplexing [RFC5761]. 981 8. Metadata 982 8.1. Procedures at the SRC 984 The SRC MUST deliver metadata to the SRS in a recording session; the 985 timing of which SRC sends the metadata depends on when the metadata 986 becomes available. Metadata SHOULD be provided by the SRC in the 987 initial INVITE request when establishing the recording session, and 988 subsequent metadata updates can be provided by the SRC in reINVITE 989 and UPDATE requests ([RFC3311]) and responses in the recording 990 session. There are cases that metadata is not available in the 991 initial INVITE request sent by the SRC, for example, when a recording 992 session is established in the absence of a communication session, and 993 the SRC would update the recording session with metadata whenever 994 metdata becomes available. 996 Certain metadata attributes are contained in the SDP, and others are 997 contained in a new content type "application/rs-metadata". The 998 format of the metadata is described as part of the mechanism in 999 [I-D.ietf-siprec-metadata]. A new "disposition-type" of Content- 1000 Disposition is defined for the purpose of carrying metadata and the 1001 value is "recording-session". The "recording-session" value 1002 indicates that the "application/rs-metadata" content contains 1003 metadata to be handled by the SRS, and the disposition can be carried 1004 in either INVITE or UPDATE requests or responses sent by the SRC. 1006 Metadata sent by the SRC can be categorized as either a full metadata 1007 snapshot or partial update. A full metadata snapshot describes all 1008 the recorded streams and all metadata associated with the recording 1009 session. When the SRC sends a full metadata snapshot, the SRC MUST 1010 send an INVITE or an UPDATE request ([RFC3311]) with an SDP offer and 1011 the "recording-session" disposition. A partial update represents an 1012 incremental update since the last metadata update sent by the SRC. A 1013 partial update sent by the SRC can be an INVITE request or response 1014 with an SDP offer, or an INVITE/UPDATE request or response containing 1015 a "recording-session" disposition, or an INVITE request containing 1016 both an SDP offer and the "recording-session" disposition. 1018 The following is an example of a full metadata snapshot sent by the 1019 SRC in the initial INVITE request: 1021 INVITE sip:recorder@example.com SIP/2.0 1022 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 1023 From: ;tag=35e195d2-947d-4585-946f-098392474 1024 To: 1025 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1026 CSeq: 101 INVITE 1027 Max-Forwards: 70 1028 Require: siprec 1029 Accept: application/sdp, application/rs-metadata, 1030 application/rs-metadata-request 1031 Contact: ;+sip.src 1032 Content-Type: multipart/mixed;boundary=foobar 1033 Content-Length: [length] 1035 --foobar 1036 Content-Type: application/sdp 1038 v=0 1039 o=SRS 2890844526 2890844526 IN IP4 198.51.100.1 1040 s=- 1041 c=IN IP4 198.51.100.1 1042 t=0 0 1043 m=audio 12240 RTP/AVP 0 4 8 1044 a=sendonly 1045 a=label:1 1047 --foobar 1048 Content-Type: application/rs-metadata 1049 Content-Disposition: recording-session 1051 [metadata content] 1053 Figure 9: Sample INVITE request for the recording session 1055 8.2. Procedures at the SRS 1057 The SRS receives metadata updates from the SRC in INVITE and UPDATE 1058 requests. Since the SRC can send partial updates based on the 1059 previous update, the SRS needs to keep track of the sequence of 1060 updates from the SRC. 1062 In the case of an internal failure at the SRS, the SRS may fail to 1063 recognize a partial update from the SRC. The SRS may be able to 1064 recover from the internal failure by requesting for a full metadata 1065 snapshot from the SRC. Certain errors, such as syntax errors or 1066 semantic errors in the metadata information, are likely caused by an 1067 error on the SRC side, and it is likely the same error will occur 1068 again even when a full metadata snapshot is requested. In order to 1069 avoid repeating the same error, the SRS can simply terminate the 1070 recording session when a syntax error or semantic error is detected 1071 in the metadata. 1073 When the SRS explicitly requests for a full metadata snapshot, the 1074 SRS MUST send an UPDATE request without an SDP offer. A metadata 1075 snapshot request contains a content with the content disposition type 1076 "recording-session". Note that the SRS MAY generate an INVITE 1077 request without an SDP offer but this MUST not include a metadata 1078 snapshot request. The format of the content is "application/ 1079 rs-metadata-request", and the body format is chosen to be a simple 1080 text-based format. The following shows an example: 1082 UPDATE sip:2000@src.exmaple.com SIP/2.0 1083 Via: SIP/2.0/UDP srs.example.com;branch=z9hG4bKdf6b622b648d9 1084 To: ;tag=35e195d2-947d-4585-946f-098392474 1085 From: ;tag=1234567890 1086 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1087 CSeq: 1 UPDATE 1088 Max-Forwards: 70 1089 Require: siprec 1090 Contact: ;+sip.srs 1091 Accept: appliation/sdp, application/rs-metadata 1092 Content-Disposition: recording-session 1093 Content-Type: application/rs-metadata-request 1094 Content-Length: [length] 1096 SRS internal error 1098 Figure 10: Metadata Request 1100 The SRS MAY include the reason why a metadata snapshot request is 1101 being made to the SRC in the reason line. This reason line is free 1102 form text, mainly designed for logging purposes on the SRC side. The 1103 processing of the content by the SRC is entirely optional since the 1104 content is for logging only, and the snapshot request itself is 1105 indicated by the use of the application/rs-metadata-request content 1106 type. 1108 When the SRC receives the request for a metadata snapshot, the SRC 1109 MUST provide a full metadata snapshot in a separate INVITE or UPDATE 1110 transaction, along with an SDP offer. All subsequent metadata 1111 updates sent by the SRC MUST be based on the new metadata snapshot. 1113 8.2.1. Formal Syntax 1115 The formal syntax for the application/rs-metadata-request MIME is 1116 described below using the augmented Backus-Naur Form (BNF) as 1117 described in [RFC2234]. 1119 snapshot-request = srs-reason-line CRLF 1121 srs-reason-line = [TEXT-UTF8-TRIM] 1123 9. Persistent Recording 1125 Persistent recording is a specific use case outlined in REQ-005 or 1126 Use Case 4 in [RFC6341], where a recording session can be established 1127 in the absence of a communication session. The SRC continuously 1128 records media in a recording session to the SRS even in the absence 1129 of a CS for all user agents that are part of persistent recording. 1130 By allocating recorded streams and continuously sending recorded 1131 media to the SRS, the SRC does not have to prepare new recorded 1132 streams with new SDP offer when a new communication session is 1133 created and also does not impact the timing of the CS. The SRC only 1134 needs to update the metadata when new communication sessions are 1135 created. 1137 When there is no communication sessions running on the devices with 1138 persistent recording, there is no recorded media to stream from the 1139 SRC to the SRS. In certain environments where Network Address 1140 Translator (NAT) is used, typically a minimum of flow activity is 1141 required to maintain the NAT binding for each port opened. Agents 1142 that support Interactive Connectivity Establishment (ICE) solves this 1143 problem. For non-ICE agents, in order not to lose the NAT bindings 1144 for the RTP/RTCP ports opened for the recorded streams, the SRC and 1145 SRS SHOULD follow the recommendations provided in [RFC6263] to 1146 maintain the NAT bindings. 1148 10. Extensions for Recording-aware User Agents 1150 The following sections describe the SIP and SDP extensions for 1151 recording-aware user agents. A recording-aware user agent is a 1152 participant in the CS that supports the SIP and SDP extensions for 1153 receiving recording indication and for requesting recording 1154 preferences for the call. 1156 10.1. Procedures at the record-aware user agent 1158 A recording-aware UA MUST indicate that it can accept reporting of 1159 recording indication provided by the SRC with a new option tag 1160 "record-aware" when initiating or establishing a CS, meaning 1161 including the "record-aware" tag in the Supported header in the 1162 initial INVITE request or response. A recording-aware UA that has 1163 indicated recording awareness MUST provide at recording indication to 1164 the end user through an appropriate user interface an indication 1165 whether recording is on or off for a given medium based on the most 1166 recently received a=record SDP attribute for that medium. 1168 Some user agents that are automatons (eg. IVR, media server, PSTN 1169 gateway) may not have a user interface to render recording 1170 indication. When such user agent indicates recording awareness, the 1171 UA SHOULD render recording indication through other means, such as 1172 passing an inband tone on the PSTN gateway, putting the recording 1173 indication in a log file, or raising an application event in a 1174 VoiceXML dialog. These user agents MAY also choose not to indicate 1175 recording awareness, thereby relying on whatever mechanism an SRC 1176 chooses to indicate recording, such as playing a tone inband. 1178 10.1.1. Recording preference 1180 A participant in a CS MAY set the recording preference in the CS to 1181 be recorded or not recorded at session establishment or during the 1182 session. The recording-aware UA sets the indication of recording 1183 preference in a new SDP attribute a=recordpref in the CS in any SDP 1184 offer/answer. This indication of recording preference can be sent at 1185 session establishment time or during the session. The SRC is not 1186 required to honor the recording preference from a participant based 1187 on local policies at the SRC; the partcipant gets the recording 1188 indication through the a=record SDP attribute described in the next 1189 section. 1191 The SDP a=recordpref attribute can appear at the media level or 1192 session level and can appear in an SDP offer or answer. When the 1193 attribute is applied at the session level, the recording preference 1194 applies to all media stream in the SDP. When the attribute is 1195 applied at the media level, the recording preference applies to the 1196 media stream only, and that overrides the recording preference if 1197 also set at the session level. The user agent can change the 1198 recording preference by changing the a=recordpref attribute in 1199 subsequent SDP offer or answer. If the a=recordpref attribute is 1200 omitted, then the recording preference would be assumed to be the 1201 recording preference set in a previous SDP offer or answer. 1203 The following is the ABNF of the recordpref attribute: 1205 attribute /= recordpref-attr 1207 ; attribute defined in RFC 4566 1209 recordpref-attr = "a=recordpref:" pref 1211 pref = "on" / "off" / "pause" / "nopreference" 1213 on Sets the preference to record if it has not already been started. 1214 If the recording is currently paused, the preference is to resume 1215 recording. 1217 off Sets the preference for no recording. If recording has already 1218 been started, then the preference is to stop the recording. 1220 pause If the recording is currently in progress, sets the preference 1221 to pause the recording. 1223 nopreference To indicate that the UA has no preference on recording. 1225 10.2. Procedures at the SRC 1227 The SRC MUST provide recording indication to all participants in the 1228 CS. When a UA has indicated that it is recording-aware through the 1229 "record-aware" option tag, the SRC MUST provide recording indications 1230 in the new SDP a=record attribute described in the following section. 1231 In the absence of the "record-aware" option tag, meaning that the UA 1232 is not recording-aware, an SRC MUST provide recording indications 1233 through other means such as playing a tone inband, if the SRC is 1234 required to do so (eg. based on policies). 1236 10.2.1. Recording indication 1238 While there are existing mechanisms for providing an indication that 1239 a CS is being recorded, these mechanisms are usually delivered on the 1240 CS media streams such as playing an in-band tone or an announcement 1241 to the participants. A new SDP attribute is introduced to allow a 1242 recording-aware UA to render recording indication at the user 1243 interface. 1245 The 'record' SDP attribute appears at the media level or session 1246 level in either SDP offer or answer. When the attribute is applied 1247 at the session level, the indication applies to all media streams in 1248 the SDP. When the attribute is applied at the media level, the 1249 indication applies to the media stream only, and that overrides the 1250 indication if also set at the session level. Whenever the recording 1251 indication needs to change, such as termination of recording, then 1252 the SRC MUST initiate a reINVITE or UPDATE to update the SDP a=record 1253 attribute. 1255 The following is the ABNF of the 'record' attribute: 1257 attribute /= record-attr 1259 ; attribute defined in RFC 4566 1261 record-attr = "record:" indication 1263 indication = "on" / "off" / "paused" 1265 on Recording is in progress. 1267 off No recording is in progress. 1269 paused Recording is in progress by media is paused. 1271 If a call is traversed through one or more SIP B2BUA, and it happens 1272 that there are more than one SRC in the call path, the recording 1273 indication attribute does not provide any hint as to which SRC is 1274 performing the recording, meaning the endpoint only knows that the 1275 call is being recorded. This attribute is also not used as an 1276 indication to negotiate which SRC in the call path will perform 1277 recording and is not used as a request to start/stop recording if 1278 there are multiple SRCs in the call path. 1280 10.2.2. Recording preference 1282 When the SRC receives the a=recordpref SDP in an SDP offer or answer, 1283 the SRC chooses to honor the preference to record based on local 1284 policy at the SRC. When the SRC honors the preference, the SRC MUST 1285 also update the a=record attribute to indicate the current state of 1286 the recording (on/off/paused). 1288 11. IANA Considerations 1290 11.1. Registration of Option Tags 1292 This specification registers two option tags. The required 1293 information for this registration, as specified in [RFC3261], is as 1294 follows. 1296 11.1.1. siprec Option Tag 1297 Name: siprec 1299 Description: This option tag is for identifying the SIP session 1300 for the purpose of recording session only. This is typically not 1301 used in a Supported header. When present in a Require header in a 1302 request, it indicates that the UAS MUST be either a SRC or SRS 1303 capable of handling the contexts of a recording session. 1305 11.1.2. record-aware Option Tag 1307 Name: record-aware 1309 Description: This option tag is to indicate the ability for the 1310 user agent to receive recording indicators in media level or 1311 session level SDP. When present in a Supported header, it 1312 indicates that the UA can receive recording indicators in media 1313 level or session level SDP. 1315 11.2. Registration of media feature tags 1317 This document registers two new media feature tags in the SIP tree 1318 per the process defined in [RFC2506] and [RFC3840] 1320 11.2.1. src feature tag 1322 Media feature tag name: sip.src 1324 ASN.1 Identifier: 25 1326 Summary of the media feature indicated by this tag: This feature 1327 tag indicates that the user agent is a Session Recording Client 1328 for the purpose for Recording Session. 1330 Values appropriate for use with this feature tag: boolean 1332 The feature tag is intended primarily for use in the following 1333 applications, protocols, services, or negotiation mechanisms: This 1334 feature tag is only useful for a Recording Session. 1336 Examples of typical use: Routing the request to a Session 1337 Recording Server. 1339 Security Considerations: Security considerations for this media 1340 feature tag are discussed in Section 11.1 of RFC 3840. 1342 11.2.2. srs feature tag 1344 Media feature tag name: sip.srs 1346 ASN.1 Identifier: 26 1348 Summary of the media feature indicated by this tag: This feature 1349 tag indicates that the user agent is a Session Recording Server 1350 for the purpose for Recording Session. 1352 Values appropriate for use with this feature tag: boolean 1354 The feature tag is intended primarily for use in the following 1355 applications, protocols, services, or negotiation mechanisms: This 1356 feature tag is only useful for a Recording Session. 1358 Examples of typical use: Routing the request to a Session 1359 Recording Client. 1361 Security Considerations: Security considerations for this media 1362 feature tag are discussed in Section 11.1 of RFC 3840. 1364 11.3. New Content-Disposition Parameter Registrations 1366 This document registers a new "disposition-type" value in Content- 1367 Disposition header: recording-session. 1369 recording-session the body describes the metadata information about 1370 the recording session 1372 11.4. Media Type Registration 1374 11.4.1. Registration of MIME Type application/rs-metadata 1376 This document registers the application/rs-metadata MIME media type 1377 in order to describe the recording session metadata. This media type 1378 is defined by the following information: 1380 Media type name: application 1382 Media subtype name: rs-metadata 1384 Required parameters: none 1386 Options parameters: none 1388 11.4.2. Registration of MIME Type application/rs-metadata-request 1390 This document registers the application/rs-metadata-request MIME 1391 media type in order to describe a recording session metadata snapshot 1392 request. This media type is defined by the following information: 1394 Media type name: application 1396 Media subtype name: rs-metadata-request 1398 Required parameters: none 1400 Options parameters: none 1402 11.5. SDP Attributes 1404 This document registers the following new SDP attributes. 1406 11.5.1. 'record' SDP Attribute 1408 Contact names: Leon Portman leon.portman@nice.com, Henry Lum 1409 henry.lum@genesyslab.com 1411 Attribute name: record 1413 Long form attribute name: Recording Indication 1415 Type of attribute: session or media level 1417 Subject to charset: no 1419 This attribute provides the recording indication for the session or 1420 media stream. 1422 Allowed attribute values: on, off, paused 1424 11.5.2. 'recordpref' SDP Attribute 1426 Contact names: Leon Portman leon.portman@nice.com, Henry Lum 1427 henry.lum@genesyslab.com 1429 Attribute name: recordpref 1431 Long form attribute name: Recording Preference 1433 Type of attribute: session or media level 1435 Subject to charset: no 1436 This attribute provides the recording preference for the session or 1437 media stream. 1439 Allowed attribute values: on, off, pause, nopreference 1441 12. Security Considerations 1443 The recording session is fundamentally a standard SIP dialog 1444 [RFC3261], therefore, the recording session can reuse any of the 1445 existing SIP security mechanism available for securing the recorded 1446 media as well as metadata. Other security considerations are 1447 outlined in the use cases and requirements document [RFC6341]. 1449 12.1. RTP handling 1451 In many scenarios it will be critical that the media transported 1452 between the SRC and SRS to be protected. Media encryption is an 1453 important element in the overall SIPREC solution, therefore, it is 1454 RECOMMENDED that SRC and SRS support RTP/SAVP [RFC3711] and RTP/SAVPF 1455 [RFC5124]. RTP/SAVP and RTP/SAVPF provide media encryption, 1456 integrity protection, replay protection, and a limited form of source 1457 authentication. They do not contain or require a specific keying 1458 mechanism. 1460 12.2. Authentication and Authorization 1462 The recording session reuses the SIP mechanism to challenge requests 1463 that is based on HTTP authentication. The mechanism relies on 401 1464 and 407 SIP responses as well as other SIP header fields for carrying 1465 challenges and credentials. 1467 The SRS may have its own set of recording policies to authorize 1468 recording requests from the SRC. The use of recording policies is 1469 outside the scope of the Session Recording Protocol. 1471 13. Acknowledgements 1473 We want to thank John Elwell, Paul Kyzivat, Partharsarathi R, Ram 1474 Mohan R, Charles Eckel, Hadriel Kaplan, Adam Roach, Miguel Garcia, 1475 Thomas Stach for their valuable comments and inputs to this document. 1477 We also want to thank Andrew Hutton, Ram Mohan, Muthu Perumal, John 1478 Elwell, Dan Wing, Hadriel Kaplan, Paul Kyzivat, and Magnus Westerlund 1479 for their valuable contributions to the RTP Handling portion. 1481 14. References 1483 14.1. Normative References 1485 [I-D.ietf-siprec-metadata] 1486 R, R., Ravindran, P., and P. Kyzivat, "Session Initiation 1487 Protocol (SIP) Recording Metadata", 1488 draft-ietf-siprec-metadata-06 (work in progress), 1489 March 2012. 1491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1492 Requirement Levels", BCP 14, RFC 2119, March 1997. 1494 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1495 Specifications: ABNF", RFC 2234, November 1997. 1497 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 1498 Registration Procedure", BCP 31, RFC 2506, March 1999. 1500 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 1501 May 2000. 1503 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1504 A., Peterson, J., Sparks, R., Handley, M., and E. 1505 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1506 June 2002. 1508 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1509 with Session Description Protocol (SDP)", RFC 3264, 1510 June 2002. 1512 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1513 "Indicating User Agent Capabilities in the Session 1514 Initiation Protocol (SIP)", RFC 3840, August 2004. 1516 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1517 Preferences for the Session Initiation Protocol (SIP)", 1518 RFC 3841, August 2004. 1520 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1521 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 1523 [RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use 1524 Cases and Requirements for SIP-Based Media Recording 1525 (SIPREC)", RFC 6341, August 2011. 1527 14.2. Informative References 1529 [I-D.ietf-siprec-architecture] 1530 Hutton, A., Portman, L., Jain, R., and K. Rehor, "An 1531 Architecture for Media Recording using the Session 1532 Initiation Protocol", draft-ietf-siprec-architecture-05 1533 (work in progress), May 2012. 1535 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1536 UPDATE Method", RFC 3311, October 2002. 1538 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1539 Jacobson, "RTP: A Transport Protocol for Real-Time 1540 Applications", STD 64, RFC 3550, July 2003. 1542 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1543 Video Conferences with Minimal Control", STD 65, RFC 3551, 1544 July 2003. 1546 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1547 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1548 RFC 3711, March 2004. 1550 [RFC4508] Levin, O. and A. Johnston, "Conveying Feature Tags with 1551 the Session Initiation Protocol (SIP) REFER Method", 1552 RFC 4508, May 2006. 1554 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 1555 (SIP) Call Control - Conferencing for User Agents", 1556 BCP 119, RFC 4579, August 2006. 1558 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1559 "Extended RTP Profile for Real-time Transport Control 1560 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1561 July 2006. 1563 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 1564 BCP 131, RFC 4961, July 2007. 1566 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 1567 "Codec Control Messages in the RTP Audio-Visual Profile 1568 with Feedback (AVPF)", RFC 5104, February 2008. 1570 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 1571 Real-time Transport Control Protocol (RTCP)-Based Feedback 1572 (RTP/SAVPF)", RFC 5124, February 2008. 1574 [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for 1575 Media Control", RFC 5168, March 2008. 1577 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1578 Control Packets on a Single Port", RFC 5761, April 2010. 1580 [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for 1581 Choosing RTP Control Protocol (RTCP) Canonical Names 1582 (CNAMEs)", RFC 6222, April 2011. 1584 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 1585 Keeping Alive the NAT Mappings Associated with RTP / RTP 1586 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 1588 Authors' Addresses 1590 Leon Portman 1591 NICE Systems 1592 8 Hapnina 1593 Ra'anana 43017 1594 Israel 1596 Email: leon.portman@nice.com 1598 Henry Lum (editor) 1599 Genesys 1600 1380 Rodick Road, Suite 201 1601 Markham, Ontario L3R4G5 1602 Canada 1604 Email: henry.lum@genesyslab.com 1606 Charles Eckel 1607 Cisco 1608 170 West Tasman Drive 1609 San Jose, CA 95134 1610 United States 1612 Email: eckelcu@cisco.com 1613 Alan Johnston 1614 Avaya 1615 St. Louis, MO 63124 1617 Email: alan.b.johnston@gmail.com 1619 Andrew Hutton 1620 Siemens Enterprise Communications 1621 Brickhill Street 1622 Milton Keynes MK15 0DJ 1623 United Kingdom 1625 Email: andrew.hutton@siemens-enterprise.com