idnits 2.17.1 draft-ietf-siprec-protocol-01.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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. -- The document date (October 26, 2011) is 4560 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 620, but not defined == Unused Reference: 'RFC2119' is defined on line 987, but no explicit reference was found in the text == Unused Reference: 'RFC2804' is defined on line 996, but no explicit reference was found in the text == Unused Reference: 'RFC4508' is defined on line 1036, but no explicit reference was found in the text == Unused Reference: 'RFC4579' is defined on line 1040, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-siprec-metadata-04 ** 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 (-03) exists of draft-eckel-siprec-rtp-rec-02 == Outdated reference: A later version (-12) exists of draft-ietf-siprec-architecture-03 Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPREC L. Portman, Ed. 3 Internet-Draft NICE Systems 4 Intended status: Standards Track H. Lum, Ed. 5 Expires: April 28, 2012 Genesys, Alcatel-Lucent 6 A. Johnston 7 Avaya 8 A. Hutton 9 Siemens Enterprise 10 Communications 11 October 26, 2011 13 Session Recording Protocol 14 draft-ietf-siprec-protocol-01 16 Abstract 18 This document specifies the use of the Session Initiation Protocol 19 (SIP), the Session Description Protocol (SDP), and the Real Time 20 Protocol (RTP) for delivering real-time media and metadata from a 21 communication session to a recording device. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 28, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Overview of operations . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Delivering recorded media . . . . . . . . . . . . . . . . 5 62 4.2. Delivering recording metadata . . . . . . . . . . . . . . 7 63 5. Initiating a Recording Session . . . . . . . . . . . . . . . . 8 64 5.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 8 65 5.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 9 66 6. SDP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 6.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 10 68 6.1.1. Handling media stream updates . . . . . . . . . . . . 11 69 6.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 12 70 7. RTP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 8. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 8.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 13 73 8.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 14 74 8.2.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . 16 75 9. Persistent Recording . . . . . . . . . . . . . . . . . . . . . 16 76 10. Extensions for Recording-aware User Agents . . . . . . . . . . 16 77 10.1. Procedures at the record-aware user agent . . . . . . . . 17 78 10.1.1. Recording preference . . . . . . . . . . . . . . . . . 17 79 10.2. Procedures at the SRC . . . . . . . . . . . . . . . . . . 18 80 10.2.1. Recording indication . . . . . . . . . . . . . . . . . 18 81 10.2.2. Recording preference . . . . . . . . . . . . . . . . . 20 82 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 83 11.1. Registration of Option Tags . . . . . . . . . . . . . . . 20 84 11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . . 20 85 11.1.2. record-aware Option Tag . . . . . . . . . . . . . . . 20 86 11.2. Registration of media feature tags . . . . . . . . . . . . 20 87 11.2.1. src feature tag . . . . . . . . . . . . . . . . . . . 20 88 11.2.2. srs feature tag . . . . . . . . . . . . . . . . . . . 21 89 11.3. New Content-Disposition Parameter Registrations . . . . . 21 90 11.4. Media Type Registration . . . . . . . . . . . . . . . . . 22 91 11.4.1. Registration of MIME Type application/rs-metadata . . 22 92 11.4.2. Registration of MIME Type 93 application/rs-metadata-request . . . . . . . . . . . 22 94 11.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 22 95 11.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . . 22 96 11.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . . 23 97 12. Security Considerations . . . . . . . . . . . . . . . . . . . 23 98 12.1. Authentication and Authorization . . . . . . . . . . . . . 23 99 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 100 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 101 14.1. Normative References . . . . . . . . . . . . . . . . . . . 24 102 14.2. Informative References . . . . . . . . . . . . . . . . . . 25 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 105 1. Introduction 107 This document specifies the mechanism to record a Communication 108 Session (CS) by delivering real-time media and metadata from the CS 109 to a recording device. In accordance to the architecture 110 [I-D.ietf-siprec-architecture], the Session Recording Protocol 111 specifies the use of SIP, SDP, and RTP to establish a Recording 112 Session (RS) from the Session Recording Client (SRC), which is on the 113 path of the CS, to a Session Recording Server (SRS) at the recording 114 device. 116 SIP is also used to deliver metadata to the recording device, as 117 specified in [I-D.ietf-siprec-metadata]. 119 The Session Recording Protocol intends to satisfy the SIP-based Media 120 Recording requirements listed in [RFC6341]. 122 2. Definitions 124 This document refers to the core definitions provided in the 125 architecture document [I-D.ietf-siprec-architecture]. 127 3. Scope 129 The scope of the Session Recording Protocol includes the 130 establishment of the recording sessions and the reporting of the 131 metadata. The scope also includes extensions supported by User 132 Agents participating in the CS such as indication of recording. The 133 user agents need not be recording-aware in order to participate in a 134 CS being recorded. 136 The following items, which are not an exhaustive list, do not 137 represent the protocol itself and are considered out of the scope of 138 the Session Recording Protocol: 140 o Delivering recorded media in real-time as the CS media 142 o Specifications of criteria to select specific CS to be recorded or 143 triggers to record certain CS in the future 145 o Recording policies that determine whether the CS should be 146 recorded and whether parts of the CS are to be recorded 148 o Retention policies that determine how long a recording is stored 149 o Searching and accessing the recorded media and metadata 151 o Policies governing how CS users are made aware of recording 153 o Delivering additional recording session metadata through non-SIP 154 mechanism 156 4. Overview of operations 158 This section is informative and provides a description of recording 159 operations. 161 As mentioned in the architecture document 162 [I-D.ietf-siprec-architecture], there are a couple of types of call 163 flows based on the location of the Session Recording Client. The 164 following sample call flows provide a quick overview of the 165 operations between the SRC and the SRS. 167 4.1. Delivering recorded media 169 When a B2BUA with SRC functionality routes a call from UA(A) to 170 UA(B), the SRC has access to the media path between the user agents. 171 When the SRC is aware that it should be recording the conversation, 172 the SRC can cause the B2BUA to bridge the media between UA(A) and 173 UA(B). The SRC then establishes the Recording Session with the SRS 174 and sends replicated media towards the SRS. 176 An endpoint may also have SRC functionality, where the endpoint 177 itself establishes the Recording Session to the SRS. Since the 178 endpoint has access to the media in the Communication Session, the 179 endpoint can send replicated media towards the SRS. 181 The following is a sample call flow that shows the SRC establishing a 182 recording session towards the SRS. The call flow is essentially 183 identical when the SRC is a B2BUA or as the endpoint itself. Note 184 that the SRC can choose when to establish the Recording Session 185 independent of the Communication Session, even though the following 186 call flow suggests that the SRC is establishing the Recording Session 187 (message #5) after the Communication Session is established. 189 UA A SRC UA B SRS 190 |(1)CS INVITE | | | 191 |------------->| | | 192 | |(2)CS INVITE | | 193 | |---------------------->| | 194 | | (3)OK | | 195 | |<----------------------| | 196 | (4)OK | | | 197 |<-------------| | | 198 | |(5)RS INVITE with SDP | | 199 | |--------------------------------------------->| 200 | | | (6)OK with SDP | 201 | |<---------------------------------------------| 202 |(7)CS RTP | | | 203 |=============>|======================>| | 204 |<=============|<======================| | 205 | |(8)RS RTP | | 206 | |=============================================>| 207 | |=============================================>| 208 |(9)CS BYE | | | 209 |------------->| | | 210 | |(10)CS BYE | | 211 | |---------------------->| | 212 | |(11)RS BYE | | 213 | |--------------------------------------------->| 214 | | | | 216 Figure 1: Basic Recording Call flow 218 The above call flow can also apply to the case of a centralized 219 conference with a mixer. The conference focus can provide the SRC 220 functionality since the conference focus has access to all the media 221 from each conference participant. When a recording is requested, the 222 SRC delivers the metadata and the media streams to the SRS. Since 223 the conference focus has access to a mixer, the SRC may choose to mix 224 the media streams from all participants as a single mixed media 225 stream towards the SRS. 227 An SRC can use a single recording session to record multiple 228 communication sessions. Every time the SRC wants record a new call, 229 the SRC updates the recording session with a new SDP offer to add new 230 recorded streams to the recording session, and correspondingly also 231 update the metadata for the new call. 233 4.2. Delivering recording metadata 235 The SRC is responsible to deliver metadata to the SRS. The SRC may 236 provide an initial metadata snapshot about recorded media streams in 237 the initial INVITE content in the recording session. Subsequent 238 metadata updates can be represented as a stream of events in UPDATE 239 or reINVITE requests sent by the SRC. These metadata updates are 240 normally incremental updates to the initial metadata snapshot to 241 optimize on the size of updates, however, the SRC may also decide to 242 send a new metadata snapshot anytime. 244 Metadata is transported in the body of INVITE or UPDATE messages. 245 Certain metadata, such as the attributes of the recorded media stream 246 are located in the SDP of the recording session. 248 The SRS has the ability to send a request to the SRC to request for a 249 new metadata snapshot update from the SRC. This can happen when the 250 SRS fails to understand the current stream of incremental updates for 251 whatever reason, for example, when SRS loses the current state due to 252 internal failure. The SRS may optionally attach a reason along with 253 the snapshot request. This request allows both SRC and SRS to 254 restart the states with a new metadata snapshot so that further 255 metadata incremental updates will be based on the latest metadata 256 snapshot. Similar to the metadata content, the metadata snapshot 257 request is transported as content in UPDATE or INVITE sent by the SRS 258 in the recording session. 260 SRC SRS 261 | | 262 |(1) INVITE (metadata snapshot) | 263 |---------------------------------------------------->| 264 | (2)200 OK | 265 |<----------------------------------------------------| 266 |(3) ACK | 267 |---------------------------------------------------->| 268 |(4) RTP | 269 |====================================================>| 270 |(5) UPDATE (metadata update 1) | 271 |---------------------------------------------------->| 272 | (6) 200 OK | 273 |<----------------------------------------------------| 274 |(7) UPDATE (metadata update 2) | 275 |---------------------------------------------------->| 276 | (8) 200 OK | 277 |<----------------------------------------------------| 278 | (9) UPDATE (metadata snapshot request) | 279 |<----------------------------------------------------| 280 | (10) 200 OK | 281 |---------------------------------------------------->| 282 | (11) INVITE (metadata snapshot 2 + SDP offer) | 283 |---------------------------------------------------->| 284 | (12) 200 OK (SDP answer) | 285 |<----------------------------------------------------| 286 | (13) UPDATE (metadata update 1 based on snapshot 2) | 287 |---------------------------------------------------->| 288 | (14) 200 OK | 289 |<----------------------------------------------------| 291 Figure 3: Delivering metadata via SIP UPDATE 293 5. Initiating a Recording Session 295 5.1. Procedures at the SRC 297 The SRC can initiate a recording session by sending a SIP INVITE 298 request to the SRS. In this case, the From header MUST contain the 299 identity of the SRC, and the To header MUST contain the identity of 300 the SRS. Participants information is not recorded in the From or To 301 header; they are included in the metadata. 303 The SRC MUST include the 'src' feature tag in the Contact URI, as per 304 [RFC3840], for all recording sessions. An SRS uses the presence of 305 the 'src' feature tag in dialog creating and modifying requests and 306 responses to confirm that the dialog being created is for the purpose 307 of a Recording Session. In addition, a registrar could discover that 308 a UA is an SRC based on the presence of this feature tag in a 309 registration. Other SIP Recording extensions and behaviors can be 310 triggered by the presence of this feature tag. 312 To ensure a recording session is redirected to an SRS, an SRC can 313 utilize the SIP Caller Preferences extensions, defined in [RFC3841]. 314 The presence of a Accept-Contact: *;sip.srs allows a UA to request 315 that the INVITE be routed to an SRS. Note that to be completely 316 sure, the SRC would need to include a Require: prefs header field in 317 the request. 319 Since SIP Caller Preferences extensions are optional to implement for 320 routing proxies, there is no guarantee that a recording session will 321 be routed to an SRC or SRS. A new options tag is introduced: 322 "siprec". As per [RFC3261], only an SRC or an SRS can accept this 323 option tag in a recording session. An SRC SHOULD include the 324 "siprec" option tag in the Require header when initiating a Recording 325 Session so that other types of user agents can simply reject the 326 INVITE request with a 420 Bad Extension. 328 5.2. Procedures at the SRS 330 The SRS can initiate a recording session by sending a SIP INVITE 331 request to the SRC. In this case, the From header MUST contain the 332 identity of the SRS, and the To header MUST contain the identity of 333 the SRC. 335 The SRS MUST include the 'srs' feature tag in the Contact URI, as per 336 [RFC3840], for all recording sessions. An SRC uses the presence of 337 this feature tag in dialog creating and modifying requests and 338 responses to confirm that the dialog being created is for the purpose 339 of a Recording Session (REQ-30). In addition, a registrar could 340 discover that a UA is an SRS based on the presence of this feature 341 tag in a registration. Other SIP Recording extensions and behaviors 342 can be triggered by the presence of this feature tag. 344 To ensure a recording session is redirected to an SRC, an SRS can 345 utilize the SIP Caller Preferences extensions, defined in [RFC3841]. 346 The presence of a Accept-Contact: *;sip.src allows a UA to request 347 that the INVITE be routed to an SRC. Note that to be completely 348 sure, the SRS would need to include a Require: prefs header field in 349 the request. 351 An SRS SHOULD include the "siprec" option tag in the Require header 352 as per [RFC3261] when initiating a Recording Session so that other 353 types of user agents can simply reject the INVITE request with a 420 354 Bad Extension. 356 6. SDP Handling 358 The SRC and SRS follows the SDP offer/answer model in [RFC3264]. The 359 rest of this section describes conventions used in a recording 360 session. 362 6.1. Procedures at the SRC 364 Since the SRC does not expect to receive media from the SRS, the SRC 365 typically sets each media stream of the SDP offer to only send media, 366 by qualifying them with the a=sendonly attribute, according to the 367 procedures in [RFC3264]. 369 The SRC sends recorded streams of participants to the SRS, and the 370 SRC MUST provide a label attribute (a=label), as per [RFC4574], on 371 each media stream in order to identify the recorded stream with the 372 rest of the metadata. The a=label attribute identifies each recorded 373 media stream, and the label name is mapped to the Media Stream 374 Reference in the metadata in [I-D.ietf-siprec-metadata]. Note that a 375 recorded stream is different than a CS stream; the metadata provides 376 a list of participants that contributes to each recorded stream. 378 The following is an example of SDP with both audio and video recorded 379 streams. 381 v=0 382 o=SRS 2890844526 2890844526 IN IP4 198.51.100.1 383 s=- 384 c=IN IP4 198.51.100.1 385 t=0 0 386 m=audio 12240 RTP/AVP 0 4 8 387 a=sendonly 388 a=label:1 389 m=video 22456 RTP/AVP 98 390 a=rtpmap:98 H264/90000 391 a=fmtp:98 profile-level-id=42A01E; 392 sprop-parameter-sets=Z0IACpZTBYmI,aMljiA== 393 a=sendonly 394 a=label:2 395 m=audio 12242 RTP/AVP 0 4 8 396 a=sendonly 397 a=label:3 398 m=audio 22458 RTP/AVP 98 399 a=rtpmap:98 H264/90000 400 a=fmtp:98 profile-level-id=42A01E; 401 sprop-parameter-sets=Z0IACpZTBYmI,aMljiA== 402 a=sendonly 403 a=label:4 405 Figure 4: Sample SDP with audio and video streams 407 6.1.1. Handling media stream updates 409 Over the lifetime of a recording session, the SRC can add and remove 410 recorded streams from the recording session for various reasons. For 411 example, when a CS stream is added or removed from the CS, or when a 412 CS is created or terminated if a recording session handles multiple 413 CSes. To remove a recorded stream from the recording session, the 414 SRC sends a new SDP offer where the port of the media stream to be 415 removed is set to zero, according to the procedures in [RFC3264]. To 416 add a recorded stream to the recording session, the SRC sends a new 417 SDP offer by adding a new media stream description or by reusing an 418 old media stream which had been previously disabled, according to the 419 procedures in [RFC3264]. 421 The SRC can temporarily discontinue streaming and collection of 422 recorded media from the SRC to the SRS for reason such as masking the 423 recording. In this case, the SRC sends a new SDP offer and sets the 424 media stream to inactive (a=inactive) for each recorded stream to be 425 paused, as per the procedures in [RFC3264]. To resume streaming and 426 collection of recorded media, the SRC sends a new SDP offer and sets 427 the media streams with a=sendonly attribute. Note that when a CS 428 stream is muted/unmuted, this information is conveyed in the metadata 429 by the SRC. The SRC SHOULD not modify the media stream with 430 a=inactive for mute since this operation is reserved for pausing the 431 RS media. 433 6.2. Procedures at the SRS 435 The SRS only receives RTP streams from the SRC, the SDP answer 436 normally sets each media stream to receive media, by setting them 437 with the a=recvonly attribute, according to the procedures of 438 [RFC3264]. When the SRS is not ready to receive a recorded stream, 439 the SRS sets the media stream as inactive in the SDP offer or answer 440 by setting it with a=inactive attribute, according to the procedures 441 of [RFC3264]. When the SRS is ready to receive recorded streams, the 442 SRS sends a new SDP offer and sets the media streams with a=recvonly 443 attribute. 445 The following sequence diagram shows an example where the SRS is 446 initially not ready to receive recorded streams, and later updates 447 the recording session when the SRS is ready to record. 449 SRC SRS 450 | | 451 |(1) INVITE (SDP offer) | 452 |---------------------------------------------------->| 453 | [not ready to record] 454 | (2)200 OK with SDP inactive | 455 |<----------------------------------------------------| 456 |(3) ACK | 457 |---------------------------------------------------->| 458 | ... | 459 | [ready to record] 460 | (4) re-INVITE with SDP recvonly | 461 |<----------------------------------------------------| 462 |(5)200 OK with SDP sendonly | 463 |---------------------------------------------------->| 464 | (6) ACK | 465 |<----------------------------------------------------| 466 |(7) RTP | 467 |====================================================>| 468 | ... | 469 |(8) BYE | 470 |---------------------------------------------------->| 471 | (9) OK | 472 |<----------------------------------------------------| 474 Figure 5: SRS to offer with a=inactive 476 7. RTP Handling 478 This is a placeholder section to specify any protocol impacts or 479 recommendations for RTP usage in the session recording protocol. The 480 details are listed in [I-D.eckel-siprec-rtp-rec] 482 8. Metadata 484 8.1. Procedures at the SRC 486 The SRC is responsible to deliver metadata to the SRS in a recording 487 session. Metadata can be provided by the SRC in the initial INVITE 488 request when establishing the recording session, and subsequent 489 metadata updates can be provided by the SRC in reINVITE and UPDATE 490 requests and responses in the recording session. 492 Certain metadata attributes are contained in the SDP, and others are 493 contained in a new content type "application/rs-metadata". The 494 format of the metadata is described as part of the mechanism in 495 [I-D.ietf-siprec-metadata]. A new "disposition-type" of Content- 496 Disposition is defined for the purpose of carrying metadata and the 497 value is "recording-session". The "recording-session" value 498 indicates that the "application/rs-metadata" content contains 499 metadata to be handled by the SRS, and the disposition can be carried 500 in either INVITE or UPDATE requests or responses sent by the SRC. 502 Metadata sent by the SRC can be categorized as either a full metadata 503 snapshot or partial update. A full metadata snapshot describes all 504 the recorded streams and all metadata associated with the recording 505 session. When the SRC sends a full metadata snapshot, the SRC MUST 506 send an INVITE request with an SDP offer and the "recording-session" 507 disposition. A partial update represents an incremental update since 508 the last metadata update sent by the SRC. A partial update sent by 509 the SRC can be an INVITE request or response with an SDP offer, or an 510 INVITE/UPDATE request or response containing a "recording-session" 511 disposition, or an INVITE request containing both an SDP offer and 512 the "recording-session" disposition. 514 The following is an example of a full metadata snapshot sent by the 515 SRC in the initial INVITE request: 517 INVITE sip:97753210@10.240.3.10:5060 SIP/2.0 518 From: ;tag=35e195d2-947d-4585-946f-098392474 519 To: 520 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a@10.226.240.3 521 CSeq: 101 INVITE 522 Date: Thu, 26 Nov 2009 02:38:49 GMT 523 Supported: timer 524 Max-Forwards: 70 525 Min-SE: 90 526 Session-Expires: 1800 527 Require: siprec 528 Contact: ;src 529 Via: SIP/2.0/TCP 10.226.240.3:5060;branch=z9hG4bKdf6b622b648d9 530 Content-Type: multipart/mixed;boundary=foobar 531 Content-Length: [length] 533 --foobar 534 Content-Type: application/sdp 536 v=0 537 o=SRS 2890844526 2890844526 IN IP4 198.51.100.1 538 s=- 539 c=IN IP4 198.51.100.1 540 t=0 0 541 m=audio 12240 RTP/AVP 0 4 8 542 a=sendonly 543 a=label:1 545 --foobar 546 Content-Type: application/rs-metadata 547 Content-Disposition: recording-session 549 [metadata content] 551 Figure 6: Sample INVITE request for the recording session 553 8.2. Procedures at the SRS 555 The SRS receives metadata updates from the SRC in INVITE and UPDATE 556 requests. Since the SRC can send partial updates based on the 557 previous update, the SRS needs to keep track of the sequence of 558 updates from the SRC. 560 In the case of an internal failure at the SRS, the SRS may fail to 561 recognize a partial update from the SRC. The SRS may be able to 562 recover from the internal failure by requesting for a full metadata 563 snapshot from the SRC. Certain errors, such syntax errors or 564 semantic errors in the metadata information, are likely caused by an 565 error on the SRC side, and it is likely the same error will occur 566 again even when a full metadata snapshot is requested. In order to 567 avoid repeating the same error, it is RECOMMENDED that the SRS 568 terminate the recording session when a syntax error or semantic error 569 is detected in the metadata. 571 When the SRS requires a full metadata snapshot, the SRS sends a 572 metadata snapshot request to the SRC in an INVITE/UPDATE request or 573 in an INVITE/UPDATE response. The metadata snapshot request is 574 contained the content with the disposition type "recording-session". 575 The format of the content is "application/rs-metadata-request", and 576 the body format is chosen to be a simple text-based format. The 577 following shows an example: 579 UPDATE sip:2000@10.226.240.3:5060 SIP/2.0 580 To: ;tag=35e195d2-947d-4585-946f-098392474 581 From: ;tag=1234567890 582 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a@10.226.240.3 583 CSeq: 1 UPDATE 584 Supported: timer 585 Max-Forwards: 70 586 Min-SE: 90 587 Session-Expires: 1800 588 Require: siprec 589 Contact: ;srs 590 Via: SIP/2.0/UDP 10.240.3.10:5060;branch=z9hG4bKdf6b622b648d9 591 Content-Disposition: recording-session 592 Content-Type: application/rs-metadata-request 593 Content-Length: [length] 595 SRS internal error 597 Figure 7: Metadata Request 599 The SRS MAY include the reason why a metadata snapshot request is 600 being made to the SRC in the reason line. This reason line is free 601 form text, mainly designed for logging purposes on the SRC side. The 602 processing of the content by the SRC is entirely optional since the 603 content is for logging only, and the snapshot request itself is 604 indicated by the use of the application/rs-metadata-request content 605 type. 607 When the SRC receives the request for a metadata snapshot, the SRC 608 MUST provide a full metadata snapshot in a separate INVITE 609 transaction, along with an SDP offer. All subsequent metadata 610 updates sent by the SRC MUST be based on the new metadata snapshot. 612 8.2.1. Formal Syntax 614 The formal syntax for the application/rs-metadata-request MIME is 615 described below using the augmented Backus-Naur Form (BNF) as 616 described in [RFC2234]. 618 snapshot-request = srs-reason-line CRLF 620 srs-reason-line = [TEXT-UTF8-TRIM] 622 9. Persistent Recording 624 Persistent recording is a specific use case outlined in REQ-005 or 625 Use Case 4 in [RFC6341], where a recording session can be established 626 in the absence of a communication session. The SRC continuously 627 sends recorded media to the SRS in the absence of a CS for certain 628 allocated devices; allocated devices can include a specific physical 629 device, a specific person or contact registered, or a set of trunks 630 or ports of a gateway. To continuously record, the SRC adds recorded 631 streams into the recording session for all devices with persistent 632 recording. By allocating recorded streams and continuously sending 633 recorded media to the SRS, the SRC does not have to prepare new 634 recorded streams with new SDP offer when a new communication session 635 is created and also does not impact the timing of the CS. The SRC 636 only needs to update the metadata when new communication sessions are 637 created. 639 When there is no communication sessions running on the devices with 640 persistent recording, there is no recorded media to stream from the 641 SRC to the SRS. In certain environments where Network Address 642 Translator (NAT) is used, typically a minimum of flow activity is 643 required to maintain the NAT binding for each port opened. In order 644 not to lose the NAT bindings for the RTP/RTCP ports opened for the 645 recorded streams, the SRC and SRS SHOULD follow the recommendations 646 provided in [RFC6263] to maintain the NAT bindings. 648 10. Extensions for Recording-aware User Agents 650 The following sections describe the SIP and SDP extensions for 651 recording-aware user agents. 653 10.1. Procedures at the record-aware user agent 655 A recording-aware UA SHOULD indicate that it can accept reporting of 656 recording indication provided by the SRC. A new option tag "record- 657 aware" is introduced to indicate such awareness. The recording-aware 658 UA SHOULD include the "record-aware" option tag in the Supported 659 header when initiating or establishing a CS. A recording-aware UA 660 that has indicated recording awareness MUST provide at recording 661 indication to the end user through an appropriate user interface an 662 indication whether recording is on or off for a given medium based on 663 the most recently received a=record SDP attribute for that medium. 665 Some user agents that are automatons (eg. IVR, media server, PSTN 666 gateway) may not have a user interface to render recording 667 indication. When such user agent indicates recording awareness, the 668 UA SHOULD render recording indication through other means, such as 669 passing an inband tone on the PSTN gateway, putting the recording 670 indication in a log file, or raising an application event in a 671 VoiceXML dialog. These user agents MAY also choose not to indicate 672 recording awareness, thereby relying on whatever mechanism an SRC 673 chooses to indicate recording, such as playing a tone inband. 675 10.1.1. Recording preference 677 A recording-aware UA involved in a CS MAY request the CS to be 678 recorded or not recorded. This indication of recording preference 679 can be sent at session establishment time or during the session. 681 A new SDP attribute "recordpref" is introduced. The SDP attribute 682 appears at the media level and can only appear in an SDP offer. The 683 recording indication applies to the specified media stream only. The 684 following is the ABNF of the recordpref attribute: 686 recordpref-attr = "a=recordpref:" pref 688 pref = "on" / "off" / "pause" / "nopreference" 690 on Request for recording if it has not already been started. If the 691 recording is currently paused, request to resume recording. 693 off Request for no recording. If recording has already been 694 started, then this preference indicates a request to stop 695 recording. 697 pause Request to pause recording if recording is currently in 698 progress. 700 nopreference To indicate that the UA has no preference on recording. 701 While the absence of this attribute indirectly implies the lack of 702 preference, using this value allows the UA to explicitly state no 703 preference to being recorded. 705 10.2. Procedures at the SRC 707 When a UA has indicated that it is recording-aware through the 708 "record-aware" option tag, the SRC MUST provide recording indications 709 in a new SDP attribute described in the following section. In the 710 absence of the "record-aware" option tag, meaning that the UA is not 711 recording-aware, an SRC MUST provide recording indications, where SRC 712 is required to do so based on policies, through other means such as 713 playing a tone inband. 715 10.2.1. Recording indication 717 While there are existing mechanisms for providing an indication that 718 a CS is being recorded, these mechanisms are usually delivered on the 719 CS media streams such as playing an in-band tone or an announcement 720 to the participants. A new SDP attribute is introduced to allow a 721 recording-aware UA to render recording indication at the user 722 interface. 724 The 'record' SDP attribute appears at the media level in either SDP 725 offer or answer. The recording indication applies to the specified 726 media stream only, for example, only the audio portion of the call is 727 recorded in an audio/video call. The following is the ABNF of the 728 'record' attribute: 730 attribute /= record-attr 732 ; attribute defined in RFC 4566 734 record-attr = "record:" indication 736 indication = "on" / "off" / "paused" 738 on Recording is in progress. 740 off No recording is in progress. 742 paused Recording is in progress by media is paused. 744 The recording attribute is a declaration by an endpoint in the CS to 745 indicate whether recording is taking place. For example, if a UA (A) 746 is initiating a call to UA (B) and UA (A) is also an SRC that is 747 performing the recording, then UA (A) provides the recording 748 indication in the SDP offer with a=record:on. When UA (B) receives 749 the SDP offer, UA (B) will see that recording is happening on the 750 other endpoint of this session. If UA (B) does not wish to perform 751 recording itself, UA (B) provides the recording indication as 752 a=record:off in the SDP answer. 754 Whenever the recording indication needs to change, such as 755 termination of recording, then the UA MUST initiate a reINVITE to 756 update the SDP attribute to a=record:off. The following call flow 757 shows an example of the offer/answer with the recording indication 758 attribute. 760 UA A UA B 761 (SRC) | 762 | | 763 | [SRC recording starts] | 764 |(1) INVITE (SDP offer + a=record:on) | 765 |---------------------------------------------------->| 766 | 200 OK (SDP answer + a=record:off) | 767 |<----------------------------------------------------| 768 |(3) ACK | 769 |---------------------------------------------------->| 770 |(4) RTP | 771 |<===================================================>| 772 | [SRC stops recording] | 773 |(5) re-INVITE (SDP + a=record:off) | 774 |---------------------------------------------------->| 775 | (6) 200 OK (SDP + a=record:off)| 776 |<----------------------------------------------------| 777 | (6) ACK | 778 |---------------------------------------------------->| 780 Figure 8: Recording indication example 782 If a call is traversed through one or more SIP B2BUA, and it happens 783 that there are more than one SRC in the call path, the recording 784 indication attribute does not provide any hint as to which SRC is 785 performing the recording, meaning the endpoint only knows that the 786 call is being recorded. This attribute is also not used as an 787 indication to negotiate which SRC in the call path will perform 788 recording and is not used as a request to start/stop recording if 789 there are multiple SRCs in the call path. 791 10.2.2. Recording preference 793 When the SRC receives the a=recordpref SDP in an SDP offer or answer, 794 the SRC MAY choose to honor such request to record the request based 795 on local policy on the SRC. When the SRC honors the request, the SRC 796 MUST also update the recording indication to reflect the current 797 state of the recording (on/off/paused). 799 11. IANA Considerations 801 11.1. Registration of Option Tags 803 This specification registers two option tags. The required 804 information for this registration, as specified in [RFC3261], is as 805 follows. 807 11.1.1. siprec Option Tag 809 Name: siprec 811 Description: This option tag is for identifying the SIP session 812 for the purpose of recording session only. This is typically not 813 used in a Supported header. When present in a Require header in a 814 request, it indicates that the UAS MUST be either a SRC or SRS 815 capable of handling the contexts of a recording session. 817 11.1.2. record-aware Option Tag 819 Name: record-aware 821 Description: This option tag is to indicate the ability for the 822 user agent to receive recording indicators in media level SDP. 823 When present in a Supported header, it indicates that the UA can 824 receive recording indicators in media level SDP. 826 11.2. Registration of media feature tags 828 This document registers two new media feature tags in the SIP tree 829 per the process defined in [RFC2506] and [RFC3840] 831 11.2.1. src feature tag 833 Media feature tag name: sip.src 835 ASN.1 Identifier: 25 836 Summary of the media feature indicated by this tag: This feature 837 tag indicates that the user agent is a Session Recording Client 838 for the purpose for Recording Session. 840 Values appropriate for use with this feature tag: boolean 842 The feature tag is intended primarily for use in the following 843 applications, protocols, services, or negotiation mechanisms: This 844 feature tag is only useful for a Recording Session. 846 Examples of typical use: Routing the request to a Session 847 Recording Server. 849 Security Considerations: Security considerations for this media 850 feature tag are discussed in Section 11.1 of RFC 3840. 852 11.2.2. srs feature tag 854 Media feature tag name: sip.srs 856 ASN.1 Identifier: 26 858 Summary of the media feature indicated by this tag: This feature 859 tag indicates that the user agent is a Session Recording Server 860 for the purpose for Recording Session. 862 Values appropriate for use with this feature tag: boolean 864 The feature tag is intended primarily for use in the following 865 applications, protocols, services, or negotiation mechanisms: This 866 feature tag is only useful for a Recording Session. 868 Examples of typical use: Routing the request to a Session 869 Recording Client. 871 Security Considerations: Security considerations for this media 872 feature tag are discussed in Section 11.1 of RFC 3840. 874 11.3. New Content-Disposition Parameter Registrations 876 This document registers a new "disposition-type" value in Content- 877 Disposition header: recording-session. 879 recording-session the body describes the metadata information about 880 the recording session 882 11.4. Media Type Registration 884 11.4.1. Registration of MIME Type application/rs-metadata 886 This document registers the application/rs-metadata MIME media type 887 in order to describe the recording session metadata. This media type 888 is defined by the following information: 890 Media type name: application 892 Media subtype name: rs-metadata 894 Required parameters: none 896 Options parameters: none 898 11.4.2. Registration of MIME Type application/rs-metadata-request 900 This document registers the application/rs-metadata-request MIME 901 media type in order to describe a recording session metadata snapshot 902 request. This media type is defined by the following information: 904 Media type name: application 906 Media subtype name: rs-metadata-request 908 Required parameters: none 910 Options parameters: none 912 11.5. SDP Attributes 914 This document registers the following new SDP attributes. 916 11.5.1. 'record' SDP Attribute 918 Contact names: Leon Portman leon.portman@nice.com, Henry Lum 919 henry.lum@genesyslab.com 921 Attribute name: record 923 Long form attribute name: Recording Indication 925 Type of attribute: media level 927 Subject to charset: no 929 This attribute provides the recording indication for the session or 930 media stream. 932 Allowed attribute values: on, off, paused 934 11.5.2. 'recordpref' SDP Attribute 936 Contact names: Leon Portman leon.portman@nice.com, Henry Lum 937 henry.lum@genesyslab.com 939 Attribute name: recordpref 941 Long form attribute name: Recording Preference 943 Type of attribute: media level 945 Subject to charset: no 947 This attribute provides the recording indication for the session or 948 media stream. 950 Allowed attribute values: on, off, pause, nopreference 952 12. Security Considerations 954 The recording session is fundamentally a standard SIP dialog 955 [RFC3261], therefore, the recording session can reuse any of the 956 existing SIP security mechanism available for securing the recorded 957 media as well as metadata. Other security considerations are 958 outlined in the use cases and requirements document [RFC6341]. 960 12.1. Authentication and Authorization 962 The recording session reuses the SIP mechanism to challenge requests 963 that is based on HTTP authentication. The mechanism relies on 401 964 and 407 SIP responses as well as other SIP header fields for carrying 965 challenges and credentials. 967 The SRS may have its own set of recording policies to authorize 968 recording requests from the SRC. The use of recording policies is 969 outside the scope of the Session Recording Protocol. 971 13. Acknowledgements 973 We want to thank John Elwell, Paul Kyzivat, Partharsarathi R, Ram 974 Mohan R, Charles Eckel, Hadriel Kaplan, Adam Roach, Miguel Garcia for 975 their valuable comments and inputs to this document. 977 14. References 979 14.1. Normative References 981 [I-D.ietf-siprec-metadata] 982 R, R., Ravindran, P., and P. Kyzivat, "Session Initiation 983 Protocol (SIP) Recording Metadata", 984 draft-ietf-siprec-metadata-04 (work in progress), 985 September 2011. 987 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 988 Requirement Levels", BCP 14, RFC 2119, March 1997. 990 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 991 Specifications: ABNF", RFC 2234, November 1997. 993 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 994 Registration Procedure", BCP 31, RFC 2506, March 1999. 996 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 997 May 2000. 999 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1000 A., Peterson, J., Sparks, R., Handley, M., and E. 1001 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1002 June 2002. 1004 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1005 with Session Description Protocol (SDP)", RFC 3264, 1006 June 2002. 1008 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1009 "Indicating User Agent Capabilities in the Session 1010 Initiation Protocol (SIP)", RFC 3840, August 2004. 1012 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1013 Preferences for the Session Initiation Protocol (SIP)", 1014 RFC 3841, August 2004. 1016 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1017 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 1019 [RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use 1020 Cases and Requirements for SIP-Based Media Recording 1021 (SIPREC)", RFC 6341, August 2011. 1023 14.2. Informative References 1025 [I-D.eckel-siprec-rtp-rec] 1026 Eckel, C., "Real-time Transport Protocol (RTP) 1027 Recommendations for SIPREC", draft-eckel-siprec-rtp-rec-02 1028 (work in progress), September 2011. 1030 [I-D.ietf-siprec-architecture] 1031 Hutton, A., Portman, L., Jain, R., and K. Rehor, "An 1032 Architecture for Media Recording using the Session 1033 Initiation Protocol", draft-ietf-siprec-architecture-03 1034 (work in progress), October 2011. 1036 [RFC4508] Levin, O. and A. Johnston, "Conveying Feature Tags with 1037 the Session Initiation Protocol (SIP) REFER Method", 1038 RFC 4508, May 2006. 1040 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 1041 (SIP) Call Control - Conferencing for User Agents", 1042 BCP 119, RFC 4579, August 2006. 1044 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 1045 Keeping Alive the NAT Mappings Associated with RTP / RTP 1046 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 1048 Authors' Addresses 1050 Leon Portman (editor) 1051 NICE Systems 1052 8 Hapnina 1053 Ra'anana 43017 1054 Israel 1056 Email: leon.portman@nice.com 1058 Henry Lum (editor) 1059 Genesys, Alcatel-Lucent 1060 1380 Rodick Road, Suite 200 1061 Markham, Ontario L3R4G5 1062 Canada 1064 Email: henry.lum@genesyslab.com 1065 Alan Johnston 1066 Avaya 1067 St. Louis, MO 63124 1069 Email: alan.b.johnston@gmail.com 1071 Andrew Hutton 1072 Siemens Enterprise Communications 1074 Email: andrew.hutton@siemens-enterprise.com