idnits 2.17.1 draft-ietf-siprec-architecture-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2012) is 4421 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3265' is defined on line 623, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-22) exists of draft-ietf-siprec-metadata-04 == Outdated reference: A later version (-18) exists of draft-ietf-siprec-protocol-00 -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPREC A. Hutton, Ed. 3 Internet-Draft Siemens Enterprise 4 Intended status: Informational Communications 5 Expires: September 13, 2012 L. Portman, Ed. 6 Nice Systems 7 R. Jain 8 IPC Systems 9 K. Rehor 10 Cisco Systems, Inc. 11 March 12, 2012 13 An Architecture for Media Recording using the Session Initiation 14 Protocol 15 draft-ietf-siprec-architecture-04 17 Abstract 19 Session recording is a critical requirement in many communications 20 environments such as call centers and financial trading. In some of 21 these environments, all calls must be recorded for regulatory, 22 compliance, and consumer protection reasons. Recording of a session 23 is typically performed by sending a copy of a media stream to a 24 recording device. This document describes architectures for 25 deploying session recording solutions in an environment which is 26 based on the Session Initiation Protocol (SIP). 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 13, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Session Recording Architecture . . . . . . . . . . . . . . . . 5 65 3.1. Location of the Session Recording Client . . . . . . . . . 5 66 3.1.1. B2BUA acts as a Session Recording Client . . . . . . . 5 67 3.1.2. Endpoint acts as Session Recording Client . . . . . . 7 68 3.1.3. A SIP Proxy cannot be a Session Recording Client . . . 7 69 3.1.4. Interaction with MEDIACTRL . . . . . . . . . . . . . . 8 70 3.1.5. Interaction with Conference Focus . . . . . . . . . . 9 71 3.2. Establishing the Recording Session . . . . . . . . . . . . 10 72 3.2.1. Session Recording Client Initiated Recording . . . . . 11 73 3.2.2. Session Recording Server Initiated Recording . . . . . 11 74 3.2.3. Pause/Resume Recording Session . . . . . . . . . . . . 12 75 3.2.4. Media Stream Mixing . . . . . . . . . . . . . . . . . 12 76 3.2.5. Media Transcoding . . . . . . . . . . . . . . . . . . 12 77 3.3. Media Recording Metadata . . . . . . . . . . . . . . . . . 13 78 3.3.1. Contents of recording metadata . . . . . . . . . . . . 13 79 3.3.2. Mechanisms for delivery of metadata to Session 80 Recording Server . . . . . . . . . . . . . . . . . . . 13 81 3.4. Notifications to the Recorded User Agents . . . . . . . . 13 82 3.5. Preventing the recording of a SIP session . . . . . . . . 13 83 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 84 5. Security considerations . . . . . . . . . . . . . . . . . . . 14 85 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 86 7. Informative References . . . . . . . . . . . . . . . . . . . . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 89 1. Introduction 91 Session recording is a critical requirement in many communications 92 environments such as call centers and financial trading. In some of 93 these environments, all calls must be recorded for regulatory, 94 compliance, and consumer protection reasons. Recording of a session 95 is typically performed by sending a copy of a media stream to a 96 recording device. This document describes architectures for 97 deploying session recording solutions in an environment which is 98 based on the Session Initiation Protocol (SIP) the requirements for 99 which are described in [RFC6341]. 101 This document focuses on how sessions are established between a 102 Session Recording Client (SRC) and the Session Recording Server (SRS) 103 for the purpose of conveying the Replicated Media and Media Recording 104 Metadata (e.g. Identity of parties involved) relating to the 105 Communication Session. 107 Once the Replicated Media and Media Recording Metadata have been 108 received by the Session Recording Server they will typically be 109 archived for retrieval at a later time. The procedures relating to 110 the archiving and retrieval of this information in outside the scope 111 of this document. 113 This document only considers active recording, where the Session 114 Recording Client purposefully streams media to a Session Recording 115 Server. Passive recording, where a recording device detects media 116 directly from the network (E.g. using port mirroring techniques), is 117 outside the scope of this document. In addition, lawful intercept is 118 outside the scope of this document which takes account of the IETF 119 policy on wiretapping [RFC2804]. 121 The Recording Session that is established between the Session 122 Recording Client and the Session Recording Server uses the normal 123 procedures for establishing INVITE initiated dialogs as specified in 124 [RFC3261] and uses SDP for describing the media to be used during the 125 session as specified in [RFC4566]. However it is intended that some 126 extensions to SIP (E.g. Headers, Option Tags, Etc.) will be defined 127 to support the requirements for media recording. The Replicated 128 Media is required to be sent in real-time to the Session Recording 129 Server and is not buffered by the Session Recording Client to allow 130 for real-time analysis of the media by the Session Recording Server. 132 2. Definitions 134 Session Recording Server (SRS): A Session Recording Server (SRS) is 135 a SIP User Agent (UA) that acts as the sink of the recorded media. 136 An SRS is a logical function that typically archives media for 137 extended durations of time and provides interfaces for search and 138 retrieval of the archived media. An SRS is typically implemented as 139 a multi-port device that is capable of receiving media from several 140 sources simultaneously. An SRS is the sink of the recorded session 141 metadata. Note that the term "Server" does not imply the SRS is the 142 server side of a signaling protocol as the SRS may be the initiator 143 of recording requests. 145 Session Recording Client (SRC): A Session Recording Client (SRC) is 146 a SIP User Agent (UA) that acts as the source of the recorded media, 147 sending it to the Session Recording Server. A Session Recording 148 Client is a logical function. Its capabilities may be implemented 149 across one or more physical devices. In practice, a Session 150 Recording Client could be a personal device (such as a SIP phone), a 151 SIP Media Gateway (MG), a Session Border Controller (SBC), Media 152 Server, or an Application Server. The Session Recording Client is 153 also the source of the recorded session metadata. 155 Communication Session (CS): A SIP session created between two or 156 more UA's for the purpose of communication which may be recorded. 158 Recording Session (RS): The session created between an Session 159 Recording Client and Session Recording Server for the purpose of 160 recording a Communication Session. 162 Recording aware User Agent (UA): A SIP User Agent that is aware of 163 SIP extensions associated with the Communication Session. Such 164 extensions may be used to notify the Recording aware UA that a 165 session is being recorded or to all the Recording aware UA to express 166 preferences as to whether a recording should be started, paused, 167 resumed or stopped. 169 Recording unaware User Agent (UA): A SIP User Agent that is unaware 170 of SIP extensions associated with the Communication Session. Such 171 Recording unaware UA will be notified that a session is being 172 recorded or to express preferences as to whether a recording should 173 be started, paused, resumed or stopped via some other means that out 174 of scope of the SIPREC. 176 Media Recording Metadata (MRM): The metadata describing the 177 communication session that is required by the Session Recording 178 Server. This will include for example the identity of users that 179 participate in the Communication Session and dialog state. Typically 180 this metadata is archived with the replicated media at the Session 181 Recording Server. The media recording metadata is delivered in real- 182 time to the Session Recording Server. 184 Replicated Media: A copy of the media associated with the 185 Communication Session created by the Session Recording Client and 186 sent to the Session Recording Server. It may contain all the media 187 associated with the communication session (E.g. Audio and Video) or 188 just a subset (E.g. Audio). Replicated Media is part of Recordin 189 Session. 191 3. Session Recording Architecture 193 3.1. Location of the Session Recording Client 195 This section contains some example session recording architectures 196 showing how the Session Recording Client is a logical function that 197 can be located in or split between various physical components. 199 3.1.1. B2BUA acts as a Session Recording Client 201 A SIP Back to Back User Agent (B2BUA) which has access to the media 202 that is to be recorded may act as a Session Recording Client. The 203 B2BUA may already be aware that a session needs to be recorded before 204 the initial establishment of the communication session or the 205 decision to record the session may occur after the session has been 206 established. 208 If the B2BUA/SRC makes the decision to initiate the Recording Session 209 (RS) then it will initiate the establishment of a SIP Session by 210 sending an INVITE to the Session Recording Server. 212 If the Session Recording Server makes the decision to initiate the 213 recording session then it will initiate the establishment of a SIP 214 Session by sending an INVITE to the B2BUA/Session Recording Client. 216 The RS INVITE contains information which identifies the session as 217 being established for the purposes of recording and prevents the 218 session from being accidently rerouted to a UA which is not a SRS. 220 The B2BUA/SRC is responsible for notifying the UA's involved in the 221 communication session that the session is being recorded. 223 The B2BUA/SRC is responsible for honoring any indication from 224 recording aware UA's or through some configured policies that the 225 communication session must not be recorded. 227 +-----------+ 228 (Recording Session) | Session | 229 +------SIP------>| Recording | 230 | | Server | 231 | +--RTP/RTCP-->| (SRS) | 232 | | +-----------+ 233 V V ^ 234 +-------------+ | 235 | | | 236 | |-- MetaData -+ 237 | | 238 | B2BUA | 239 | | 240 | Session | 241 +--------+ | Recording | +---------+ 242 | |<- SIP ->| Client |<- SIP ->| | 243 | UA-A | | (SRC) | | UA-B | 244 | |<- RTP ->| |<- RTP ->| | 245 +--------+ | | +---------+ 246 +-------------+ 247 |____________________________________________________| 248 (Communication Session) 250 Figure 1: B2BUA Acts as the Session Recording Client. 252 3.1.2. Endpoint acts as Session Recording Client 254 A SIP Endpoint / UA may act as a Session Recording Client in which 255 case the endpoint sends the Replicated Media to the Session Recording 256 Server 258 If the endpoint makes the decision to initiate the Recording Session 259 then it will initiate the establishment of a SIP Session by sending 260 an INVITE to the Session Recording Server. 262 If the Session Recording Server makes the decision to initiate the 263 Recording Session then it will initiate the establishment of a SIP 264 Session by sending an INVITE to the endpoint. The actual decision 265 mechanism is out of scope of the SIPREC. 267 (Recording Session) +-----------+ 268 +----------SIP------>| | 269 | +----RTP/RTCP---->| Session | 270 | | | Recording | 271 | | | Server | 272 | | +-- Metadata -->| (SRS) | 273 | | | | | 274 | | | +-----------+ 275 | | | 276 | | | 277 | | | 278 | | | 279 V V | (Communication Session) 280 +--+------+ +---------+ 281 | |<-------SIP--------->| | 282 | UA-A | | UA-B | 283 | (SRC) |<-----RTP/RTCP------>| | 284 +---------+ +---------+ 286 Figure 2: SIP Endpoint acts as the Session Recording Client 288 3.1.3. A SIP Proxy cannot be a Session Recording Client 290 A SIP Proxy is unable to act as an SRC because it does not have 291 access to the media and therefore has no way of enabling the delivery 292 of the replicated media to the SRS 294 3.1.4. Interaction with MEDIACTRL 296 The mediactrl architecture [RFC5567] describes an architecure in 297 which an Application Server (AS) controls a Media Server (MS) which 298 may be used for purposes such as conferencing and recording media 299 streams. In the [RFC5567] architecure the AS typically uses SIP 300 Third Party Call Control (3PCC) to instruct the SIP UA's to direct 301 their media to the Media Server. 303 The Session Recording Client and Session Recording Server described 304 in this document may act as an application server as described in 305 [RFC5567] and therefore may when further decomposed be made up of an 306 application server which uses a mediactrl interface to control a 307 media server for the purpose of recording the media streams however 308 this interface is considered outside the scope of this document. 310 Session Recording Server (SRS) 311 +----------------------------------------+ 312 | | 313 (Recording Session) | +-----------+ +------------+ | 314 +------------SIP----|->| | | | | 315 | | | MediaCtrl |MEDIACTRL | Media | | 316 | | |Application|<-------->| Server | | 317 | +-----Metadata--->| Server | | (Recorder)| | 318 | | | | | | | | 319 | | | +-----------+ +------------+ | 320 | | | ^ | 321 | | +------------------------------|---------+ 322 | | +--------------- RTP/RTCP -----------------+ 323 | | | 324 V | V 325 +---+------+ +---------+ 326 | |<-------SIP-------------->| | 327 | UA-A | (Communication Session) | UA-B | 328 | (SRC) |<-------RTP/RTCP--------->| | 329 +----------+ +---------+ 331 Figure 3: Example of Session Recording Server using MEDIACTRL 332 +----------+ 333 (Recording Session) | Session | 334 +-----------SIP------------------------->|Recording | 335 | | Server | 336 | | (SRS) | 337 | UA-A Session Recording Client (SRC) +----------+ 338 +----------------------------------------+ ^ 339 | | | 340 | +-----------+ +------------+ | | 341 | | | Control | |<-RTP/RTCP-+ +---------+ 342 | | UA | Protocol | Media | | | | 343 | |Application|<-------->| Server | |<----SIP----->| UA-B | 344 | | Server | | |<-----RTP------>| | 345 | | | | | | +---------+ 346 | +-----------+ +------------+ | 347 | | 348 +----------------------------------------+ 349 Figure 4: Example of Session Recording Client decomposition 351 3.1.5. Interaction with Conference Focus 353 In the case of a centralised conference a combination of the 354 conference focus and mixer [RFC4353] may act as a SRC and therefore 355 provide the SRS with the replicated media and associated media 356 recording metadata. In this arrangement the SRC is able to provide 357 media and metadata relating to each of the participants, including, 358 for example, any side conversations where the media passes through 359 the mixer 361 The conference focus may also act as a Recording Aware UA in the case 362 when one of the participants acts as a SRC. 364 In an alternative arrangement a SIP endpoint which is a conference 365 participant can act as an SRC. The SRC will in this case have access 366 to the media and metadata relating to that particular participant and 367 may be able to obtain additional metadata from the conference focus. 368 The SRC may for example use the conference event package as described 369 in [RFC4575] to obtain information about other participants which it 370 provides to the SRS within the media recording metadata. 372 The SRC may be involved in the conference from the very beginning or 373 may join at some later point of time. 375 User 1 376 +-----------+ 377 | | 378 | | 379 |Participant| 380 | 1 | 381 | | 382 +-----------+ 383 ^ ^SIP 384 RTP | |Dialog 385 | |1 386 User 2 V V Recording 387 +-----------+ +-----------+ Session ************* 388 | | | |<------------>* * 389 | |<-- RTP -->| |<-RTP/RTCP 1->* * 390 |Participant|<--------->| Focus/SRC |<-RTP/RTCP 2->* SRS * 391 | 2 | SIP | |<-RTP/RTCP 3->* * 392 | | Dialog | | * * 393 +-----------+ 2 +-----------+ ************* 394 ^ ^ 395 | |SIP 396 RTP | |Dialog 397 | |3 398 V V 399 +-----------+ 400 | | 401 | | 402 |Participant| 403 | 3 | 404 | | 405 +-----------+ 406 User 3 408 Figure 5: Conference Focus acting as an SRC. 410 3.2. Establishing the Recording Session 412 The Session Recording Client or the Session Recording Server may 413 initiate the Recording Session. 415 It should be noted that the Recording Session is independent from the 416 Communication Session that is being recorded at both the SIP dialog 417 level and at the session level. 419 Concerning media negotiation, regular SIP/SDP capabilities should be 420 used, and existing transcoding capabilities should not be precluded 422 3.2.1. Session Recording Client Initiated Recording 424 When the Session Recording Client initiates the Recording Session for 425 the purpose of conveying media to the Session Recording Server it 426 performs the following actions. 428 o The SRC is provisioned with a Unified Resource Identifier (URI) 429 for the SRS, which is resolved through normal [RFC3263] 430 procedures. 432 o Initiates the dialog by sending an INVITE request to the Session 433 Recording Server. The dialog is established according to the 434 normal procedures for establishing an INVITE initiated dialog as 435 specified in [RFC3261]. 437 o Include in the INVITE an indication that the session is 438 established for the purpose of recording the associated media. 440 o If the Replicated Media is to be started immediately then the 441 Session Recording Client will include an SDP attribute of 442 "a=sendonly" for each media line or "a=inactive" if it is not 443 ready to transmit the media. 445 o The Recording Session may replicate all media associated with the 446 Communication Session or only a subset. 448 o Replicate the media streams that are to be recorded and transmit 449 the media to the Session Recording Server. 451 3.2.2. Session Recording Server Initiated Recording 453 When the Session Recording Server initiates the media recording 454 session with the Session Recording Client it performs the following 455 actions. 457 o The SRS is provisioned with a Unified Resource Identifier (URI) 458 for the SRC, which is resolved through normal [RFC3263] 459 procedures. 461 o Send an INVITE request to the Session Recording Client 463 o Include in the INVITE an indication that the session is 464 established for the purpose of recording the associated media. 465 Possible mechanisms for this include using the Require header or a 466 media feature tag similar to the use of "isfocus" as defined in 467 [RFC3840] 469 o The actual mechanism of the identification is depends on SRC 470 policy. 472 o Identify the session that is to be recorded - Possibly using the 473 Join header [RFC3911] 475 o If the Recording Session is to be started immediately then the 476 Session Recording Client will include an SDP attribute of 477 "a=recvonly" for each media line or "a=inactive" if it is not 478 ready to receive the media 480 If the Session Recording Server does not have prior knowledge of what 481 media streams are available to be recorded it can make use of an 482 offerless INVITE which allows the Session Recording Client to make 483 the initial Session Description Protocol (SDP) offer. 485 3.2.3. Pause/Resume Recording Session 487 The Session Recording Server or the Session Recording Client may 488 pause the recording by changing the SDP direction attribute to 489 "inactive" and resume the recording by changing the direction back to 490 "recvonly" or "sendonly". 492 3.2.4. Media Stream Mixing 494 In a basic session involving only audio there are typically two 495 audio/RTP streams between the two UA's involved transporting media in 496 each direction. When recording this media the two streams may be 497 mixed at the SRC before being transmitted to the SRS or it may be a 498 requirement of the recording server that the media streams are not 499 mixed and are sent to the SRS as two separate streams. The case when 500 media is mixed at the SRC is simple as only a single media stream is 501 required to be sent to the SRS. However in the case when the media 502 streams are not mixed then the SDP offer sent to the SRS must 503 describe two separate media streams. 505 3.2.5. Media Transcoding 507 The communication session (CS) and the recording session (RS) are 508 negotiated separately using a standard SDP offer/answer exchange 509 which may result in the SRC having to perform media transcoding 510 between the two sessions. If the SRC is not capable of performing 511 media transcoding it may limit the media formats in the offer to the 512 SRS depending on what media is negotiated on the CS or may limit what 513 it includes in the offer on the CS if it has prior knowledge of the 514 media formats supported by the SRS. However typically the SRS will 515 be the more capable device which can provide a wide range of media 516 format options to the SRC and may also be able to make use of a media 517 transcoder as detailed in [RFC5369]. 519 3.3. Media Recording Metadata 521 3.3.1. Contents of recording metadata 523 The metadata model is defined in [I-D.ietf-siprec-metadata]. 525 3.3.2. Mechanisms for delivery of metadata to Session Recording Server 527 The SRS obtains session recording metadata from the SRC. The 528 metadata is transported via SIP based mechanisms as specified in 529 [I-D.ietf-siprec-protocol] 531 It is also possible that metadata is transported via non SIP based 532 mechanisms but these are considered out of scope. 534 it is also possible to have RS session without the metadata, in such 535 case SRS will be receiving it by some other means or not at all. 537 3.4. Notifications to the Recorded User Agents 539 Typically a user that is involved in a session that is to be recorded 540 is notified by an announcement at the beginning of the session or may 541 receive some warning tones within the media. However the 542 standardization of media recording protocols when using SIP enable an 543 indication that the call is being recorded to be included in the SIP 544 requests and responses associated with that communication session. 546 It is the Session Recording Client that provides the notification to 547 all SIP UA's for which it is replicating received media for the 548 purpose of recording including the local user if the Session 549 Recording Client is a SIP endpoint. 551 3.5. Preventing the recording of a SIP session 553 A Recording Aware UA may during the initial session establishment or 554 during an established session provide an indication of their 555 preference with regard to recording the media in the communication 556 session. The mechanism for this are specified in 557 [I-D.ietf-siprec-protocol] 559 4. IANA considerations 561 None. 563 5. Security considerations 565 The Recording Session is fundamentally a standard SIP dialog and 566 media session and therefore make use of existing SIP security 567 mechanisms for securing the Recording Session and Media Recording 568 Metadata. 570 The intended use of this architecture is only for the case where the 571 users are aware of that they are being recorded and the architecture 572 provides the means for the Session Recording Client to notify users 573 that they are being recorded. 575 This architectural solution is not intended to support lawful 576 intercept which in contrast requires that users are not informed. 578 It is the responsibility of the Session Recording Server to protect 579 the Replicated Media and Media Recording Metadata once it has been 580 received and archived. 582 6. Acknowledgements 584 Thanks to John Elwell, Alan Johnson, Cullen Jennings, Hadriel Kaplan, 585 Henry Lum, Paul Kyzivat, Parthasarathi R, Ram Mohan R, Charles Eckel 586 and Friso Feenstra for their significant contributions and assistance 587 with this document and Working Group, and to all the members of the 588 SIPREC WG mailing list for providing valuable input to this work. 590 7. Informative References 592 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 593 A., Peterson, J., Sparks, R., Handley, M., and E. 594 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 595 June 2002. 597 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 598 Protocol (SIP): Locating SIP Servers", RFC 3263, 599 June 2002. 601 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 602 Description Protocol", RFC 4566, July 2006. 604 [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol 605 (SIP) "Join" Header", RFC 3911, October 2004. 607 [RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use 608 Cases and Requirements for SIP-Based Media Recording 609 (SIPREC)", RFC 6341, August 2011. 611 [I-D.ietf-siprec-metadata] 612 R, R., Ravindran, P., and P. Kyzivat, "Session Initiation 613 Protocol (SIP) Recording Metadata", 614 draft-ietf-siprec-metadata-04 (work in progress), 615 September 2011. 617 [I-D.ietf-siprec-protocol] 618 Portman, L., Lum, H., Johnston, A., and A. Hutton, 619 "Session Recording Protocol", 620 draft-ietf-siprec-protocol-00 (work in progress), 621 August 2011. 623 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 624 Event Notification", RFC 3265, June 2002. 626 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 627 "Indicating User Agent Capabilities in the Session 628 Initiation Protocol (SIP)", RFC 3840, August 2004. 630 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 631 Session Initiation Protocol (SIP)", RFC 4353, 632 February 2006. 634 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 635 Initiation Protocol (SIP) Event Package for Conference 636 State", RFC 4575, August 2006. 638 [RFC5567] Melanchuk, T., "An Architectural Framework for Media 639 Server Control", RFC 5567, June 2009. 641 [RFC5369] Camarillo, G., "Framework for Transcoding with the Session 642 Initiation Protocol (SIP)", RFC 5369, October 2008. 644 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 645 May 2000. 647 Authors' Addresses 649 Andrew Hutton (editor) 650 Siemens Enterprise Communications 651 Hofmannstrasse 51 652 Munich D-81379 653 Germany 655 Email: andrew.hutton@siemens-enterprise.com 657 Leon Portman (editor) 658 Nice Systems 659 8 Hapnina 660 Ra'anana 43017 661 Israel 663 Email: leon.portman@nice.com 665 Rajnish Jain 666 IPC Systems 667 777 Commerce Drive 668 Fairfield, CT 06825 669 USA 671 Email: rajnish.jain@ipc.com 673 Ken Rehor 674 Cisco Systems, Inc. 675 170 West Tasman Drive 676 San Jose, CA 95134-1706 677 USA 679 Email: krehor@cisco.com