idnits 2.17.1 draft-ietf-siprec-protocol-00.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 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. 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: Note that when a media stream in the CS is muted/unmuted, this information is conveyed in the metadata by the SRC. The SRC SHOULD not modify the recorded media stream with a=inactive for mute since this operation is reserved for pausing the RS media. -- The document date (August 15, 2011) is 4637 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 643, but not defined == Unused Reference: 'RFC2119' is defined on line 980, but no explicit reference was found in the text == Unused Reference: 'RFC2804' is defined on line 989, but no explicit reference was found in the text == Unused Reference: 'I-D.eckel-siprec-rtp-rec' is defined on line 1018, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-siprec-metadata-03 ** 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-01 == Outdated reference: A later version (-12) exists of draft-ietf-siprec-architecture-02 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: February 16, 2012 Genesys, Alcatel-Lucent 6 A. Johnston 7 Avaya 8 A. Hutton 9 Siemens Enterprise 10 Communications 11 August 15, 2011 13 Session Recording Protocol 14 draft-ietf-siprec-protocol-00 16 Abstract 18 The Session Recording Protocol is used for establishing recording 19 session and reporting of the metadata of the communication session. 21 This document specifies the Session Recording Protocol. The protocol 22 is used between Session Recording Client (SRC) and Session Recording 23 Server (SRS). 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 16, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Overview of operations . . . . . . . . . . . . . . . . . . . . 5 63 4.1. Delivering recorded media . . . . . . . . . . . . . . . . 5 64 4.2. Conference focus as an SRC . . . . . . . . . . . . . . . . 6 65 4.3. Delivering recording metadata . . . . . . . . . . . . . . 7 66 5. SIP Extensions for Recording Session . . . . . . . . . . . . . 8 67 5.1. Callee Capabilities Extensions for SIP Recording . . . . . 9 68 5.1.1. src Feature Tag . . . . . . . . . . . . . . . . . . . 9 69 5.1.2. srs Feature Tag . . . . . . . . . . . . . . . . . . . 10 70 5.2. recording-session Options Tag . . . . . . . . . . . . . . 10 71 5.3. SDP handling . . . . . . . . . . . . . . . . . . . . . . . 11 72 5.4. RTP handling . . . . . . . . . . . . . . . . . . . . . . . 13 73 5.5. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 5.6. Requesting for metadata snapshot . . . . . . . . . . . . . 15 75 5.6.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . 16 76 5.7. Recording Pause and Resume . . . . . . . . . . . . . . . . 16 77 6. Extensions for Recording-aware User Agents . . . . . . . . . . 16 78 6.1. SIP Extensions . . . . . . . . . . . . . . . . . . . . . . 17 79 6.1.1. Recording awareness . . . . . . . . . . . . . . . . . 17 80 6.2. SDP Extensions . . . . . . . . . . . . . . . . . . . . . . 17 81 6.2.1. Providing recording indication . . . . . . . . . . . . 17 82 6.2.2. Recording preference . . . . . . . . . . . . . . . . . 19 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 84 7.1. Registration of Option Tags . . . . . . . . . . . . . . . 19 85 7.1.1. recording-session Option Tag . . . . . . . . . . . . . 20 86 7.1.2. record-aware Option Tag . . . . . . . . . . . . . . . 20 87 7.2. Registration of media feature tags . . . . . . . . . . . . 20 88 7.2.1. src feature tag . . . . . . . . . . . . . . . . . . . 20 89 7.2.2. srs feature tag . . . . . . . . . . . . . . . . . . . 21 90 7.3. New Content-Disposition Parameter Registrations . . . . . 21 91 7.4. Media Type Registration . . . . . . . . . . . . . . . . . 21 92 7.4.1. Registration of MIME Type application/rs-metadata . . 21 93 7.4.2. Registration of MIME Type 94 application/rs-metadata-request . . . . . . . . . . . 22 95 7.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 22 96 7.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . . 22 97 7.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . . 22 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 99 8.1. Authentication and Authorization . . . . . . . . . . . . . 23 100 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 102 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 103 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 106 1. Introduction 108 Communication Session (CS) recording requires establishment of the 109 recording session between communication system and recording system. 110 In order to allow access to such recordings, the metadata about the 111 CS shall be sent from the SRC to the SRS. 113 The SIP-based Media Recording Requirements [RFC6341] list a set of 114 requirements that need to be met by session recording protocols. The 115 Session Recording Protocol, which is specified in this document, 116 meets these requirements. 118 The remainder of this document is organized as follows: Section 2 119 defines the terminology used throughout this document, Section 3 120 discusses the scope of the Session Recording Protocol, Section 4 121 provides a non-normative overview of recording operations, Section 5 122 provides normative description of SIP extensions for the Recording 123 Session, Section 6 provides normative description of SIP extensions 124 for recording-aware user agents. 126 2. Definitions 128 This document refers to the core definitions provided in the 129 architecture document [I-D.ietf-siprec-architecture]. 131 3. Scope 133 The scope of the Session Recording Protocol includes the 134 establishment of the recording sessions and the reporting of the 135 metadata. The scope also includes extensions supported by Record- 136 aware User Agents such as indication of recording. The following 137 items, which are not an exhaustive list, do not represent the 138 protocol itself and are considered out of the scope of the Session 139 Recording Protocol: 141 o Recording policies that determine whether the CS should be 142 recorded 144 o Retention policies that determine how long a recording is stored 146 o Searching and accessing the recorded media and metadata 148 o Delivering recording session metadata through non-SIP mechanism 150 4. Overview of operations 152 This section is informative and provides a description of recording 153 operations. 155 As mentioned in the architecture document 156 [I-D.ietf-siprec-architecture], there are a couple of types of call 157 flows based on the location of the Session Recording Client. The 158 following sample call flows provide a quick overview of the 159 operations between the SRC and the SRS. 161 4.1. Delivering recorded media 163 When the SRC is deployed as a B2BUA, the SRC can route call requests 164 from UA(A) to UA(B). As a SIP B2BUA, the SRC has access to the media 165 path between the user agents. When the SRC is aware that it should 166 be recording the conversation, the SRC may bridge the media between 167 UA(A) and UA(B). The SRC then establishes the Recording Session with 168 the SRS and sends replicated media towards the SRS. 170 An endpoint can also be acting as the SRC, and the endpoint itself 171 will be establishing the Recording Session to the SRS. Since the 172 endpoint has access to the media in the Communication Session, the 173 endpoint can send replicated media towards the SRS. 175 The following is a sample call flow that shows the SRC establishing a 176 recording session towards the SRS. The call flow is essentially 177 identical when the SRC is a B2BUA or as the endpoint itself. Note 178 that the SRC can choose when to establish the Recording Session 179 independent of the Communication Session, even though the following 180 call flow suggests that the SRC is establishing the Recording Session 181 (message #5) after the Communication Session is established. 183 UA A SRC UA B SRS 184 |(1)CS INVITE | | | 185 |------------->| | | 186 | |(2)CS INVITE | | 187 | |---------------------->| | 188 | | (3)OK | | 189 | |<----------------------| | 190 | (4)OK | | | 191 |<-------------| | | 192 | |(5)RS INVITE with SDP | | 193 | |--------------------------------------------->| 194 | | | (6)OK with SDP | 195 | |<---------------------------------------------| 196 |(7)CS RTP | | | 197 |=============>|======================>| | 198 |<=============|<======================| | 199 | |(8)RS RTP | | 200 | |=============================================>| 201 | |=============================================>| 202 |(9)CS BYE | | | 203 |------------->| | | 204 | |(10)CS BYE | | 205 | |---------------------->| | 206 | |(11)RS BYE | | 207 | |--------------------------------------------->| 208 | | | | 210 Figure 1: Basic Recording Call flow 212 4.2. Conference focus as an SRC 214 A conference focus may also act as an SRC since it has access to all 215 the media from each conference participant. In this example, a user 216 agent may REFER the conference focus to the SRS, and the SRC may 217 choose to mix media streams from all participants as a single media 218 stream towards the SRS. In order to tell the conference focus to 219 start a recording session to the SRS, the user agent can include the 220 srs feature tag in the Refer-To header as per [RFC4508]. 222 UA A Focus UA B SRS 223 | (SRC) | | 224 | | | | 225 | (already in a conference) | | 226 |<==================>|<==================>| | 227 |(1)REFER sip:Conf-ID Refer-To:;srs | | 228 |------------------->| | 229 |(2)202 Accepted | | 230 |<-------------------| | 231 | (3)NOTIFY (Trying)| | 232 |<-------------------| | 233 |(4)200 OK | | 234 |------------------->| | 235 | |(5)RS INVITE Contact:Conf-ID;isfocus | 236 | |--------------------------------------->| 237 | | (6)200 OK | 238 | |<---------------------------------------| 239 | | (7)RTP (mixed or unmixed) | 240 | |=======================================>| 241 | (8)NOTIFY (OK) | | 242 |<-------------------| | 243 |(9)200 OK | | 244 |------------------->| | 246 Figure 2: Recording call flow - SRC as a conference focus 248 4.3. Delivering recording metadata 250 Certain metadata, such as the attributes of the recorded media 251 stream, are already included in the SDP of the recording session. 252 This information is reused as part of the metadata. The SRC may 253 provide an initial metadata snapshot about recorded media streams in 254 the initial INVITE content in the recording session. Subsequent 255 metadata updates can be represented as a stream of events in UPDATE 256 or reINVITE requests sent by the SRC. These metadata updates are 257 normally incremental updates to the initial metadata snapshot to 258 optimize on the size of updates, however, the SRC may also decide to 259 send a new metadata snapshot anytime. 261 The SRS also has the ability to send a request to the SRC to request 262 to receive a new metadata snapshot update when the SRS fails to 263 understand the current stream of incremental updates for whatever 264 reason (ie. SRS gets a syntax/semantic error in metadata update, the 265 SRS crashes and restarts), and the SRS may attach a reason along with 266 the snapshot request. This request allows both SRC and SRS to 267 restart the states with a new metadata snapshot so that further 268 metadata incremental updates will be based on the latest metadata 269 snapshot. Similar to the metadata content, the metadata snapshot 270 request is transported as content in UPDATE or INVITE sent by the SRS 271 in the recording session. 273 SRC SRS 274 | | 275 |(1) INVITE (metadata snapshot) | 276 |---------------------------------------------------->| 277 | (2)200 OK | 278 |<----------------------------------------------------| 279 |(3) ACK | 280 |---------------------------------------------------->| 281 |(4) RTP | 282 |====================================================>| 283 |(5) UPDATE (metadata update 1) | 284 |---------------------------------------------------->| 285 | (6) 200 OK | 286 |<----------------------------------------------------| 287 |(7) UPDATE (metadata update 2) | 288 |---------------------------------------------------->| 289 | (8) 200 OK | 290 |<----------------------------------------------------| 291 | (9) UPDATE (metadata snapshot request) | 292 |<----------------------------------------------------| 293 | (10) 200 OK | 294 |---------------------------------------------------->| 295 | (11) INVITE (metadata snapshot 2 + SDP offer) | 296 |---------------------------------------------------->| 297 | (12) 200 OK (SDP answer) | 298 |<----------------------------------------------------| 299 | (13) UPDATE (metadata update 1 based on snapshot 2) | 300 |---------------------------------------------------->| 301 | (14) 200 OK | 302 |<----------------------------------------------------| 304 Figure 3: Delivering metadata via SIP UPDATE 306 5. SIP Extensions for Recording Session 308 The following sections describe SIP extensions for the Recording 309 Session. 311 The From header must contain the identity of the SRC or the SRS. 312 Participants information is not recorded in the From or To header; 313 they are included in the metadata information. 315 Note that a recording session does not have to live within the scope 316 of a single communication session. As outline in REQ-005 of 317 [RFC6341], the recording session can be established in the absence of 318 a communication session. In this case, the SRC MUST pre-allocate a 319 recorded media stream and offer an SDP with at least one m= line to 320 establish a persistent recording session. When the actual call 321 arrives, the SRC can map recorded media stream to participant media 322 and minimize media clipping. 324 Recorded media from multiple communication sessions MAY be handled in 325 a single recording session. The SRC provides a reference of each 326 recorded media stream to the metadata described in the next section. 328 5.1. Callee Capabilities Extensions for SIP Recording 330 This section discusses how the callee capabilities defined in 331 [RFC3840] can be extended for SIP call recording. 333 SIP Callee Capabilities defines feature tags which are used to 334 represent characteristics and capabilities of a UA. From RFC 3840: 336 "Capability and characteristic information about a UA is carried 337 as parameters of the Contact header field. These parameters can 338 be used within REGISTER requests and responses, OPTIONS responses, 339 and requests and responses that create dialogs (such as INVITE)." 341 Note that feature tags are also used in dialog modifying requests and 342 responses such as re-INVITE and responses to a re-INVITE, and UPDATE. 343 The 'isfocus' feature tag, defined in [RFC4579] is similar 344 semantically to this case: it indicates that the UA is acting as a 345 SIP conference focus, and is performing a specific action (mixing) on 346 the resulting media stream. This information is available from 347 OPTIONS queries, dialog package notifications, and the SIP 348 registration event package. 350 Two new feature tags are introduced: 'src' and 'srs'. 352 5.1.1. src Feature Tag 354 The 'src' feature tag is used in Contact URIs by the Session 355 Recording Client (SRC) related to recording sessions. A Session 356 Recording Server uses the presence of this feature tag in dialog 357 creating and modifying requests and responses to confirm that the 358 dialog being created is for the purpose of a Recording Session. In 359 addition, a registrar could discover that a UA is an SRC based on the 360 presence of this feature tag in a registration. Other SIP Recording 361 extensions and behaviors can be triggered by the presence of this 362 feature tag. 364 Note that we could use a single feature tag, such as 'recording' used 365 by either an SRC or SRS to identify that the session is a recording 366 session. However, due to the differences in functionality and 367 behavior between an SRC and SRS, using only one feature tag for both 368 is not ideal. For instance, if a routing mistake resulted in a 369 request from a SRC being routed back to another SRC, if only one 370 feature tag were defined, they would not know right away about the 371 error and could become confused. With separate feature tags, they 372 would realize the error immediately and terminate the session. Also, 373 call logs would clearly show the routing error. 375 To ensure a recording session is redirected to an SRS, an SRC can 376 utilize the SIP Caller Preferences extensions, defined in [RFC3841]. 377 The presence of a Accept-Contact: *;sip.srs allows a UA to request 378 that the INVITE be routed to an SRS. Note that to be completely 379 sure, the SRC would need to include a Require: prefs header field in 380 the request. 382 5.1.2. srs Feature Tag 384 The 'srs' feature tag is used in Contact URIs by the Session 385 Recording Server (SRS) related to recording sessions. A Session 386 Recording Client uses the presence of this feature tag in dialog 387 creating and modifying requests and responses to confirm that the 388 dialog being created is for the purpose of a Recording Session 389 (REQ-30). In addition, a registrar could discover that a UA is an 390 SRS based on the presence of this feature tag in a registration. 391 Other SIP Recording extensions and behaviors can be triggered by the 392 presence of this feature tag. 394 To ensure a recording session is redirected to an SRC, an SRS can 395 utilize the SIP Caller Preferences extensions, defined in [RFC3841]. 396 The presence of a Accept-Contact: *;sip.src allows a UA to request 397 that the INVITE be routed to an SRC. Note that to be completely 398 sure, the SRS would need to include a Require: prefs header field in 399 the request. 401 5.2. recording-session Options Tag 403 Since SIP Caller Preferences extensions are optional to implement for 404 routing proxies, there is no guarantee that a recording session will 405 be routed an SRC or SRS. We introduce the use of the recording- 406 session option tag as a mechanism to ensure only an SRC or an SRS 407 would be able to accept recording sessions. An SRC or an SRS SHOULD 408 include the recording-session option tag in the Require header so 409 that other types of user agents can simply reject the INVITE request 410 with a 420 Bad Extension. 412 5.3. SDP handling 414 Following the SDP offer/answer model in [RFC3264], this section 415 describes the conventions used in the recording session for SDP 416 handling. 418 SRC must provide an SDP offer in the initial INVITE to the SRS. SRC 419 can include one or more media streams to the SRS. The SRS must 420 respond with the same number of media descriptors in the SDP body of 421 the 200 OK. 423 The SRC should use a=sendonly attribute as the SRC does not expect to 424 receive media from the SRS. As SRS only receives RTP streams from 425 SRC, the 200 OK response will normally contain SDP with a=recvonly 426 attribute. 428 Since the SRC may send recorded media of different participants (or 429 even mixed streams) to the SRS, the SDP must provide a label on each 430 media stream in order to identify the recorded stream with the rest 431 of the metadata. The a=label attribute [RFC4574] will be used to 432 identify each recorded media stream, and the label name is mapped to 433 the Media Stream Reference in the metadata in 434 [I-D.ietf-siprec-metadata]. Note that a participant may have 435 multiple streams (audio and video) and each stream is labeled 436 separately. 438 v=0 439 o=SRS 0 0 IN IP4 172.22.3.8 440 s=SRS 441 c=IN IP4 172.22.3.8 442 t=0 0 443 m=audio 12241 RTP/AVP 0 4 8 444 a=sendonly 445 a=label:1 446 m=audio 12242 RTP/AVP 98 447 a=rtpmap:98 H264/90000 448 a=fmtp:98 ... 449 a=sendonly 450 a=label:2 451 m=audio 12243 RTP/AVP 0 4 8 452 a=sendonly 453 a=label:3 454 m=audio 12244 RTP/AVP 98 455 a=rtpmap:98 H264/90000 456 a=fmtp:98 ... 457 a=sendonly 458 a=label:4 460 Figure 4: Sample SDP with audio and video streams 462 To remove a recorded media stream from the recording session, send a 463 reINVITE and set the port to zero in the m= line. 465 To add a recorded media stream, send a reINVITE and add a new m= 466 line. 468 The SRS may respond with a=inactive attribute as part of the SDP in 469 the 200 OK response when the SRS is not ready to receive recorded 470 media. The SRS can send re-INVITE to update the SDP with a=recvonly 471 when it is ready to receive media. 473 The following sequence diagram shows an example of SRS responds with 474 SDP that contain a=inactive, and then later update media information 475 update with re-INVITE. 477 SRC SRS 478 | | 479 |(1) INVITE (SDP offer) | 480 |---------------------------------------------------->| 481 | (2)200 OK with SDP inactive | 482 |<----------------------------------------------------| 483 |(3) ACK | 484 |---------------------------------------------------->| 485 | ... | 486 | (4) re-INVITE with SDP recvonly | 487 |<----------------------------------------------------| 488 |(5)200 OK with SDP sendonly | 489 |---------------------------------------------------->| 490 | (6) ACK | 491 |<----------------------------------------------------| 492 |(7) RTP | 493 |====================================================>| 494 | ... | 495 |(8) BYE | 496 |---------------------------------------------------->| 497 | (9) OK | 498 |<----------------------------------------------------| 500 Figure 5: SRS to offer with a=inactive 502 5.4. RTP handling 504 [This is a placeholder section to specify any protocol impacts or 505 recommendations for RTP usage in the session recording protocol. The 506 details are listed in [I-D.eckel-siprec-rtp-rec]] 508 5.5. Metadata 510 The format of the full metadata will be described as part of the 511 mechanism in [I-D.ietf-siprec-metadata]. 513 As mentioned in the previous section, the SDP of the recording 514 session describes the properties of media for all recorded media 515 streams. The label attribute contains a reference to the rest of the 516 metadata information. 518 For all basic metadata information such as communication session, 519 participants and call identifiers, they can be included in the 520 initial INVITE request sent by the SRC. Metadata can be included as 521 content in the INVITE or UPDATE request. A new "disposition-type" of 522 Content-Disposition is defined for this purpose and the value is 523 "recording-session". 525 The following is an example for RS establishment between SRC and SRS 526 with metadata as content. 528 INVITE sip:97753210@10.240.3.10:5060 SIP/2.0 529 From: ;tag=35e195d2-947d-4585-946f-098392474 530 To: 531 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a@10.226.240.3 532 CSeq: 101 INVITE 533 Date: Thu, 26 Nov 2009 02:38:49 GMT 534 Supported: timer 535 Max-Forwards: 70 536 Min-SE: 90 537 Session-Expires: 1800 538 Require: recording-session 539 Contact: ;src 540 Via: SIP/2.0/TCP 10.226.240.3:5060;branch=z9hG4bKdf6b622b648d9 541 Content-Type: multipart/mixed;boundary=foobar 542 Content-Length: [length] 544 --foobar 545 Content-Type: application/sdp 547 v=0 548 o=SRS 0 0 IN IP4 10.226.240.3 549 c=IN IP4 10.226.240.3 550 t=0 0 551 m=audio 12241 RTP/AVP 0 4 8 552 a=sendonly 553 a=label:1 555 --foobar 556 Content-Type: application/rs-metadata 557 Content-Disposition: recording-session 559 [metadata content] 561 Figure 6: Sample INVITE request for the recording session 563 Further updates to recording metadata can be delivered as a sequence 564 events reported in SIP UPDATE or reINVITE requests and the SRS must 565 receive the sequence of events in order. Since there can only be a 566 single INVITE or UPDATE transaction happening at a time within a SIP 567 dialog, using sequence number CSeq in the dialog can be a reliable 568 way for the SRS to identify the receipt of the next metadata update. 570 At any time during Recording Session, the SRC can send a new metadata 571 snapshot in a SIP reINVITE request along with an SDP offer. All 572 subsequent metadata updates will be based on the new metadata 573 snapshot. 575 5.6. Requesting for metadata snapshot 577 The SRS can send a request for metadata snapshot any time after the 578 Recording Session has been established. Typically, the SRS sends 579 such as request in the case where the SRS is failing to process 580 further metadata incremental updates. Failure scenarios can include 581 failure to internal SRS error or failure to match metadata update 582 sequence. Certain errors, such syntax errors or semantic errors in 583 the metadata information, are likely caused by an error on the SRC 584 side, and it is likely the same error will occur again when a new 585 snapshot is requested. In order to avoid repeating the same error 586 with snapshot requests, it is RECOMMENDED that the SRS terminate the 587 recording session when a syntax error or semantic error occurs in the 588 metadata. 590 Similar to delivering metadata, the SRS sends the metadata snapshot 591 request as content in UPDATE or INVITE requests or responses. The 592 same disposition type "recording-session" is used to note that the 593 content represents content sent by the SRS. The format of the 594 content is application/rs-metadata-request, and the body format is 595 chosen to be a simple text-based format with header and values. The 596 following shows an example: 598 UPDATE sip:2000@10.226.240.3:5060 SIP/2.0 599 To: ;tag=35e195d2-947d-4585-946f-098392474 600 From: ;tag=1234567890 601 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a@10.226.240.3 602 CSeq: 1 UPDATE 603 Supported: timer 604 Max-Forwards: 70 605 Min-SE: 90 606 Session-Expires: 1800 607 Require: recording-session 608 Contact: ;srs 609 Via: SIP/2.0/UDP 10.240.3.10:5060;branch=z9hG4bKdf6b622b648d9 610 Content-Disposition: recording-session 611 Content-Type: application/rs-metadata-request 612 Content-Length: [length] 614 Reason: SRS internal error 616 Figure 7: Metadata Request 618 The SRS MAY include the reason why a metadata snapshot request is 619 being made to the SRC in the Reason header. This header is free form 620 text mainly designed for logging purposes on the SRC side. The body 621 format also allows additional extension headers to be included by the 622 SRS in the snapshot request to convey additional information to the 623 SRC. The processing of the content by the SRC is entirely optional 624 since the content is for logging only, and the snapshot request 625 itself is indicated by the use of the application/rs-metadata-request 626 content type. 628 When the SRC receives the request for a metadata snapshot, the SRC 629 MUST provide a metadata snapshot in a separate INVITE transaction, 630 along with an SDP offer. All subsequent metadata updates sent by the 631 SRC MUST be based on the new metadata snapshot. 633 5.6.1. Formal Syntax 635 The formal syntax for the application/rs-metadata-request MIME is 636 described below using the augmented Backus-Naur Form (BNF) as 637 described in [RFC2234]. 639 snapshot-request = srs-reason-line CRLF [ *opt-srs-headers ] 641 srs-reason-line = "Reason" HCOLON srs-reason 643 srs-reason = [TEXT-UTF8-TRIM] 645 opt-srs-headers = CRLF 1*(extension-header CRLF) 647 5.7. Recording Pause and Resume 649 To temporarily discontinue streaming and collection of recorded media 650 from the SRC to the SRS, the SRC sends a reINVITE and set a=inactive 651 for each recorded media stream to be paused. 653 To resume streaming and collection of recorded media, the SRC sends a 654 reINVITE and set a=sendonly for each recorded media stream to resume. 656 Note that when a media stream in the CS is muted/unmuted, this 657 information is conveyed in the metadata by the SRC. The SRC SHOULD 658 not modify the recorded media stream with a=inactive for mute since 659 this operation is reserved for pausing the RS media. 661 6. Extensions for Recording-aware User Agents 663 The following sections describe SIP and SDP extensions for recording- 664 aware UA. 666 6.1. SIP Extensions 668 6.1.1. Recording awareness 670 A recording-aware UA SHOULD indicate that it can accept reporting of 671 recording indication in media level SDP provided in the previous 672 section. A new option tag "record-aware" is introduced to indicate 673 such awareness. 675 A UA that has indicated recording awareness by including the record- 676 aware option tag in a transmitted Supported header field MUST provide 677 at its user interface an indication whether recording is on or off 678 for a given medium based on the most recently received a=record SDP 679 attribute for that medium. 681 Some user agents that are automatons (eg. IVR, media server, PSTN 682 gateway) may not have a user interface to render recording 683 indication. When such user agent indicates recording awareness, the 684 UA SHOULD render recording indication through other means, such as 685 passing an inband tone on the PSTN gateway, putting the recording 686 indication in a log file, or raising an application event in a 687 VoiceXML dialog. These user agents MAY also choose not to indicate 688 recording awareness, thereby relying on whatever mechanism an SRC 689 chooses to indicate recording, such as playing a tone inband. 691 When a UA has not indicated that it is recording aware, an SRC MUST 692 provide recording indications, where SRC is required to do so based 693 on policies, through other means such as playing a tone inband. 695 6.2. SDP Extensions 697 6.2.1. Providing recording indication 699 While there are existing mechanisms for providing an indication that 700 a CS is being recorded, these mechanisms are usually delivered on the 701 CS media streams such as playing an in-band tone or an announcement 702 to the participants. A new SDP attribute is introduced to allow a 703 recording-aware UA to render recording indication at the user 704 interface. 706 The 'record' SDP attribute appears at the media level in either SDP 707 offer or answer. The recording indication applies to the specified 708 media stream only, for example, only the audio portion of the call is 709 recorded in an audio/video call. The following is the ABNF of the 710 'record' attribute: 712 record-attr = "a=record:" indication 714 indication = "on" / "off" / "paused" 716 on Recording is in progress. 718 off No recording is in progress. 720 paused Recording is in progress by media is paused. 722 The recording attribute is a declaration by the endpoints in the 723 session to indicate whether recording is taking place. For example, 724 if a UA (A) is initiating a call to UA (B) and UA (A) is also an SRC 725 that is performing the recording, then UA (A) provides the recording 726 indication in the SDP offer with a=record:on. When UA (B) receives 727 the SDP offer, UA (B) will see that recording is happening on the 728 other endpoint of this session. If UA (B) does not wish to perform 729 recording itself, UA (B) provides the recording indication as 730 a=record:off in the SDP answer. 732 Whenever the recording indication needs to change, such as 733 termination of recording, then the UA MUST initiate a reINVITE to 734 update the SDP attribute to a=record:off. The following call flow 735 shows an example of the offer/answer with the recording indication 736 attribute. 738 UA A UA B 739 (SRC) | 740 | | 741 | [SRC recording starts] | 742 |(1) INVITE (SDP offer + a=record:on) | 743 |---------------------------------------------------->| 744 | 200 OK (SDP answer + a=record:off) | 745 |<----------------------------------------------------| 746 |(3) ACK | 747 |---------------------------------------------------->| 748 |(4) RTP | 749 |<===================================================>| 750 | [SRC stops recording] | 751 |(5) re-INVITE (SDP + a=record:off) | 752 |---------------------------------------------------->| 753 | (6) 200 OK (SDP + a=record:off)| 754 |<----------------------------------------------------| 755 | (6) ACK | 756 |---------------------------------------------------->| 758 Figure 8: Recording indication example 760 If a call is traversed through one or more SIP B2BUA, and it happens 761 that there are more than one SRC in the call path, the recording 762 indication attribute does not provide any hint as to which SRC is 763 performing the recording, meaning the endpoint only knows that the 764 call is being recorded. This attribute is also not used as an 765 indication to negotiate which SRC in the call path will perform 766 recording and is not used as a request to start/stop recording if 767 there are multiple SRCs in the call path. 769 6.2.2. Recording preference 771 A recording-aware UA involved in a CS MAY request the CS to be 772 recorded or not recorded. This indication of recording preference 773 can be sent at session establishment time or during the session. 775 A new SDP attribute "recordpref" is introduced. The SDP attribute 776 appears at the media level and can only appear in an SDP offer. The 777 recording indication applies to the specified media stream only. The 778 following is the ABNF of the recordpref attribute: 780 recordpref-attr = "a=recordpref:" pref 782 pref = "on" / "off" / "pause" / "nopreference" 784 on Request for recording if it has not already been started. If the 785 recording is currently paused, request to resume recording. 787 off Request for no recording. If recording has already been 788 started, then this preference indicates a request to stop 789 recording. 791 pause Request to pause recording if recording is currently in 792 progress. 794 nopreference To indicate that the UA has no preference on recording. 795 While the absence of this attribute indirectly implies the lack of 796 preference, using this value allows the UA to explicitly state no 797 preference to being recorded. 799 7. IANA Considerations 801 7.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 7.1.1. recording-session Option Tag 809 Name: recording-session 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 7.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 7.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 7.2.1. src feature tag 833 Media feature tag name: sip.src 835 ASN.1 Identifer: 25 837 Summary of the media feature indicated by this tag: This feature 838 tag indicates that the user agent is a Session Recording Client 839 for the purpose for Recording Session. 841 Values appropriate for use with this feature tag: boolean 843 The feature tag is intended primarily for use in the following 844 applications, protocols, services, or negotiation mechanisms: This 845 feature tag is only useful for a Recording Session. 847 Examples of typical use: Routing the request to a Session 848 Recording Server. 850 Security Considerations: Security considerations for this media 851 feature tag are discussed in Section 11.1 of RFC 3840. 853 7.2.2. srs feature tag 855 Media feature tag name: sip.srs 857 ASN.1 Identifer: 26 859 Summary of the media feature indicated by this tag: This feature 860 tag indicates that the user agent is a Session Recording Server 861 for the purpose for Recording Session. 863 Values appropriate for use with this feature tag: boolean 865 The feature tag is intended primarily for use in the following 866 applications, protocols, services, or negotiation mechanisms: This 867 feature tag is only useful for a Recording Session. 869 Examples of typical use: Routing the request to a Session 870 Recording Client. 872 Security Considerations: Security considerations for this media 873 feature tag are discussed in Section 11.1 of RFC 3840. 875 7.3. New Content-Disposition Parameter Registrations 877 This document registers a new "disposition-type" value in Content- 878 Disposition header: recording-session. 880 recording-session the body describes the metadata information about 881 the recording session 883 7.4. Media Type Registration 885 7.4.1. Registration of MIME Type application/rs-metadata 887 This document registers the application/rs-metadata MIME media type 888 in order to describe the recording session metadata. This media type 889 is defined by the following information: 891 Media type name: application 893 Media subtype name: rs-metadata 895 Required parameters: none 897 Options parameters: none 899 7.4.2. Registration of MIME Type application/rs-metadata-request 901 This document registers the application/rs-metadata-request MIME 902 media type in order to describe a recording session metadata snapshot 903 request. This media type is defined by the following information: 905 Media type name: application 907 Media subtype name: rs-metadata-request 909 Required parameters: none 911 Options parameters: none 913 7.5. SDP Attributes 915 This document registers the following new SDP attributes. 917 7.5.1. 'record' SDP Attribute 919 Attribute name: record 921 Long form attribute name: Recording Indication 923 Type of attribute: media level 925 Subject to charset: no 927 This attribute provides the recording indication for the session or 928 media stream. 930 Allowed attribute values: on, off, paused 932 7.5.2. 'recordpref' SDP Attribute 934 Attribute name: recordpref 936 Long form attribute name: Recording Preference 938 Type of attribute: media level 940 Subject to charset: no 942 This attribute provides the recording indication for the session or 943 media stream. 945 Allowed attribute values: on, off, pause, nopreference 947 8. Security Considerations 949 The recording session is fundamentally a standard SIP dialog 950 [RFC3261], therefore, the recording session can reuse any of the 951 existing SIP security mechanism available for securing the recorded 952 media as well as metadata. 954 8.1. Authentication and Authorization 956 The recording session reuses the SIP mechanism to challenge requests 957 that is based on HTTP authentication. The mechanism relies on 401 958 and 407 SIP responses as well as other SIP header fields for carrying 959 challenges and credentials. 961 The SRS may have its own set of recording policies to authorize 962 recording requests from the SRC. The use of recording policies is 963 outside the scope of the Session Recording Protocol. 965 9. Acknowledgements 967 We want to thank John Elwell, Paul Kyzivat, Partharsarathi R, Ram 968 Mohan R, Charles Eckel, Hadriel Kaplan, Adam Roach for their valuable 969 comments and inputs to this document. 971 10. References 973 10.1. Normative References 975 [I-D.ietf-siprec-metadata] 976 R, R., R, P., and P. Kyzivat, "Session Initiation Protocol 977 (SIP) Recording Metadata", draft-ietf-siprec-metadata-03 978 (work in progress), July 2011. 980 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 981 Requirement Levels", BCP 14, RFC 2119, March 1997. 983 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 984 Specifications: ABNF", RFC 2234, November 1997. 986 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 987 Registration Procedure", BCP 31, RFC 2506, March 1999. 989 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 990 May 2000. 992 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 993 A., Peterson, J., Sparks, R., Handley, M., and E. 994 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 995 June 2002. 997 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 998 with Session Description Protocol (SDP)", RFC 3264, 999 June 2002. 1001 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1002 "Indicating User Agent Capabilities in the Session 1003 Initiation Protocol (SIP)", RFC 3840, August 2004. 1005 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1006 Preferences for the Session Initiation Protocol (SIP)", 1007 RFC 3841, August 2004. 1009 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1010 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 1012 [RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use 1013 Cases and Requirements for SIP-Based Media Recording 1014 (SIPREC)", RFC 6341, August 2011. 1016 10.2. Informative References 1018 [I-D.eckel-siprec-rtp-rec] 1019 Eckel, C., "Real-time Transport Protocol (RTP) 1020 Recommendations for SIPREC", draft-eckel-siprec-rtp-rec-01 1021 (work in progress), June 2011. 1023 [I-D.ietf-siprec-architecture] 1024 Hutton, A., Portman, L., Jain, R., and K. Rehor, "An 1025 Architecture for Media Recording using the Session 1026 Initiation Protocol", draft-ietf-siprec-architecture-02 1027 (work in progress), April 2011. 1029 [RFC4508] Levin, O. and A. Johnston, "Conveying Feature Tags with 1030 the Session Initiation Protocol (SIP) REFER Method", 1031 RFC 4508, May 2006. 1033 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 1034 (SIP) Call Control - Conferencing for User Agents", 1035 BCP 119, RFC 4579, August 2006. 1037 Authors' Addresses 1039 Leon Portman (editor) 1040 NICE Systems 1041 8 Hapnina 1042 Ra'anana 43017 1043 Israel 1045 Email: leon.portman@nice.com 1047 Henry Lum (editor) 1048 Genesys, Alcatel-Lucent 1049 1380 Rodick Road, Suite 200 1050 Markham, Ontario L3R4G5 1051 Canada 1053 Email: henry.lum@genesyslab.com 1055 Alan Johnston 1056 Avaya 1057 St. Louis, MO 63124 1059 Email: alan.b.johnston@gmail.com 1061 Andrew Hutton 1062 Siemens Enterprise Communications 1064 Email: andrew.hutton@siemens-enterprise.com