idnits 2.17.1 draft-ietf-siprec-architecture-08.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 (May 23, 2013) is 3983 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-22) exists of draft-ietf-siprec-metadata-11 == Outdated reference: A later version (-18) exists of draft-ietf-siprec-protocol-10 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 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 Communications 4 Intended status: Informational L. Portman, Ed. 5 Expires: November 24, 2013 NICE Systems 6 R. Jain 7 IPC Systems 8 K. Rehor 9 Cisco Systems, Inc. 10 May 23, 2013 12 An Architecture for Media Recording using the Session Initiation 13 Protocol 14 draft-ietf-siprec-architecture-08 16 Abstract 18 Session recording is a critical requirement in many communications 19 environments such as call centers and financial trading. In some of 20 these environments, all calls must be recorded for regulatory, 21 compliance, and consumer protection reasons. Recording of a session 22 is typically performed by sending a copy of a media stream to a 23 recording device. This document describes architectures for 24 deploying session recording solutions in an environment which is 25 based on the Session Initiation Protocol (SIP). 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 24, 2013. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Session Recording Architecture . . . . . . . . . . . . . . . 5 64 3.1. Location of the Session Recording Client . . . . . . . . 5 65 3.1.1. B2BUA acts as a Session Recording Client . . . . . . 5 66 3.1.2. Endpoint acts as Session Recording Client . . . . . . 7 67 3.1.3. A SIP Proxy cannot be a Session Recording Client . . 7 68 3.1.4. Interaction with MEDIACTRL . . . . . . . . . . . . . 8 69 3.1.5. Interaction with Conference Focus . . . . . . . . . . 9 70 3.2. Establishing the Recording Session . . . . . . . . . . . 10 71 3.2.1. Session Recording Client Initiated Recording . . . . 11 72 3.2.2. Session Recording Server Initiated Recording . . . . 11 73 3.2.3. Pause/Resume Recording Session . . . . . . . . . . . 12 74 3.2.4. Media Stream Mixing . . . . . . . . . . . . . . . . . 12 75 3.2.5. Media Transcoding . . . . . . . . . . . . . . . . . . 12 76 3.3. Recording Metadata . . . . . . . . . . . . . . . . . . . 13 77 3.3.1. Contents of recording metadata . . . . . . . . . . . 13 78 3.3.2. Mechanisms for delivery of metadata to Session 79 Recording Server . . . . . . . . . . . . . . . . . . 13 80 3.4. Notifications to the Recorded User Agents . . . . . . . . 13 81 3.5. Preventing the recording of a SIP session . . . . . . . . 13 82 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 83 5. Security considerations . . . . . . . . . . . . . . . . . . . 14 84 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 85 7. Informative References . . . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 88 1. Introduction 90 Session recording is a critical requirement in many communications 91 environments such as call centers and financial trading. In some of 92 these environments, all calls must be recorded for regulatory, 93 compliance, and consumer protection reasons. Recording of a session 94 is typically performed by sending a copy of a media stream to a 95 recording device. This document describes architectures for 96 deploying session recording solutions in an environment which is 97 based on the Session Initiation Protocol (SIP) the requirements for 98 which are described in [RFC6341]. 100 This document focuses on how sessions are established between a 101 Session Recording Client (SRC) and the Session Recording Server (SRS) 102 for the purpose of conveying the Replicated Media and Recording 103 Metadata (e.g. Identity of parties involved) relating to the 104 Communication Session. 106 Once the Replicated Media and Recording Metadata have been received 107 by the Session Recording Server they will typically be archived for 108 retrieval at a later time. The procedures relating to the archiving 109 and retrieval of this information is outside the scope of this 110 document. 112 This document only considers active recording, where the Session 113 Recording Client purposefully streams media to a Session Recording 114 Server. Passive recording, where a recording device detects media 115 directly from the network (E.g. using port mirroring techniques), is 116 outside the scope of this document. In addition, lawful intercept is 117 outside the scope of this document which takes account of the IETF 118 policy on wiretapping [RFC2804]. 120 The Recording Session that is established between the Session 121 Recording Client and the Session Recording Server uses the normal 122 procedures for establishing INVITE initiated dialogs as specified in 123 [RFC3261] and uses SDP for describing the media to be used during the 124 session as specified in [RFC4566]. However it is intended that some 125 extensions to SIP (E.g. Headers, Option Tags, Etc.) will be defined 126 to support the requirements for media recording. The Replicated 127 Media is required to be sent in real-time to the Session Recording 128 Server and is not buffered by the Session Recording Client to allow 129 for real-time analysis of the media by the Session Recording Server. 131 2. Definitions 133 Session Recording Server (SRS): A Session Recording Server (SRS) is a 134 SIP User Agent (UA) that is a specialized media server or collector 135 that acts as the sink of the recorded media. An SRS is typically 136 implemented as a multi-port device that is capable of receiving media 137 from multiple sources simultaneously. An SRS is the sink of the 138 communication session metadata. 140 Session Recording Client (SRC): A Session Recording Client (SRC) is a 141 SIP User Agent (UA) that acts as the source of the recorded media, 142 sending it to the SRS. An SRC is a logical function. Its 143 capabilities may be implemented across one or more physical devices. 144 In practice, an SRC could be a personal device (such as a SIP phone), 145 a SIP Media Gateway (MG), a Session Border Controller (SBC) or a SIP 146 Media Server (MS) integrated with an Application Server (AS). This 147 specification defines the term SRC such that all such SIP entities 148 can be generically addressed under one definition. The SRC provides 149 comunication session metadata to the SRS. 151 Communication Session (CS): A session created between two or more SIP 152 User Agents (UAs) that is the subject of recording. 154 Recording Session (RS): The SIP session created between an SRC and 155 SRS for the purpose of recording a Communication Session. 157 Recording aware User Agent (UA): A SIP User Agent that is aware of 158 SIP extensions associated with the Communication Session. Such 159 extensions may be used to notify the Recording aware UA that a 160 session is being recorded, or by a Recording aware UA to express 161 preferences as to whether a recording should be started, paused, 162 resumed or stopped. 164 Recording unaware User Agent (UA): A SIP User Agent that is unaware 165 of SIP extensions associated with the Communication Session. Such 166 Recording unaware UA will be notified that a session is being 167 recorded or express preferences as to whether a recording should be 168 started, paused, resumed or stopped via some other means that is out 169 of scope of SIPREC. 171 Recording Metadata: The metadata describing the communication session 172 that is required by the Session Recording Server. This will include 173 for example the identity of users that participate in the 174 Communication Session and dialog state. Typically this metadata is 175 archived with the replicated media at the Session Recording Server. 176 The recording metadata is delivered in real-time to the Session 177 Recording Server. 179 Replicated Media: A copy of the media associated with the 180 Communication Session created by the Session Recording Client and 181 sent to the Session Recording Server. It may contain all the media 182 associated with the communication session (E.g. Audio and Video) or 183 just a subset (E.g. Audio). Replicated Media is part of Recording 184 Session. 186 3. Session Recording Architecture 188 3.1. Location of the Session Recording Client 190 This section contains some example session recording architectures 191 showing how the Session Recording Client is a logical function that 192 can be located in or split between various physical components. 194 3.1.1. B2BUA acts as a Session Recording Client 196 A SIP Back to Back User Agent (B2BUA) which has access to the media 197 that is to be recorded may act as a Session Recording Client. The 198 B2BUA may already be aware that a session needs to be recorded before 199 the initial establishment of the communication session or the 200 decision to record the session may occur after the session has been 201 established. 203 If the SRC makes the decision to initiate the Recording Session (RS), 204 then it will initiate the establishment of a SIP RS by sending an 205 INVITE to the SRS. 207 If the SRS makes the decision to initiate the recording session, then 208 it will initiate the establishment of a SIP RS by sending an INVITE 209 to the SRC. 211 The RS INVITE contains information which identifies the session as 212 being established for the purposes of recording and prevents the 213 session from being accidentally rerouted to a UA which is not an SRS 214 if the RS was initiated by SRC or vice-versa. 216 The B2BUA/SRC is responsible for notifying the UAs involved in the 217 communication session that the session is being recorded. 219 The B2BUA/SRC is responsible for complying with requests from 220 recording aware UAs or through some configured policies indicating 221 that the communication session should not be recorded. 223 +-----------+ 224 (Recording Session) | Session | 225 +------SIP------>| Recording | 226 | | Server | 227 | +--RTP/RTCP-->| (SRS) | 228 | | +-----------+ 229 V V ^ 230 +-------------+ | 231 | | | 232 | |-- Metadata -+ 233 | | 234 | B2BUA | 235 | | 236 | Session | 237 +--------+ | Recording | +---------+ 238 | |<- SIP ->| Client |<- SIP ->| | 239 | UA-A | | (SRC) | | UA-B | 240 | |<- RTP/->| |<- RTP/->| | 241 +--------+ RTCP | | RTCP +---------+ 242 +-------------+ 243 |____________________________________________________| 244 (Communication Session) 246 Figure 1: B2BUA Acts as the Session Recording Client. 248 3.1.2. Endpoint acts as Session Recording Client 250 A SIP Endpoint / UA may act as a Session Recording Client in which 251 case the endpoint sends the Replicated Media to the Session Recording 252 Server 254 If the endpoint makes the decision to initiate the Recording Session 255 then it will initiate the establishment of a SIP Session by sending 256 an INVITE to the Session Recording Server. 258 If the Session Recording Server makes the decision to initiate the 259 Recording Session then it will initiate the establishment of a SIP 260 Session by sending an INVITE to the endpoint. The actual decision 261 mechanism is out of scope of SIPREC. 263 (Recording Session) +-----------+ 264 +----------SIP------>| | 265 | +----RTP/RTCP---->| Session | 266 | | | Recording | 267 | | | Server | 268 | | +-- Metadata -->| (SRS) | 269 | | | | | 270 | | | +-----------+ 271 | | | 272 | | | 273 | | | 274 | | | 275 V V | (Communication Session) 276 +--+------+ +---------+ 277 | |<-------SIP--------->| | 278 | UA-A | | UA-B | 279 | (SRC) |<-----RTP/RTCP------>| | 280 +---------+ +---------+ 282 Figure 2: SIP Endpoint acts as the Session Recording Client 284 3.1.3. A SIP Proxy cannot be a Session Recording Client 286 A SIP Proxy is unable to act as an SRC because it does not have 287 access to the media and therefore has no way of enabling the delivery 288 of the replicated media to the SRS 290 3.1.4. Interaction with MEDIACTRL 292 The MEDIACTRL architecture [RFC5567] describes an architecture in 293 which an Application Server (AS) controls a Media Server (MS) which 294 may be used for purposes such as conferencing and recording media 295 streams. In the [RFC5567] architecure the AS typically uses SIP 296 Third Party Call Control (3PCC) to instruct the SIP UAs to direct 297 their media to the Media Server. 299 The SRC or the SRS described in this document may be architected 300 according to [RFC5567]; and therefore, when further decomposed, they 301 may be made up of an application server (AS) which uses a mediactrl 302 interface to control a media server (MS). 304 As shown in figure 3, when the SRS is architected according to 305 [RFC5567] the MS acts as a sink of the recording media and the AS 306 acts as a sink of the metadata and the termination point for RS SIP 307 signaling. As shown in figure 4, when the SRC is architected 308 according to [RFC5567] the MS acts as a source of recording media and 309 the AS acts as a sink of the metadata and the termination point for 310 RS SIP signaling. 312 Session Recording Server (SRS) 313 +----------------------------------------+ 314 | | 315 (Recording Session) | +-----------+ +------------+ | 316 +------------SIP----|->| | | | | 317 | | | MEDIACTRL |MEDIACTRL | Media | | 318 | | |Application|<-------->| Server | | 319 | +-----Metadata--->| Server | | (Recorder)| | 320 | | | | | | | | 321 | | | +-----------+ +------------+ | 322 | | | ^ | 323 | | +------------------------------|---------+ 324 | | +--------------- RTP/RTCP -----------------+ 325 | | | 326 V | V 327 +---+------+ +---------+ 328 | |<-------SIP-------------->| | 329 | UA-A | (Communication Session) | UA-B | 330 | (SRC) |<-------RTP/RTCP--------->| | 331 +----------+ +---------+ 333 Figure 3: Example of Session Recording Server using MEDIACTRL 334 +----------+ 335 (Recording Session) | Session | 336 +-----------SIP------------------------->|Recording | 337 | +----------Metadata------------------->| Server | 338 | | | (SRS) | 339 V | UA-A Session Recording Client (SRC) +----------+ 340 +----------------------------------------+ ^ 341 | | | 342 | +-----------+ +------------+ | | 343 | | | Control | |<-RTP/RTCP-+ +---------+ 344 | | UA | Protocol | Media | | | | 345 | |Application|<-------->| Server | |<----SIP----->| UA-B | 346 | | Server | | |<-----RTP------>| | 347 | | | | | | +---------+ 348 | +-----------+ +------------+ | 349 | | 350 +----------------------------------------+ 351 Figure 4: Example of Session Recording Client decomposition 353 3.1.5. Interaction with Conference Focus 355 In the case of a centralised conference a combination of the 356 conference focus and mixer [RFC4353] may act as a SRC and therefore 357 provide the SRS with the replicated media and associated recording 358 metadata. In this arrangement the SRC is able to provide media and 359 metadata relating to each of the participants, including, for 360 example, any side conversations where the media passes through the 361 mixer. 363 Conference Focus can either provide mixed replicated media or 364 separate streams per conference participant (as depicted in the 365 Figure 5). 367 The conference focus may also act as a Recording Aware UA in the case 368 when one of the participants acts as a SRC. 370 In an alternative arrangement a SIP endpoint which is a conference 371 participant can act as an SRC. The SRC will in this case have access 372 to the media and metadata relating to that particular participant and 373 may be able to obtain additional metadata from the conference focus. 374 The SRC may for example use the conference event package as described 375 in [RFC4575] to obtain information about other participants which it 376 provides to the SRS within the recording metadata. 378 The SRC may be involved in the conference from the very beginning or 379 may join at some later point of time. 381 User 1 382 +-----------+ 383 | | 384 | | 385 |Participant| 386 | 1 | 387 | | 388 +-----------+ 389 ^ ^SIP 390 RTP | |Dialog 391 | |1 392 User 2 V V Recording 393 +-----------+ +-----------+ Session ************* 394 | | | |<------------>* * 395 | |<-- RTP -->| |<-RTP/RTCP 1->* * 396 |Participant|<--------->| Focus/SRC |<-RTP/RTCP 2->* SRS * 397 | 2 | SIP | |<-RTP/RTCP 3->* * 398 | | Dialog | | * * 399 +-----------+ 2 +-----------+ ************* 400 ^ ^ 401 | |SIP 402 RTP | |Dialog 403 | |3 404 V V 405 +-----------+ 406 | | 407 | | 408 |Participant| 409 | 3 | 410 | | 411 +-----------+ 412 User 3 414 Figure 5: Conference Focus acting as an SRC. 416 3.2. Establishing the Recording Session 418 The Session Recording Client or the Session Recording Server may 419 initiate the Recording Session. 421 It should be noted that the Recording Session is independent from the 422 Communication Session that is being recorded at both the SIP dialog 423 level and at the session level. 425 Concerning media negotiation, regular SIP/SDP capabilities should be 426 used, and existing transcoding capabilities and media encryption 427 should not be precluded. 429 3.2.1. Session Recording Client Initiated Recording 431 When the Session Recording Client initiates the Recording Session for 432 the purpose of conveying media to the Session Recording Server it 433 performs the following actions: 435 o The SRC is provisioned with a Unified Resource Identifier (URI) 436 for the SRS, which is resolved through normal [RFC3263] 437 procedures. 439 o Initiates the dialog by sending an INVITE request to the Session 440 Recording Server. The dialog is established according to the 441 normal procedures for establishing an INVITE initiated dialog as 442 specified in [RFC3261]. 444 o Include in the INVITE an indication that the session is 445 established for the purpose of recording the associated media. 447 o If the Replicated Media is to be started immediately then the 448 Session Recording Client will include an SDP attribute of 449 "a=sendonly" for each media line or "a=inactive" if it is not 450 ready to transmit the media. 452 o The Recording Session may replicate all media associated with the 453 Communication Session or only a subset. 455 o Replicates the media streams that are to be recorded and transmits 456 the media to the Session Recording Server. 458 3.2.2. Session Recording Server Initiated Recording 460 When the Session Recording Server initiates the media recording 461 session with the Session Recording Client it performs the following 462 actions: 464 o The SRS is provisioned with a Unified Resource Identifier (URI) 465 for the SRC, which is resolved through normal [RFC3263] 466 procedures. 468 o Sends an INVITE request to the Session Recording Client 469 o Includes in the INVITE an indication that the session is 470 established for the purpose of recording the associated media. 471 Possible mechanisms for this include using the Require header or a 472 media feature tag as defined in [RFC3840]. 474 o Identifies the sessions that is to be recorded. The actual 475 mechanism of the identification depends on SRC policy. 477 o If the Recording Session is to be started immediately then the 478 Session Recording Client will include an SDP attribute of 479 "a=recvonly" for each media line or "a=inactive" if it is not 480 ready to receive the media 482 If the SRS does not have prior knowledge of what media streams are 483 available to be recorded it can make use of an offerless INVITE which 484 allows the SRC to make the initial Session Description Protocol (SDP) 485 offer. 487 3.2.3. Pause/Resume Recording Session 489 The SRS or the Session Recording Client may pause the recording by 490 changing the SDP direction attribute to "inactive" and resume the 491 recording by changing the direction back to "recvonly" or "sendonly". 493 3.2.4. Media Stream Mixing 495 In a basic session involving only audio there are typically two audio 496 /RTP streams between the two UAs involved transporting media in each 497 direction. When recording this media the two streams may be mixed at 498 the SRC before being transmitted to the SRS or it may be required 499 that the media streams are not mixed and are sent to the SRS as two 500 separate streams. The case when media is mixed at the SRC is simple 501 as only a single media stream is required to be sent to the SRS. 502 However in the case when the media streams are not mixed then the SDP 503 offer sent to the SRS must describe two separate media streams. 505 3.2.5. Media Transcoding 506 The communication session (CS) and the recording session (RS) are 507 negotiated separately using the standard SDP offer/answer exchange 508 which may result in the SRC having to perform media transcoding 509 between the two sessions. If the SRC is not capable of performing 510 media transcoding it may limit the media formats in the offer to the 511 SRS depending on what media is negotiated on the CS or may limit what 512 it includes in the offer on the CS if it has prior knowledge of the 513 media formats supported by the SRS. However typically the SRS will 514 be a more capable device which can provide a wide range of media 515 format options to the SRC and may also be able to make use of a media 516 transcoder as detailed in [RFC5369]. 518 3.3. Recording Metadata 520 3.3.1. Contents of recording metadata 522 The metadata model is defined in [I-D.ietf-siprec-metadata]. 524 3.3.2. Mechanisms for delivery of metadata to Session Recording Server 526 The SRS obtains session recording metadata from the SRC. The 527 metadata is transported via SIP based mechanisms as specified in 528 [I-D.ietf-siprec-protocol] 530 It is also possible that metadata is transported via non SIP based 531 mechanisms but these are considered out of scope. 533 It is also possible to have RS session without the metadata, in such 534 case SRS will be receiving it by some other means or not at all. 536 3.4. Notifications to the Recorded User Agents 538 Typically a user that is involved in a session that is to be recorded 539 is notified by an announcement at the beginning of the session or may 540 receive some warning tones within the media. However the 541 standardization of media recording protocols when using SIP enable an 542 indication that the call is being recorded to be included in the SIP 543 requests and responses associated with that communication session. 545 It is the Session Recording Client that provides the notification to 546 all SIP UAs for which it is replicating received media for the 547 purpose of recording including the local user if the Session 548 Recording Client is a SIP endpoint. 550 3.5. Preventing the recording of a SIP session 552 A Recording Aware UA may during the initial session establishment or 553 during an established session provide an indication of their 554 preference with regard to recording the media in the communication 555 session. The mechanism for this are specified in 556 [I-D.ietf-siprec-protocol] 558 4. IANA considerations 560 This document has no actions for IANA. This draft mentions SIP/SDP 561 extensions. The associated IANA considerations are addressed in 562 [I-D.ietf-siprec-protocol] that defines them. 564 5. Security considerations 566 The Recording Session is fundamentally a standard SIP dialog and 567 media session and therefore makes use of existing SIP security 568 mechanisms for securing the Recording Session and Recording Metadata. 570 The intended use of this architecture is only for the case where the 571 users are aware 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 Recording Metadata once it has been received 580 and archived. The mechanism for protecting the storage and retrieval 581 from the SRS is out of scope of this work. 583 Protection of the RS should not be weaker than protection of the CS, 584 and may need to be stronger because the media is retransmitted 585 (allowing more possibility for interception). This applies to both 586 the signaling and media paths. 588 It is essential that the SRC will authenticate the SRS because the 589 client must be certain that it is recording on the right recording 590 system. It is less important that the SRS authenticate the SRC, but 591 implementations must have the ability to perform mutual 592 authentication. 594 In some environments, it is desirable to not decrypt and re-encrypt 595 the media. This means the same media encryption key is negotiated 596 and used within the CS and RS. If for any reason the media are 597 decrypted on the CS, and are re-encrypted on the RS, a new key must 598 be used. 600 The retrieval mechanism for media recorded by this protocol is out of 601 scope. Implementations of retrieval mechanisms should consider the 602 security implications carefully as the retriever is not usually a 603 party to the call that was recorded. Retrievers should be 604 authenticated carefully. The crypto suites on the retrieval should 605 be no less strong than used on the RS, and may need to be stronger. 607 6. Acknowledgements 609 Thanks to John Elwell, Brian Rosen, Alan Johnson, Cullen Jennings, 610 Hadriel Kaplan, Henry Lum, Paul Kyzivat, Parthasarathi R, Ram Mohan 611 R, Charles Eckel, Friso Feenstra and Dave Higton for their 612 significant contributions and assistance with this document and 613 Working Group, and to all the members of SIPREC WG mailing list for 614 providing valuable input to this work. 616 7. Informative References 618 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 619 A., Peterson, J., Sparks, R., Handley, M., and E. 620 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 621 June 2002. 623 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 624 Protocol (SIP): Locating SIP Servers", RFC 3263, June 625 2002. 627 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 628 Description Protocol", RFC 4566, July 2006. 630 [RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use 631 Cases and Requirements for SIP-Based Media Recording 632 (SIPREC)", RFC 6341, August 2011. 634 [I-D.ietf-siprec-metadata] 635 R, R., Ravindran, P., and P. Kyzivat, "Session Initiation 636 Protocol (SIP) Recording Metadata", draft-ietf-siprec- 637 metadata-11 (work in progress), January 2013. 639 [I-D.ietf-siprec-protocol] 640 Portman, L., Lum, H., Eckel, C., Johnston, A., and A. 641 Hutton, "Session Recording Protocol", draft-ietf-siprec- 642 protocol-10 (work in progress), May 2013. 644 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 645 "Indicating User Agent Capabilities in the Session 646 Initiation Protocol (SIP)", RFC 3840, August 2004. 648 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 649 Session Initiation Protocol (SIP)", RFC 4353, February 650 2006. 652 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 653 Initiation Protocol (SIP) Event Package for Conference 654 State", RFC 4575, August 2006. 656 [RFC5567] Melanchuk, T., "An Architectural Framework for Media 657 Server Control", RFC 5567, June 2009. 659 [RFC5369] Camarillo, G., "Framework for Transcoding with the Session 660 Initiation Protocol (SIP)", RFC 5369, October 2008. 662 [RFC2804] IAB IESG, "IETF Policy on Wiretapping", RFC 2804, May 663 2000. 665 Authors' Addresses 667 Andrew Hutton (editor) 668 Siemens Enterprise Communications 669 Hofmannstrasse 51 670 Munich D-81379 671 Germany 673 Email: andrew.hutton@siemens-enterprise.com 675 Leon Portman (editor) 676 NICE Systems 677 8 Hapnina 678 Ra'anana 43017 679 Israel 681 Email: leon.portman@gmail.com 683 Rajnish Jain 684 IPC Systems 685 777 Commerce Drive 686 Fairfield, CT 06825 687 USA 689 Email: rajnish.jain@outlook.com 690 Ken Rehor 691 Cisco Systems, Inc. 692 170 West Tasman Drive 693 San Jose, CA 95134-1706 694 USA 696 Email: krehor@cisco.com