idnits 2.17.1 draft-ietf-siprec-architecture-12.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 (February 27, 2014) is 3709 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-15 == Outdated reference: A later version (-18) exists of draft-ietf-siprec-protocol-12 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 Unify 4 Intended status: Informational L. Portman, Ed. 5 Expires: August 31, 2014 NICE Systems 6 R. Jain 7 IPC Systems 8 K. Rehor 9 Cisco Systems, Inc. 10 February 27, 2014 12 An Architecture for Media Recording using the Session Initiation 13 Protocol 14 draft-ietf-siprec-architecture-12 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 August 31, 2014. 44 Copyright Notice 46 Copyright (c) 2014 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 SRC . . . . . . . . . . . . . . . . . . . 5 65 3.1.1. B2BUA acts as a SRC . . . . . . . . . . . . . . . . . 5 66 3.1.2. Endpoint acts as SRC . . . . . . . . . . . . . . . . 7 67 3.1.3. A SIP Proxy cannot be a SRC . . . . . . . . . . . . . 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. SRC Initiated Recording . . . . . . . . . . . . . . . 11 72 3.2.2. SRS 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.2.6. Lossless Recording . . . . . . . . . . . . . . . . . 12 77 3.3. Recording Metadata . . . . . . . . . . . . . . . . . . . 13 78 3.3.1. Contents of recording metadata . . . . . . . . . . . 13 79 3.3.2. Mechanisms for delivery of metadata to SRS . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 13 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 as defined in "Use Cases and 97 Requirements for SIP-Based Media Recording (SIPREC)" [RFC6341]. 99 This document focuses on how sessions are established between a 100 Session Recording Client (SRC) and the Session Recording Server (SRS) 101 for the purpose of conveying the Replicated Media and Recording 102 Metadata (e.g. Identity of parties involved) relating to the 103 Communication Session. 105 Once the Replicated Media and Recording Metadata have been received 106 by the SRS they will typically be archived for retrieval at a later 107 time. The procedures relating to the archiving and retrieval of this 108 information is outside the scope of this document. 110 This document only considers active recording, where the SRC 111 purposefully streams media to a SRS. Passive recording, where a 112 recording device detects media directly from the network (E.g. using 113 port mirroring techniques), is outside the scope of this document. 114 In addition, lawful intercept is outside the scope of this document 115 which takes account of the IETF policy on wiretapping [RFC2804]. 117 The Recording Session that is established between the SRC and the SRS 118 uses the normal procedures for establishing INVITE initiated dialogs 119 as specified in [RFC3261] and uses SDP for describing the media to be 120 used during the session as specified in [RFC4566]. However it is 121 intended that some extensions to SIP (E.g. Headers, Option Tags, 122 Etc.) will be defined to support the requirements for media 123 recording. The Replicated Media is required to be sent in real-time 124 to the SRS and is not buffered by the SRC to allow for real-time 125 analysis of the media by the SRS. 127 2. Definitions 129 Session Recording Server (SRS): A Session Recording Server (SRS) is a 130 SIP User Agent (UA) that is a specialized media server or collector 131 that acts as the sink of the recorded media. An SRS is typically 132 implemented as a multi-port device that is capable of receiving media 133 from multiple sources simultaneously. An SRS is the sink of the 134 communication session metadata. 136 Session Recording Client (SRC): A Session Recording Client (SRC) is a 137 SIP User Agent (UA) that acts as the source of the recorded media, 138 sending it to the SRS. An SRC is a logical function. Its 139 capabilities may be implemented across one or more physical devices. 140 In practice, an SRC could be a personal device (such as a SIP phone), 141 a SIP Media Gateway (MG), a Session Border Controller (SBC) or a SIP 142 Media Server (MS) integrated with an Application Server (AS). This 143 specification defines the term SRC such that all such SIP entities 144 can be generically addressed under one definition. The SRC provides 145 comunication session metadata to the SRS. 147 Communication Session (CS): A session created between two or more SIP 148 User Agents (UAs) that is the subject of recording. 150 Recording Session (RS): The SIP session created between an SRC and 151 SRS for the purpose of recording a CS. 153 Recording aware User Agent (UA): A SIP User Agent that is aware of 154 SIP extensions associated with the CS. Such extensions may be used 155 to notify the Recording aware UA that a session is being recorded, or 156 by a Recording aware UA to express preferences as to whether a 157 recording should be started, paused, resumed or stopped. 159 Recording unaware User Agent (UA): A SIP User Agent that is unaware 160 of SIP extensions associated with the CS. Such Recording unaware UA 161 will be notified that a session is being recorded or express 162 preferences as to whether a recording should be started, paused, 163 resumed or stopped via some other means that is out of scope for the 164 SIP media recording architecture. 166 Recording Metadata: The metadata describing the CS that is required 167 by the SRS. This will include for example the identity of users that 168 participate in the CS and dialog state. Typically this metadata is 169 archived with the Replicated Media at the SRS. The recording 170 metadata is delivered in real-time to the SRS. 172 Replicated Media: A copy of the media associated with the CS created 173 by the SRC and sent to the SRS. It may contain all the media 174 associated with the CS (e.g. Audio and Video) or just a subset (e.g. 175 Audio). Replicated Media is part of Recording Session. 177 3. Session Recording Architecture 179 3.1. Location of the SRC 181 This section contains some example session recording architectures 182 showing how the SRC is a logical function that can be located in or 183 split between various physical components. 185 3.1.1. B2BUA acts as a SRC 187 A SIP Back to Back User Agent (B2BUA) which has access to the media 188 to be recorded may act as an SRC. The B2BUA may already be aware 189 that a session needs to be recorded before the initial establishment 190 of the CS or the decision to record the session may occur after the 191 session has been established. 193 If the SRC makes the decision to initiate the RS, then it will 194 initiate the establishment of a SIP RS by sending an INVITE to the 195 SRS. 197 If the SRS makes the decision to initiate the recording session, then 198 it will initiate the establishment of a SIP RS by sending an INVITE 199 to the SRC. 201 The RS INVITE contains information which identifies the session as 202 being established for the purposes of recording and prevents the 203 session from being accidentally rerouted to a UA which is not an SRS 204 if the RS was initiated by SRC or vice-versa. 206 The B2BUA/SRC is responsible for notifying the UAs involved in the CS 207 that the session is being recorded. 209 The B2BUA/SRC is responsible for complying with requests from 210 recording aware UAs or through some configured policies indicating 211 that the CS should not be recorded. 213 +-----------+ 214 (Recording Session) | Session | 215 +------SIP------>| Recording | 216 | | Server | 217 | +--RTP/RTCP-->| (SRS) | 218 | | +-----------+ 219 V V ^ 220 +-------------+ | 221 | | | 222 | |-- Metadata -+ 223 | | 224 | B2BUA | 225 | | 226 | Session | 227 +--------+ | Recording | +---------+ 228 | |<- SIP ->| Client |<- SIP ->| | 229 | UA-A | | (SRC) | | UA-B | 230 | |<- RTP/->| |<- RTP/->| | 231 +--------+ RTCP | | RTCP +---------+ 232 +-------------+ 233 |____________________________________________________| 234 (Communication Session) 236 Figure 1: B2BUA Acts as the Session Recording Client. 238 3.1.2. Endpoint acts as SRC 240 A SIP Endpoint / UA may act as a SRC. in which case the endpoint 241 sends the Replicated Media to the SRS. 243 If the endpoint makes the decision to initiate the Recording Session 244 then it will initiate the establishment of a SIP Session by sending 245 an INVITE to the SRS. 247 If the SRS makes the decision to initiate the Recording Session then 248 it will initiate the establishment of a SIP Session by sending an 249 INVITE to the endpoint. The actual decision mechanism is out of 250 scope for the SIP media recording architecture. 252 (Recording Session) +-----------+ 253 +----------SIP------>| | 254 | +----RTP/RTCP---->| Session | 255 | | | Recording | 256 | | | Server | 257 | | +-- Metadata -->| (SRS) | 258 | | | | | 259 | | | +-----------+ 260 | | | 261 | | | 262 | | | 263 | | | 264 V V | (Communication Session) 265 +--+------+ +---------+ 266 | |<-------SIP--------->| | 267 | UA-A | | UA-B | 268 | (SRC) |<-----RTP/RTCP------>| | 269 +---------+ +---------+ 271 Figure 2: SIP Endpoint acts as the Session Recording Client 273 3.1.3. A SIP Proxy cannot be a SRC 275 A SIP Proxy is unable to act as an SRC because it does not have 276 access to the media and therefore has no way of enabling the delivery 277 of the replicated media to the SRS. 279 3.1.4. Interaction with MEDIACTRL 281 The MEDIACTRL architecture [RFC5567] describes an architecture in 282 which an Application Server (AS) controls a Media Server (MS) which 283 may be used for purposes such as conferencing and recording media 284 streams. In the [RFC5567] architecure the AS typically uses SIP 285 Third Party Call Control (3PCC) to instruct the SIP UAs to direct 286 their media to the Media Server. 288 The SRC or the SRS described in this document may be architected 289 according to [RFC5567]; and therefore, when further decomposed, they 290 may be made up of an application server (AS) which uses a mediactrl 291 interface to control a media server (MS). 293 As shown in figure 3, when the SRS is architected according to 294 [RFC5567] the MS acts as a sink of the recording media and the AS 295 acts as a sink of the metadata and the termination point for RS SIP 296 signaling. As shown in figure 4, when the SRC is architected 297 according to [RFC5567] the MS acts as a source of recording media and 298 the AS acts as a source of the metadata and the termination point for 299 RS SIP signaling. 301 Session Recording Server (SRS) 302 +----------------------------------------+ 303 | | 304 (Recording Session) | +-----------+ +------------+ | 305 +------------SIP----|->| | | | | 306 | | | MEDIACTRL |MEDIACTRL | Media | | 307 | | |Application|<-------->| Server | | 308 | +-----Metadata--->| Server | | (Recorder)| | 309 | | | | | | | | 310 | | | +-----------+ +------------+ | 311 | | | ^ | 312 | | +------------------------------|---------+ 313 | | +--------------- RTP/RTCP -----------------+ 314 | | | 315 V | V 316 +---+------+ +---------+ 317 | |<-------SIP-------------->| | 318 | UA-A | (Communication Session) | UA-B | 319 | (SRC) |<-------RTP/RTCP--------->| | 320 +----------+ +---------+ 322 Figure 3: Example of Session Recording Server using MEDIACTRL 323 +----------+ 324 (Recording Session) | Session | 325 +-----------SIP------------------------->|Recording | 326 | +----------Metadata------------------->| Server | 327 | | | (SRS) | 328 V | UA-A Session Recording Client (SRC) +----------+ 329 +----------------------------------------+ ^ 330 | | | 331 | +-----------+ +------------+ | | 332 | | | Control | |<-RTP/RTCP-+ +---------+ 333 | | UA | Protocol | Media | | | | 334 | |Application|<-------->| Server | |<----SIP----->| UA-B | 335 | | Server | | |<-----RTP------>| | 336 | | | | | | +---------+ 337 | +-----------+ +------------+ | 338 | | 339 +----------------------------------------+ 340 Figure 4: Example of Session Recording Client decomposition 342 3.1.5. Interaction with Conference Focus 344 In the case of a centralised conference a combination of the 345 conference focus and mixer [RFC4353] may act as a SRC and therefore 346 provide the SRS with the replicated media and associated recording 347 metadata. In this arrangement the SRC is able to provide media and 348 metadata relating to each of the participants, including, for 349 example, any side conversations where the media passes through the 350 mixer. 352 Conference Focus can either provide mixed replicated media or 353 separate streams per conference participant (as depicted in the 354 Figure 5). 356 The conference focus may also act as a Recording Aware UA in the case 357 when one of the participants acts as a SRC. 359 In an alternative arrangement a SIP endpoint which is a conference 360 participant can act as an SRC. The SRC will in this case have access 361 to the media and metadata relating to that particular participant and 362 may be able to obtain additional metadata from the conference focus. 363 The SRC may for example use the conference event package as described 364 in [RFC4575] to obtain information about other participants which it 365 provides to the SRS within the recording metadata. 367 The SRC may be involved in the conference from the very beginning or 368 may join at some later point of time. 370 User 1 371 +-----------+ 372 | | 373 | | 374 |Participant| 375 | 1 | 376 | | 377 +-----------+ 378 ^ ^SIP 379 RTP | |Dialog 380 | |1 381 User 2 V V Recording 382 +-----------+ +-----------+ Session ************* 383 | | | |<------------>* * 384 | |<-- RTP -->| |<-RTP/RTCP 1->* * 385 |Participant|<--------->| Focus/SRC |<-RTP/RTCP 2->* SRS * 386 | 2 | SIP | |<-RTP/RTCP 3->* * 387 | | Dialog | | * * 388 +-----------+ 2 +-----------+ ************* 389 ^ ^ 390 | |SIP 391 RTP | |Dialog 392 | |3 393 V V 394 +-----------+ 395 | | 396 | | 397 |Participant| 398 | 3 | 399 | | 400 +-----------+ 401 User 3 403 Figure 5: Conference Focus acting as an SRC. 405 3.2. Establishing the Recording Session 407 The SRC or the SRS may initiate the Recording Session. 409 It should be noted that the Recording Session is independent from the 410 CS that is being recorded at both the SIP dialog level and at the 411 session level. 413 Concerning media negotiation, regular SIP/SDP capabilities should be 414 used, and existing transcoding capabilities and media encryption 415 should not be precluded. 417 3.2.1. SRC Initiated Recording 419 When the SRC initiates the Recording Session for the purpose of 420 conveying media to the SRS it performs the following actions: 422 o The SRC is provisioned with a Unified Resource Identifier (URI) 423 for the SRS, which is resolved through normal [RFC3263] 424 procedures. 426 o Initiates the dialog by sending an INVITE request to the SRS. The 427 dialog is established according to the normal procedures for 428 establishing an INVITE initiated dialog as specified in [RFC3261]. 430 o Include in the INVITE an indication that the session is 431 established for the purpose of recording the associated media. 433 o If the Replicated Media is to be started immediately then the SRC 434 will include an SDP attribute of "a=sendonly" for each media line 435 or "a=inactive" if it is not ready to transmit the media. 437 o The Recording Session may replicate all media associated with the 438 CS or only a subset. 440 o Replicates the media streams that are to be recorded and transmits 441 the media to the SRS. 443 3.2.2. SRS Initiated Recording 445 When the SRS initiates the media recording session with the SRC it 446 performs the following actions: 448 o The SRS is provisioned with a Unified Resource Identifier (URI) 449 for the SRC, which is resolved through normal [RFC3263] 450 procedures. 452 o Sends an INVITE request to the SRC. 454 o Includes in the INVITE an indication that the session is 455 established for the purpose of recording the associated media. 457 o Identifies the sessions that are to be recorded. The actual 458 mechanism of the identification depends on SRC policy. 460 o If the Recording Session is to be started immediately then the SRS 461 will include an SDP attribute of "a=recvonly" for each media line 462 or "a=inactive" if it is not ready to receive the media. 464 If the SRS does not have prior knowledge of what media streams are 465 available to be recorded it can make use of an offerless INVITE which 466 allows the SRC to make the initial Session Description Protocol (SDP) 467 offer. 469 3.2.3. Pause/Resume Recording Session 471 The SRS or the SRC may pause the recording by changing the SDP 472 direction attribute to "inactive" and resume the recording by 473 changing the direction back to "recvonly" or "sendonly". 475 3.2.4. Media Stream Mixing 477 In a basic session involving only audio there are typically two audio 478 /RTP streams between the two UAs involved transporting media in each 479 direction. When recording this media, the two streams may be mixed 480 or not mixed at the SRC before being transmitted to the SRS. In the 481 case when they are not mixed, two separate streams are sent to the 482 SRS. In the mixed case, a single mixed media stream is sent to the 483 SRS. However, in the case when the media streams are not mixed, the 484 SDP offer sent to the SRS must describe two separate media streams. 486 3.2.5. Media Transcoding 488 The CS and the RS are negotiated separately using the standard SDP 489 offer/answer exchange which may result in the SRC having to perform 490 media transcoding between the two sessions. If the SRC is not 491 capable of performing media transcoding it may limit the media 492 formats in the offer to the SRS depending on what media is negotiated 493 on the CS or may limit what it includes in the offer on the CS if it 494 has prior knowledge of the media formats supported by the SRS. 495 However typically the SRS will be a more capable device which can 496 provide a wide range of media format options to the SRC and may also 497 be able to make use of a media transcoder as detailed in [RFC5369]. 499 3.2.6. Lossless Recording 501 Session recording may be a regulatory requirement in certain 502 communication environments. Such environments may impose a 503 requirement generally known as Lossless Recording. An overall 504 lossless recordingsolution may involve multiple layers of solutions. 505 Individual aspects of the solutions may range from administering 506 networks for appropriate QoS, reliable transmission of recorded media 507 and perhaps certain SIPREC protocol level capabilities in SRC and 508 SRS. 510 3.3. Recording Metadata 512 3.3.1. Contents of recording metadata 514 The metadata model is defined in [I-D.ietf-siprec-metadata]. 516 3.3.2. Mechanisms for delivery of metadata to SRS 518 The SRS obtains session recording metadata from the SRC. The 519 metadata is transported via SIP based mechanisms as specified in 520 [I-D.ietf-siprec-protocol] 522 It is also possible that metadata is transported via non SIP based 523 mechanisms but these are considered out of scope. 525 It is also possible to have RS session without the metadata, in such 526 case SRS will be receiving it by some other means or not at all. 528 3.4. Notifications to the Recorded User Agents 530 Typically a user that is involved in a session that is to be recorded 531 is notified by an announcement at the beginning of the session or may 532 receive some warning tones within the media. However the 533 standardization of media recording protocols when using SIP enable an 534 indication that the call is being recorded to be included in the SIP 535 requests and responses associated with that CS. 537 It is the SRC that provides the notification to all SIP UAs for which 538 it is replicating received media for the purpose of recording 539 including the local user if the SRC is a SIP endpoint. 541 3.5. Preventing the recording of a SIP session 543 A Recording Aware UA may during the initial session establishment or 544 during an established session provide an indication of their 545 preference with regard to recording the media in the CS. The 546 mechanism for this are specified in [I-D.ietf-siprec-protocol] 548 4. IANA considerations 550 This document has no actions for IANA. This draft mentions SIP/SDP 551 extensions. The associated IANA considerations are addressed in 552 [I-D.ietf-siprec-protocol] that defines them. 554 5. Security considerations 556 The Recording Session is fundamentally a standard SIP dialog and 557 media session and therefore makes use of existing SIP security 558 mechanisms for securing the Recording Session and Recording Metadata. 560 The intended use of this architecture is only for the case where the 561 users are aware that they are being recorded, and the architecture 562 provides the means for the SRC to notify users that they are being 563 recorded. 565 This architectural solution is not intended to support lawful 566 intercept which in contrast requires that users are not informed. 568 It is the responsibility of the SRS to protect the Replicated Media 569 and Recording Metadata once it has been received and archived. The 570 stored content must be protected using a cipher at least as strong 571 (or stronger) than the original content however the mechanism for 572 protecting the storage and retrieval from the SRS is out of scope of 573 this work. The keys used to store the data must also be securely 574 maintained by the SRS and should only be released, securely, to 575 authorized parties. How to secure these keys, properly authorize a 576 receiving party, or securely distribute the keying material is also 577 out of scope of this work. 579 Protection of the RS should not be weaker than protection of the CS, 580 and may need to be stronger because the media is retransmitted 581 (allowing more possibility for interception). This applies to both 582 the signaling and media paths. 584 It is essential that the SRC will authenticate the SRS because the 585 client must be certain that it is recording on the right recording 586 system. It is less important that the SRS authenticate the SRC, but 587 implementations must have the ability to perform mutual 588 authentication. 590 In some environments, it is desirable to not decrypt and re-encrypt 591 the media. This means the same media encryption key is negotiated 592 and used within the CS and RS. If for any reason the media are 593 decrypted on the CS, and are re-encrypted on the RS, a new key must 594 be used. 596 The retrieval mechanism for media recorded by this protocol is out of 597 scope. Implementations of retrieval mechanisms should consider the 598 security implications carefully as the retriever is not usually a 599 party to the call that was recorded. Retrievers should be 600 authenticated carefully. The crypto suites on the retrieval should 601 be no less strong than used on the RS, and may need to be stronger. 603 6. Acknowledgements 605 Thanks to John Elwell, Brian Rosen, Alan Johnson, Cullen Jennings, 606 Hadriel Kaplan, Henry Lum, Paul Kyzivat, Parthasarathi R, Ram Mohan 607 R, Charles Eckel, Friso Feenstra and Dave Higton for their 608 significant contributions and assistance with this document and 609 Working Group, and to all the members of SIPREC WG mailing list for 610 providing valuable input to this work. 612 7. Informative References 614 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 615 A., Peterson, J., Sparks, R., Handley, M., and E. 616 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 617 June 2002. 619 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 620 Protocol (SIP): Locating SIP Servers", RFC 3263, June 621 2002. 623 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 624 Description Protocol", RFC 4566, July 2006. 626 [RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use 627 Cases and Requirements for SIP-Based Media Recording 628 (SIPREC)", RFC 6341, August 2011. 630 [I-D.ietf-siprec-metadata] 631 R, R., Ravindran, P., and P. Kyzivat, "Session Initiation 632 Protocol (SIP) Recording Metadata", draft-ietf-siprec- 633 metadata-15 (work in progress), February 2014. 635 [I-D.ietf-siprec-protocol] 636 Portman, L., Lum, H., Eckel, C., Johnston, A., and A. 637 Hutton, "Session Recording Protocol", draft-ietf-siprec- 638 protocol-12 (work in progress), February 2014. 640 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 641 Session Initiation Protocol (SIP)", RFC 4353, February 642 2006. 644 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 645 Initiation Protocol (SIP) Event Package for Conference 646 State", RFC 4575, August 2006. 648 [RFC5567] Melanchuk, T., "An Architectural Framework for Media 649 Server Control", RFC 5567, June 2009. 651 [RFC5369] Camarillo, G., "Framework for Transcoding with the Session 652 Initiation Protocol (SIP)", RFC 5369, October 2008. 654 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 655 2000. 657 Authors' Addresses 659 Andrew Hutton (editor) 660 Unify 661 Hofmannstrasse 51 662 81359 Munich 663 Germany 665 Email: andrew.hutton@unify.com 667 Leon Portman (editor) 668 NICE Systems 669 8 Hapnina 670 Ra'anana 43017 671 Israel 673 Email: leon.portman@gmail.com 675 Rajnish Jain 676 IPC Systems 677 777 Commerce Drive 678 Fairfield, CT 06825 679 USA 681 Email: rajnish.jain@outlook.com 683 Ken Rehor 684 Cisco Systems, Inc. 685 170 West Tasman Drive 686 San Jose, CA 95134-1706 687 USA 689 Email: krehor@cisco.com