idnits 2.17.1 draft-ietf-siprec-architecture-07.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 (November 21, 2012) is 4173 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-10 == Outdated reference: A later version (-18) exists of draft-ietf-siprec-protocol-08 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 4 Intended status: Informational Communications 5 Expires: May 25, 2013 L. Portman, Ed. 6 NICE Systems 7 R. Jain 8 IPC Systems 9 K. Rehor 10 Cisco Systems, Inc. 11 November 21, 2012 13 An Architecture for Media Recording using the Session Initiation 14 Protocol 15 draft-ietf-siprec-architecture-07 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 May 25, 2013. 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. Recording Metadata . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 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 Recording 104 Metadata (e.g. Identity of parties involved) relating to the 105 Communication Session. 107 Once the Replicated Media and Recording Metadata have been received 108 by the Session Recording Server they will typically be archived for 109 retrieval at a later time. The procedures relating to the archiving 110 and retrieval of this information is outside the scope of this 111 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 is a specialized media server or collector 136 that acts as the sink of the recorded media. An SRS is typically 137 implemented as a multi-port device that is capable of receiving media 138 from multiple sources simultaneously. An SRS is the sink of the 139 communication session metadata. 141 Session Recording Client (SRC): A Session Recording Client (SRC) is 142 a SIP User Agent (UA) that acts as the source of the recorded media, 143 sending it to the SRS. An SRC is a logical function. Its 144 capabilities may be implemented across one or more physical devices. 145 In practice, an SRC could be a personal device (such as a SIP phone), 146 a SIP Media Gateway (MG), a Session Border Controller (SBC) or a SIP 147 Media Server (MS) integrated with an Application Server (AS). This 148 specification defines the term SRC such that all such SIP entities 149 can be generically addressed under one definition. The SRC provides 150 comunication session metadata to the SRS. 152 Communication Session (CS): A session created between two or more 153 SIP User Agents (UAs) that is the subject of recording. 155 Recording Session (RS): The SIP session created between an SRC and 156 SRS for the purpose of recording a Communication Session. 158 Recording aware User Agent (UA): A SIP User Agent that is aware of 159 SIP extensions associated with the Communication Session. Such 160 extensions may be used to notify the Recording aware UA that a 161 session is being recorded, or by a Recording aware UA to express 162 preferences as to whether a recording should be started, paused, 163 resumed or stopped. 165 Recording unaware User Agent (UA): A SIP User Agent that is unaware 166 of SIP extensions associated with the Communication Session. Such 167 Recording unaware UA will be notified that a session is being 168 recorded or express preferences as to whether a recording should be 169 started, paused, resumed or stopped via some other means that is out 170 of scope of SIPREC. 172 Recording Metadata: The metadata describing the communication 173 session that is required by the Session Recording Server. This will 174 include for example the identity of users that participate in the 175 Communication Session and dialog state. Typically this metadata is 176 archived with the replicated media at the Session Recording Server. 177 The recording metadata is delivered in real-time to the Session 178 Recording Server. 180 Replicated Media: A copy of the media associated with the 181 Communication Session created by the Session Recording Client and 182 sent to the Session Recording Server. It may contain all the media 183 associated with the communication session (E.g. Audio and Video) or 184 just a subset (E.g. Audio). Replicated Media is part of Recording 185 Session. 187 3. Session Recording Architecture 189 3.1. Location of the Session Recording Client 191 This section contains some example session recording architectures 192 showing how the Session Recording Client is a logical function that 193 can be located in or split between various physical components. 195 3.1.1. B2BUA acts as a Session Recording Client 197 A SIP Back to Back User Agent (B2BUA) which has access to the media 198 that is to be recorded may act as a Session Recording Client. The 199 B2BUA may already be aware that a session needs to be recorded before 200 the initial establishment of the communication session or the 201 decision to record the session may occur after the session has been 202 established. 204 If the SRC makes the decision to initiate the Recording Session (RS), 205 then it will initiate the establishment of a SIP RS by sending an 206 INVITE to the SRS. 208 If the SRS makes the decision to initiate the recording session, then 209 it will initiate the establishment of a SIP RS by sending an INVITE 210 to the SRC. 212 The RS INVITE contains information which identifies the session as 213 being established for the purposes of recording and prevents the 214 session from being accidentally rerouted to a UA which is not an SRS 215 if the RS was initiated by SRC or vice-versa. 217 The B2BUA/SRC is responsible for notifying the UAs involved in the 218 communication session that the session is being recorded. 220 The B2BUA/SRC is responsible for complying with requests from 221 recording aware UAs or through some configured policies indicating 222 that the communication session should not be recorded. 224 +-----------+ 225 (Recording Session) | Session | 226 +------SIP------>| Recording | 227 | | Server | 228 | +--RTP/RTCP-->| (SRS) | 229 | | +-----------+ 230 V V ^ 231 +-------------+ | 232 | | | 233 | |-- Metadata -+ 234 | | 235 | B2BUA | 236 | | 237 | Session | 238 +--------+ | Recording | +---------+ 239 | |<- SIP ->| Client |<- SIP ->| | 240 | UA-A | | (SRC) | | UA-B | 241 | |<- RTP/->| |<- RTP/->| | 242 +--------+ RTCP | | RTCP +---------+ 243 +-------------+ 244 |____________________________________________________| 245 (Communication Session) 247 Figure 1: B2BUA Acts as the Session Recording Client. 249 3.1.2. Endpoint acts as Session Recording Client 251 A SIP Endpoint / UA may act as a Session Recording Client in which 252 case the endpoint sends the Replicated Media to the Session Recording 253 Server 255 If the endpoint makes the decision to initiate the Recording Session 256 then it will initiate the establishment of a SIP Session by sending 257 an INVITE to the Session Recording Server. 259 If the Session Recording Server makes the decision to initiate the 260 Recording Session then it will initiate the establishment of a SIP 261 Session by sending an INVITE to the endpoint. The actual decision 262 mechanism is out of scope of SIPREC. 264 (Recording Session) +-----------+ 265 +----------SIP------>| | 266 | +----RTP/RTCP---->| Session | 267 | | | Recording | 268 | | | Server | 269 | | +-- Metadata -->| (SRS) | 270 | | | | | 271 | | | +-----------+ 272 | | | 273 | | | 274 | | | 275 | | | 276 V V | (Communication Session) 277 +--+------+ +---------+ 278 | |<-------SIP--------->| | 279 | UA-A | | UA-B | 280 | (SRC) |<-----RTP/RTCP------>| | 281 +---------+ +---------+ 283 Figure 2: SIP Endpoint acts as the Session Recording Client 285 3.1.3. A SIP Proxy cannot be a Session Recording Client 287 A SIP Proxy is unable to act as an SRC because it does not have 288 access to the media and therefore has no way of enabling the delivery 289 of the replicated media to the SRS 291 3.1.4. Interaction with MEDIACTRL 293 The MEDIACTRL architecture [RFC5567] describes an architecture in 294 which an Application Server (AS) controls a Media Server (MS) which 295 may be used for purposes such as conferencing and recording media 296 streams. In the [RFC5567] architecure the AS typically uses SIP 297 Third Party Call Control (3PCC) to instruct the SIP UAs to direct 298 their media to the Media Server. 300 The SRC or the SRS described in this document may be architected 301 according to [RFC5567]; and therefore, when further decomposed, they 302 may be made up of an application server (AS) which uses a mediactrl 303 interface to control a media server (MS). 305 As shown in figure 3, when the SRS is architected according to 306 [RFC5567] the MS acts as a sink of the recording media and the AS 307 acts as a sink of the metadata and the termination point for RS SIP 308 signaling. As shown in figure 4, when the SRC is architected 309 according to [RFC5567] the MS acts as a source of recording media and 310 the AS acts as a sink of the metadata and the termination point for 311 RS SIP signaling. 313 Session Recording Server (SRS) 314 +----------------------------------------+ 315 | | 316 (Recording Session) | +-----------+ +------------+ | 317 +------------SIP----|->| | | | | 318 | | | MEDIACTRL |MEDIACTRL | Media | | 319 | | |Application|<-------->| Server | | 320 | +-----Metadata--->| Server | | (Recorder)| | 321 | | | | | | | | 322 | | | +-----------+ +------------+ | 323 | | | ^ | 324 | | +------------------------------|---------+ 325 | | +--------------- RTP/RTCP -----------------+ 326 | | | 327 V | V 328 +---+------+ +---------+ 329 | |<-------SIP-------------->| | 330 | UA-A | (Communication Session) | UA-B | 331 | (SRC) |<-------RTP/RTCP--------->| | 332 +----------+ +---------+ 334 Figure 3: Example of Session Recording Server using MEDIACTRL 335 +----------+ 336 (Recording Session) | Session | 337 +-----------SIP------------------------->|Recording | 338 | +----------Metadata------------------->| Server | 339 | | | (SRS) | 340 V | UA-A Session Recording Client (SRC) +----------+ 341 +----------------------------------------+ ^ 342 | | | 343 | +-----------+ +------------+ | | 344 | | | Control | |<-RTP/RTCP-+ +---------+ 345 | | UA | Protocol | Media | | | | 346 | |Application|<-------->| Server | |<----SIP----->| UA-B | 347 | | Server | | |<-----RTP------>| | 348 | | | | | | +---------+ 349 | +-----------+ +------------+ | 350 | | 351 +----------------------------------------+ 352 Figure 4: Example of Session Recording Client decomposition 354 3.1.5. Interaction with Conference Focus 356 In the case of a centralised conference a combination of the 357 conference focus and mixer [RFC4353] may act as a SRC and therefore 358 provide the SRS with the replicated media and associated recording 359 metadata. In this arrangement the SRC is able to provide media and 360 metadata relating to each of the participants, including, for 361 example, any side conversations where the media passes through the 362 mixer. 364 Conference Focus can either provide mixed replicated media or 365 separate streams per conference participant (as depicted in the 366 Figure 5). 368 The conference focus may also act as a Recording Aware UA in the case 369 when one of the participants acts as a SRC. 371 In an alternative arrangement a SIP endpoint which is a conference 372 participant can act as an SRC. The SRC will in this case have access 373 to the media and metadata relating to that particular participant and 374 may be able to obtain additional metadata from the conference focus. 375 The SRC may for example use the conference event package as described 376 in [RFC4575] to obtain information about other participants which it 377 provides to the SRS within the recording metadata. 379 The SRC may be involved in the conference from the very beginning or 380 may join at some later point of time. 382 User 1 383 +-----------+ 384 | | 385 | | 386 |Participant| 387 | 1 | 388 | | 389 +-----------+ 390 ^ ^SIP 391 RTP | |Dialog 392 | |1 393 User 2 V V Recording 394 +-----------+ +-----------+ Session ************* 395 | | | |<------------>* * 396 | |<-- RTP -->| |<-RTP/RTCP 1->* * 397 |Participant|<--------->| Focus/SRC |<-RTP/RTCP 2->* SRS * 398 | 2 | SIP | |<-RTP/RTCP 3->* * 399 | | Dialog | | * * 400 +-----------+ 2 +-----------+ ************* 401 ^ ^ 402 | |SIP 403 RTP | |Dialog 404 | |3 405 V V 406 +-----------+ 407 | | 408 | | 409 |Participant| 410 | 3 | 411 | | 412 +-----------+ 413 User 3 415 Figure 5: Conference Focus acting as an SRC. 417 3.2. Establishing the Recording Session 419 The Session Recording Client or the Session Recording Server may 420 initiate the Recording Session. 422 It should be noted that the Recording Session is independent from the 423 Communication Session that is being recorded at both the SIP dialog 424 level and at the session level. 426 Concerning media negotiation, regular SIP/SDP capabilities should be 427 used, and existing transcoding capabilities and media encryption 428 should not be precluded. 430 3.2.1. Session Recording Client Initiated Recording 432 When the Session Recording Client initiates the Recording Session for 433 the purpose of conveying media to the Session Recording Server it 434 performs the following actions: 436 o The SRC is provisioned with a Unified Resource Identifier (URI) 437 for the SRS, which is resolved through normal [RFC3263] 438 procedures. 440 o Initiates the dialog by sending an INVITE request to the Session 441 Recording Server. The dialog is established according to the 442 normal procedures for establishing an INVITE initiated dialog as 443 specified in [RFC3261]. 445 o Include in the INVITE an indication that the session is 446 established for the purpose of recording the associated media. 448 o If the Replicated Media is to be started immediately then the 449 Session Recording Client will include an SDP attribute of 450 "a=sendonly" for each media line or "a=inactive" if it is not 451 ready to transmit the media. 453 o The Recording Session may replicate all media associated with the 454 Communication Session or only a subset. 456 o Replicates the media streams that are to be recorded and transmits 457 the media to the Session Recording Server. 459 3.2.2. Session Recording Server Initiated Recording 461 When the Session Recording Server initiates the media recording 462 session with the Session Recording Client it performs the following 463 actions: 465 o The SRS is provisioned with a Unified Resource Identifier (URI) 466 for the SRC, which is resolved through normal [RFC3263] 467 procedures. 469 o Sends an INVITE request to the Session Recording Client 471 o Includes in the INVITE an indication that the session is 472 established for the purpose of recording the associated media. 473 Possible mechanisms for this include using the Require header or a 474 media feature tag as defined in [RFC3840]. 476 o Identifies the sessions that is to be recorded. The actual 477 mechanism of the identification depends on SRC policy. 479 o If the Recording Session is to be started immediately then the 480 Session Recording Client will include an SDP attribute of 481 "a=recvonly" for each media line or "a=inactive" if it is not 482 ready to receive the media 484 If the SRS does not have prior knowledge of what media streams are 485 available to be recorded it can make use of an offerless INVITE which 486 allows the SRC to make the initial Session Description Protocol (SDP) 487 offer. 489 3.2.3. Pause/Resume Recording Session 491 The SRS or the Session Recording Client may pause the recording by 492 changing the SDP direction attribute to "inactive" and resume the 493 recording by changing the direction back to "recvonly" or "sendonly". 495 3.2.4. Media Stream Mixing 497 In a basic session involving only audio there are typically two 498 audio/RTP streams between the two UAs involved transporting media in 499 each direction. When recording this media the two streams may be 500 mixed at the SRC before being transmitted to the SRS or it may be 501 required that the media streams are not mixed and are sent to the SRS 502 as two separate streams. The case when media is mixed at the SRC is 503 simple as only a single media stream is required to be sent to the 504 SRS. However in the case when the media streams are not mixed then 505 the SDP offer sent to the SRS must describe two separate media 506 streams. 508 3.2.5. Media Transcoding 510 The communication session (CS) and the recording session (RS) are 511 negotiated separately using the standard SDP offer/answer exchange 512 which may result in the SRC having to perform media transcoding 513 between the two sessions. If the SRC is not capable of performing 514 media transcoding it may limit the media formats in the offer to the 515 SRS depending on what media is negotiated on the CS or may limit what 516 it includes in the offer on the CS if it has prior knowledge of the 517 media formats supported by the SRS. However typically the SRS will 518 be a more capable device which can provide a wide range of media 519 format options to the SRC and may also be able to make use of a media 520 transcoder as detailed in [RFC5369]. 522 3.3. Recording Metadata 523 3.3.1. Contents of recording metadata 525 The metadata model is defined in [I-D.ietf-siprec-metadata]. 527 3.3.2. Mechanisms for delivery of metadata to Session Recording Server 529 The SRS obtains session recording metadata from the SRC. The 530 metadata is transported via SIP based mechanisms as specified in 531 [I-D.ietf-siprec-protocol] 533 It is also possible that metadata is transported via non SIP based 534 mechanisms but these are considered out of scope. 536 It is also possible to have RS session without the metadata, in such 537 case SRS will be receiving it by some other means or not at all. 539 3.4. Notifications to the Recorded User Agents 541 Typically a user that is involved in a session that is to be recorded 542 is notified by an announcement at the beginning of the session or may 543 receive some warning tones within the media. However the 544 standardization of media recording protocols when using SIP enable an 545 indication that the call is being recorded to be included in the SIP 546 requests and responses associated with that communication session. 548 It is the Session Recording Client that provides the notification to 549 all SIP UAs for which it is replicating received media for the 550 purpose of recording including the local user if the Session 551 Recording Client is a SIP endpoint. 553 3.5. Preventing the recording of a SIP session 555 A Recording Aware UA may during the initial session establishment or 556 during an established session provide an indication of their 557 preference with regard to recording the media in the communication 558 session. The mechanism for this are specified in 559 [I-D.ietf-siprec-protocol] 561 4. IANA considerations 563 This document has no actions for IANA. This draft mentions SIP/SDP 564 extensions. The associated IANA considerations are addressed in 565 [I-D.ietf-siprec-protocol] that defines them. 567 5. Security considerations 569 The Recording Session is fundamentally a standard SIP dialog and 570 media session and therefore makes use of existing SIP security 571 mechanisms for securing the Recording Session and Recording Metadata. 573 The intended use of this architecture is only for the case where the 574 users are aware that they are being recorded, and the architecture 575 provides the means for the Session Recording Client to notify users 576 that they are being recorded. 578 This architectural solution is not intended to support lawful 579 intercept which in contrast requires that users are not informed. 581 It is the responsibility of the Session Recording Server to protect 582 the Replicated Media and Recording Metadata once it has been received 583 and archived. The mechanism for protecting the storage and retrieval 584 from the SRS is out of scope of this work. 586 Protection of the RS should not be weaker than protection of the CS, 587 and may need to be stronger because the media is retransmitted 588 (allowing more possibility for interception). This applies to both 589 the signaling and media paths. 591 It is essential that the SRC will authenticate the SRS because the 592 client must be certain that it is recording on the right recording 593 system. It is less important that the SRS authenticate the SRC, but 594 implementations must have the ability to perform mutual 595 authentication. 597 In some environments, it is desirable to not decrypt and re-encrypt 598 the media. This means the same media encryption key is negotiated 599 and used within the CS and RS. If for any reason the media are 600 decrypted on the CS, and are re-encrypted on the RS, a new key must 601 be used. 603 The retrieval mechanism for media recorded by this protocol is out of 604 scope. Implementations of retrieval mechanisms should consider the 605 security implications carefully as the retriever is not usually a 606 party to the call that was recorded. Retrievers should be 607 authenticated carefully. The crypto suites on the retrieval should 608 be no less strong than used on the RS, and may need to be stronger. 610 6. Acknowledgements 612 Thanks to John Elwell, Brian Rosen, Alan Johnson, Cullen Jennings, 613 Hadriel Kaplan, Henry Lum, Paul Kyzivat, Parthasarathi R, Ram Mohan 614 R, Charles Eckel, Friso Feenstra and Dave Higton for their 615 significant contributions and assistance with this document and 616 Working Group, and to all the members of SIPREC WG mailing list for 617 providing valuable input to this work. 619 7. Informative References 621 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 622 A., Peterson, J., Sparks, R., Handley, M., and E. 623 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 624 June 2002. 626 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 627 Protocol (SIP): Locating SIP Servers", RFC 3263, 628 June 2002. 630 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 631 Description Protocol", RFC 4566, July 2006. 633 [RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use 634 Cases and Requirements for SIP-Based Media Recording 635 (SIPREC)", RFC 6341, August 2011. 637 [I-D.ietf-siprec-metadata] 638 R, R., Ravindran, P., and P. Kyzivat, "Session Initiation 639 Protocol (SIP) Recording Metadata", 640 draft-ietf-siprec-metadata-10 (work in progress), 641 November 2012. 643 [I-D.ietf-siprec-protocol] 644 Portman, L., Lum, H., Eckel, C., Johnston, A., and A. 645 Hutton, "Session Recording Protocol", 646 draft-ietf-siprec-protocol-08 (work in progress), 647 October 2012. 649 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 650 "Indicating User Agent Capabilities in the Session 651 Initiation Protocol (SIP)", RFC 3840, August 2004. 653 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 654 Session Initiation Protocol (SIP)", RFC 4353, 655 February 2006. 657 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 658 Initiation Protocol (SIP) Event Package for Conference 659 State", RFC 4575, August 2006. 661 [RFC5567] Melanchuk, T., "An Architectural Framework for Media 662 Server Control", RFC 5567, June 2009. 664 [RFC5369] Camarillo, G., "Framework for Transcoding with the Session 665 Initiation Protocol (SIP)", RFC 5369, October 2008. 667 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 668 May 2000. 670 Authors' Addresses 672 Andrew Hutton (editor) 673 Siemens Enterprise Communications 674 Hofmannstrasse 51 675 Munich D-81379 676 Germany 678 Email: andrew.hutton@siemens-enterprise.com 680 Leon Portman (editor) 681 NICE Systems 682 8 Hapnina 683 Ra'anana 43017 684 Israel 686 Email: leon.portman@gmail.com 688 Rajnish Jain 689 IPC Systems 690 777 Commerce Drive 691 Fairfield, CT 06825 692 USA 694 Email: rajnish.jain@ipc.com 696 Ken Rehor 697 Cisco Systems, Inc. 698 170 West Tasman Drive 699 San Jose, CA 95134-1706 700 USA 702 Email: krehor@cisco.com