idnits 2.17.1 draft-ietf-siprec-architecture-11.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 (December 5, 2013) is 3792 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 Unify 4 Intended status: Informational L. Portman, Ed. 5 Expires: June 8, 2014 NICE Systems 6 R. Jain 7 IPC Systems 8 K. Rehor 9 Cisco Systems, Inc. 10 December 5, 2013 12 An Architecture for Media Recording using the Session Initiation 13 Protocol 14 draft-ietf-siprec-architecture-11 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 June 8, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . 7 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.3. Recording Metadata . . . . . . . . . . . . . . . . . . . 12 77 3.3.1. Contents of recording metadata . . . . . . . . . . . 12 78 3.3.2. Mechanisms for delivery of metadata to SRS . . . . . 12 79 3.4. Notifications to the Recorded User Agents . . . . . . . . 13 80 3.5. Preventing the recording of a SIP session . . . . . . . . 13 81 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 82 5. Security considerations . . . . . . . . . . . . . . . . . . . 13 83 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 84 7. Informative References . . . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 Session recording is a critical requirement in many communications 90 environments such as call centers and financial trading. In some of 91 these environments, all calls must be recorded for regulatory, 92 compliance, and consumer protection reasons. Recording of a session 93 is typically performed by sending a copy of a media stream to a 94 recording device. This document describes architectures for 95 deploying session recording solutions as defined in "Use Cases and 96 Requirements for SIP-Based Media Recording (SIPREC)" [RFC6341]. 98 This document focuses on how sessions are established between a 99 Session Recording Client (SRC) and the Session Recording Server (SRS) 100 for the purpose of conveying the Replicated Media and Recording 101 Metadata (e.g. Identity of parties involved) relating to the 102 Communication Session. 104 Once the Replicated Media and Recording Metadata have been received 105 by the SRS they will typically be archived for retrieval at a later 106 time. The procedures relating to the archiving and retrieval of this 107 information is outside the scope of this document. 109 This document only considers active recording, where the SRC 110 purposefully streams media to a SRS. Passive recording, where a 111 recording device detects media directly from the network (E.g. using 112 port mirroring techniques), is outside the scope of this document. 113 In addition, lawful intercept is outside the scope of this document 114 which takes account of the IETF policy on wiretapping [RFC2804]. 116 The Recording Session that is established between the SRC and the SRS 117 uses the normal procedures for establishing INVITE initiated dialogs 118 as specified in [RFC3261] and uses SDP for describing the media to be 119 used during the session as specified in [RFC4566]. However it is 120 intended that some extensions to SIP (E.g. Headers, Option Tags, 121 Etc.) will be defined to support the requirements for media 122 recording. The Replicated Media is required to be sent in real-time 123 to the SRS and is not buffered by the SRC to allow for real-time 124 analysis of the media by the SRS. 126 2. Definitions 128 Session Recording Server (SRS): A Session Recording Server (SRS) is a 129 SIP User Agent (UA) that is a specialized media server or collector 130 that acts as the sink of the recorded media. An SRS is typically 131 implemented as a multi-port device that is capable of receiving media 132 from multiple sources simultaneously. An SRS is the sink of the 133 communication session metadata. 135 Session Recording Client (SRC): A Session Recording Client (SRC) is a 136 SIP User Agent (UA) that acts as the source of the recorded media, 137 sending it to the SRS. An SRC is a logical function. Its 138 capabilities may be implemented across one or more physical devices. 139 In practice, an SRC could be a personal device (such as a SIP phone), 140 a SIP Media Gateway (MG), a Session Border Controller (SBC) or a SIP 141 Media Server (MS) integrated with an Application Server (AS). This 142 specification defines the term SRC such that all such SIP entities 143 can be generically addressed under one definition. The SRC provides 144 comunication session metadata to the SRS. 146 Communication Session (CS): A session created between two or more SIP 147 User Agents (UAs) that is the subject of recording. 149 Recording Session (RS): The SIP session created between an SRC and 150 SRS for the purpose of recording a CS. 152 Recording aware User Agent (UA): A SIP User Agent that is aware of 153 SIP extensions associated with the CS. Such extensions may be used 154 to notify the Recording aware UA that a session is being recorded, or 155 by a Recording aware UA to express preferences as to whether a 156 recording should be started, paused, resumed or stopped. 158 Recording unaware User Agent (UA): A SIP User Agent that is unaware 159 of SIP extensions associated with the CS. Such Recording unaware UA 160 will be notified that a session is being recorded or express 161 preferences as to whether a recording should be started, paused, 162 resumed or stopped via some other means that is out of scope for the 163 SIP media recording architecture. 165 Recording Metadata: The metadata describing the CS that is required 166 by the SRS. This will include for example the identity of users that 167 participate in the CS and dialog state. Typically this metadata is 168 archived with the Replicated Media at the SRS. The recording 169 metadata is delivered in real-time to the SRS. 171 Replicated Media: A copy of the media associated with the CS created 172 by the SRC and sent to the SRS. It may contain all the media 173 associated with the CS (e.g. Audio and Video) or just a subset (e.g. 174 Audio). Replicated Media is part of Recording Session. 176 3. Session Recording Architecture 178 3.1. Location of the SRC 180 This section contains some example session recording architectures 181 showing how the SRC is a logical function that can be located in or 182 split between various physical components. 184 3.1.1. B2BUA acts as a SRC 186 A SIP Back to Back User Agent (B2BUA) which has access to the media 187 to be recorded may act as an SRC. The B2BUA may already be aware 188 that a session needs to be recorded before the initial establishment 189 of the CS or the decision to record the session may occur after the 190 session has been established. 192 If the SRC makes the decision to initiate the RS, then it will 193 initiate the establishment of a SIP RS by sending an INVITE to the 194 SRS. 196 If the SRS makes the decision to initiate the recording session, then 197 it will initiate the establishment of a SIP RS by sending an INVITE 198 to the SRC. 200 The RS INVITE contains information which identifies the session as 201 being established for the purposes of recording and prevents the 202 session from being accidentally rerouted to a UA which is not an SRS 203 if the RS was initiated by SRC or vice-versa. 205 The B2BUA/SRC is responsible for notifying the UAs involved in the CS 206 that the session is being recorded. 208 The B2BUA/SRC is responsible for complying with requests from 209 recording aware UAs or through some configured policies indicating 210 that the CS should not be recorded. 212 +-----------+ 213 (Recording Session) | Session | 214 +------SIP------>| Recording | 215 | | Server | 216 | +--RTP/RTCP-->| (SRS) | 217 | | +-----------+ 218 V V ^ 219 +-------------+ | 220 | | | 221 | |-- Metadata -+ 222 | | 223 | B2BUA | 224 | | 225 | Session | 226 +--------+ | Recording | +---------+ 227 | |<- SIP ->| Client |<- SIP ->| | 228 | UA-A | | (SRC) | | UA-B | 229 | |<- RTP/->| |<- RTP/->| | 230 +--------+ RTCP | | RTCP +---------+ 231 +-------------+ 232 |____________________________________________________| 233 (Communication Session) 235 Figure 1: B2BUA Acts as the Session Recording Client. 237 3.1.2. Endpoint acts as SRC 239 A SIP Endpoint / UA may act as a SRC. in which case the endpoint 240 sends the Replicated Media to the SRS. 242 If the endpoint makes the decision to initiate the Recording Session 243 then it will initiate the establishment of a SIP Session by sending 244 an INVITE to the SRS. 246 If the SRS makes the decision to initiate the Recording Session then 247 it will initiate the establishment of a SIP Session by sending an 248 INVITE to the endpoint. The actual decision mechanism is out of 249 scope for the SIP media recording architecture. 251 (Recording Session) +-----------+ 252 +----------SIP------>| | 253 | +----RTP/RTCP---->| Session | 254 | | | Recording | 255 | | | Server | 256 | | +-- Metadata -->| (SRS) | 257 | | | | | 258 | | | +-----------+ 259 | | | 260 | | | 261 | | | 262 | | | 263 V V | (Communication Session) 264 +--+------+ +---------+ 265 | |<-------SIP--------->| | 266 | UA-A | | UA-B | 267 | (SRC) |<-----RTP/RTCP------>| | 268 +---------+ +---------+ 270 Figure 2: SIP Endpoint acts as the Session Recording Client 272 3.1.3. A SIP Proxy cannot be a SRC 274 A SIP Proxy is unable to act as an SRC because it does not have 275 access to the media and therefore has no way of enabling the delivery 276 of the replicated media to the SRS. 278 3.1.4. Interaction with MEDIACTRL 279 The MEDIACTRL architecture [RFC5567] describes an architecture in 280 which an Application Server (AS) controls a Media Server (MS) which 281 may be used for purposes such as conferencing and recording media 282 streams. In the [RFC5567] architecure the AS typically uses SIP 283 Third Party Call Control (3PCC) to instruct the SIP UAs to direct 284 their media to the Media Server. 286 The SRC or the SRS described in this document may be architected 287 according to [RFC5567]; and therefore, when further decomposed, they 288 may be made up of an application server (AS) which uses a mediactrl 289 interface to control a media server (MS). 291 As shown in figure 3, when the SRS is architected according to 292 [RFC5567] the MS acts as a sink of the recording media and the AS 293 acts as a sink of the metadata and the termination point for RS SIP 294 signaling. As shown in figure 4, when the SRC is architected 295 according to [RFC5567] the MS acts as a source of recording media and 296 the AS acts as a source of the metadata and the termination point for 297 RS SIP signaling. 299 Session Recording Server (SRS) 300 +----------------------------------------+ 301 | | 302 (Recording Session) | +-----------+ +------------+ | 303 +------------SIP----|->| | | | | 304 | | | MEDIACTRL |MEDIACTRL | Media | | 305 | | |Application|<-------->| Server | | 306 | +-----Metadata--->| Server | | (Recorder)| | 307 | | | | | | | | 308 | | | +-----------+ +------------+ | 309 | | | ^ | 310 | | +------------------------------|---------+ 311 | | +--------------- RTP/RTCP -----------------+ 312 | | | 313 V | V 314 +---+------+ +---------+ 315 | |<-------SIP-------------->| | 316 | UA-A | (Communication Session) | UA-B | 317 | (SRC) |<-------RTP/RTCP--------->| | 318 +----------+ +---------+ 320 Figure 3: Example of Session Recording Server using MEDIACTRL 322 +----------+ 323 (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 372 +-----------+ 373 | | 374 | | 375 |Participant| 376 | 1 | 377 | | 378 +-----------+ 379 ^ ^SIP 380 RTP | |Dialog 381 | |1 382 User 2 V V Recording 383 +-----------+ +-----------+ Session ************* 384 | | | |<------------>* * 385 | |<-- RTP -->| |<-RTP/RTCP 1->* * 386 |Participant|<--------->| Focus/SRC |<-RTP/RTCP 2->* SRS * 387 | 2 | SIP | |<-RTP/RTCP 3->* * 388 | | Dialog | | * * 389 +-----------+ 2 +-----------+ ************* 390 ^ ^ 391 | |SIP 392 RTP | |Dialog 393 | |3 394 V V 395 +-----------+ 396 | | 397 | | 398 |Participant| 399 | 3 | 400 | | 401 +-----------+ 402 User 3 404 Figure 5: Conference Focus acting as an SRC. 406 3.2. Establishing the Recording Session 408 The SRC or the SRS may initiate the Recording Session. 410 It should be noted that the Recording Session is independent from the 411 CS that is being recorded at both the SIP dialog level and at the 412 session level. 414 Concerning media negotiation, regular SIP/SDP capabilities should be 415 used, and existing transcoding capabilities and media encryption 416 should not be precluded. 418 3.2.1. SRC Initiated Recording 420 When the SRC initiates the Recording Session for the purpose of 421 conveying media to the SRS it performs the following actions: 423 o The SRC is provisioned with a Unified Resource Identifier (URI) 424 for the SRS, which is resolved through normal [RFC3263] 425 procedures. 427 o Initiates the dialog by sending an INVITE request to the SRS. The 428 dialog is established according to the normal procedures for 429 establishing an INVITE initiated dialog as specified in [RFC3261]. 431 o Include in the INVITE an indication that the session is 432 established for the purpose of recording the associated media. 434 o If the Replicated Media is to be started immediately then the SRC 435 will include an SDP attribute of "a=sendonly" for each media line 436 or "a=inactive" if it is not ready to transmit the media. 438 o The Recording Session may replicate all media associated with the 439 CS or only a subset. 441 o Replicates the media streams that are to be recorded and transmits 442 the media to the SRS. 444 3.2.2. SRS Initiated Recording 446 When the SRS initiates the media recording session with the SRC it 447 performs the following actions: 449 o The SRS is provisioned with a Unified Resource Identifier (URI) 450 for the SRC, which is resolved through normal [RFC3263] 451 procedures. 453 o Sends an INVITE request to the SRC. 455 o Includes in the INVITE an indication that the session is 456 established for the purpose of recording the associated media. 458 o Identifies the sessions that are to be recorded. The actual 459 mechanism of the identification depends on SRC policy. 461 o If the Recording Session is to be started immediately then the SRS 462 will include an SDP attribute of "a=recvonly" for each media line 463 or "a=inactive" if it is not ready to receive the media. 465 If the SRS does not have prior knowledge of what media streams are 466 available to be recorded it can make use of an offerless INVITE which 467 allows the SRC to make the initial Session Description Protocol (SDP) 468 offer. 470 3.2.3. Pause/Resume Recording Session 472 The SRS or the SRC may pause the recording by changing the SDP 473 direction attribute to "inactive" and resume the recording by 474 changing the direction back to "recvonly" or "sendonly". 476 3.2.4. Media Stream Mixing 478 In a basic session involving only audio there are typically two audio 479 /RTP streams between the two UAs involved transporting media in each 480 direction. When recording this media the two streams may be mixed or 481 not mixed at the SRC before being transmitted to the SRS. In the 482 case when they are not mixed they are sent to the SRS as two separate 483 streams and in the mixed case only a single mixed media stream is 484 sent to the SRS. However in the case when the media streams are not 485 mixed then the SDP offer sent to the SRS must describe two separate 486 media streams. 488 3.2.5. Media Transcoding 490 The CS and the RS are negotiated separately using the standard SDP 491 offer/answer exchange which may result in the SRC having to perform 492 media transcoding between the two sessions. If the SRC is not 493 capable of performing media transcoding it may limit the media 494 formats in the offer to the SRS depending on what media is negotiated 495 on the CS or may limit what it includes in the offer on the CS if it 496 has prior knowledge of the media formats supported by the SRS. 497 However typically the SRS will be a more capable device which can 498 provide a wide range of media format options to the SRC and may also 499 be able to make use of a media transcoder as detailed in [RFC5369]. 501 3.3. Recording Metadata 503 3.3.1. Contents of recording metadata 505 The metadata model is defined in [I-D.ietf-siprec-metadata]. 507 3.3.2. Mechanisms for delivery of metadata to SRS 509 The SRS obtains session recording metadata from the SRC. The 510 metadata is transported via SIP based mechanisms as specified in 511 [I-D.ietf-siprec-protocol] 512 It is also possible that metadata is transported via non SIP based 513 mechanisms but these are considered out of scope. 515 It is also possible to have RS session without the metadata, in such 516 case SRS will be receiving it by some other means or not at all. 518 3.4. Notifications to the Recorded User Agents 520 Typically a user that is involved in a session that is to be recorded 521 is notified by an announcement at the beginning of the session or may 522 receive some warning tones within the media. However the 523 standardization of media recording protocols when using SIP enable an 524 indication that the call is being recorded to be included in the SIP 525 requests and responses associated with that CS. 527 It is the SRC that provides the notification to all SIP UAs for which 528 it is replicating received media for the purpose of recording 529 including the local user if the SRC is a SIP endpoint. 531 3.5. Preventing the recording of a SIP session 533 A Recording Aware UA may during the initial session establishment or 534 during an established session provide an indication of their 535 preference with regard to recording the media in the CS. The 536 mechanism for this are specified in [I-D.ietf-siprec-protocol] 538 4. IANA considerations 540 This document has no actions for IANA. This draft mentions SIP/SDP 541 extensions. The associated IANA considerations are addressed in 542 [I-D.ietf-siprec-protocol] that defines them. 544 5. Security considerations 546 The Recording Session is fundamentally a standard SIP dialog and 547 media session and therefore makes use of existing SIP security 548 mechanisms for securing the Recording Session and Recording Metadata. 550 The intended use of this architecture is only for the case where the 551 users are aware that they are being recorded, and the architecture 552 provides the means for the SRC to notify users that they are being 553 recorded. 555 This architectural solution is not intended to support lawful 556 intercept which in contrast requires that users are not informed. 558 It is the responsibility of the SRS to protect the Replicated Media 559 and Recording Metadata once it has been received and archived. The 560 stored content must be protected using a cipher at least as strong 561 (or stronger) than the original content however the mechanism for 562 protecting the storage and retrieval from the SRS is out of scope of 563 this work. The keys used to store the data must also be securely 564 maintained by the SRS and should only be released, securely, to 565 authorized parties. How to secure these keys, properly authorize a 566 receiving party, or securely distribute the keying material is also 567 out of scope of this work. 569 Protection of the RS should not be weaker than protection of the CS, 570 and may need to be stronger because the media is retransmitted 571 (allowing more possibility for interception). This applies to both 572 the signaling and media paths. 574 It is essential that the SRC will authenticate the SRS because the 575 client must be certain that it is recording on the right recording 576 system. It is less important that the SRS authenticate the SRC, but 577 implementations must have the ability to perform mutual 578 authentication. 580 In some environments, it is desirable to not decrypt and re-encrypt 581 the media. This means the same media encryption key is negotiated 582 and used within the CS and RS. If for any reason the media are 583 decrypted on the CS, and are re-encrypted on the RS, a new key must 584 be used. 586 The retrieval mechanism for media recorded by this protocol is out of 587 scope. Implementations of retrieval mechanisms should consider the 588 security implications carefully as the retriever is not usually a 589 party to the call that was recorded. Retrievers should be 590 authenticated carefully. The crypto suites on the retrieval should 591 be no less strong than used on the RS, and may need to be stronger. 593 6. Acknowledgements 595 Thanks to John Elwell, Brian Rosen, Alan Johnson, Cullen Jennings, 596 Hadriel Kaplan, Henry Lum, Paul Kyzivat, Parthasarathi R, Ram Mohan 597 R, Charles Eckel, Friso Feenstra and Dave Higton for their 598 significant contributions and assistance with this document and 599 Working Group, and to all the members of SIPREC WG mailing list for 600 providing valuable input to this work. 602 7. Informative References 604 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 605 A., Peterson, J., Sparks, R., Handley, M., and E. 606 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 607 June 2002. 609 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 610 Protocol (SIP): Locating SIP Servers", RFC 3263, June 611 2002. 613 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 614 Description Protocol", RFC 4566, July 2006. 616 [RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use 617 Cases and Requirements for SIP-Based Media Recording 618 (SIPREC)", RFC 6341, August 2011. 620 [I-D.ietf-siprec-metadata] 621 R, R., Ravindran, P., and P. Kyzivat, "Session Initiation 622 Protocol (SIP) Recording Metadata", draft-ietf-siprec- 623 metadata-11 (work in progress), January 2013. 625 [I-D.ietf-siprec-protocol] 626 Portman, L., Lum, H., Eckel, C., Johnston, A., and A. 627 Hutton, "Session Recording Protocol", draft-ietf-siprec- 628 protocol-10 (work in progress), May 2013. 630 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 631 Session Initiation Protocol (SIP)", RFC 4353, February 632 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, May 645 2000. 647 Authors' Addresses 649 Andrew Hutton (editor) 650 Unify 651 Hofmannstrasse 51 652 81359 Munich 653 Germany 655 Email: andrew.hutton@unify.com 656 Leon Portman (editor) 657 NICE Systems 658 8 Hapnina 659 Ra'anana 43017 660 Israel 662 Email: leon.portman@gmail.com 664 Rajnish Jain 665 IPC Systems 666 777 Commerce Drive 667 Fairfield, CT 06825 668 USA 670 Email: rajnish.jain@outlook.com 672 Ken Rehor 673 Cisco Systems, Inc. 674 170 West Tasman Drive 675 San Jose, CA 95134-1706 676 USA 678 Email: krehor@cisco.com