idnits 2.17.1 draft-ietf-siprec-architecture-00.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 29, 2010) is 5049 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3550' is defined on line 586, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-12) exists of draft-ietf-siprec-req-00 == Outdated reference: A later version (-10) exists of draft-ietf-sipcore-info-events-08 -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPREC A. Hutton 3 Internet-Draft Siemens Enterprise Communications 4 Intended status: Informational L. Portman 5 Expires: December 31, 2010 Nice Systems 6 R. Jain 7 IPC Systems 8 K. Rehor 9 Cisco Systems, Inc. 10 June 29, 2010 12 An Architecture for Media Recording using the Session Initiation 13 Protocol 14 draft-ietf-siprec-architecture-00 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 December 31, 2010. 44 Copyright Notice 46 Copyright (c) 2010 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Session Recording Architecture . . . . . . . . . . . . . . . . 5 65 4.1. Location of the Session Recording Client . . . . . . . . . 5 66 4.1.1. B2BUA acts as a Session Recording Client . . . . . . . 5 67 4.1.2. Endpoint acts as Session Recording Client . . . . . . 6 68 4.1.3. Interaction with MEDIACTRL . . . . . . . . . . . . . . 7 69 4.1.4. Interaction with Conference Focus . . . . . . . . . . 8 70 4.2. Establishing the Recording Session . . . . . . . . . . . . 8 71 4.2.1. Session Recording Client Initiated Recording . . . . . 9 72 4.2.2. Session Recording Server Initiated Recording . . . . . 10 73 4.2.3. Pause/Resume Recording Session . . . . . . . . . . . . 10 74 4.2.4. Media Stream Mixing . . . . . . . . . . . . . . . . . 10 75 4.2.5. Media Transcoding . . . . . . . . . . . . . . . . . . 11 76 4.3. Media Recording Metadata . . . . . . . . . . . . . . . . . 11 77 4.3.1. Contents of recording metadata . . . . . . . . . . . . 11 78 4.3.2. Mechanisms for delivery of metadata to Session 79 Recording Server . . . . . . . . . . . . . . . . . . . 11 80 4.4. Notifications to the Recorded User Agents . . . . . . . . 12 81 4.5. Preventing the recording of a SIP session . . . . . . . . 12 82 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 83 6. Security considerations . . . . . . . . . . . . . . . . . . . 13 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 86 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 89 1. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 92 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 93 this document are to be interpreted as described in [RFC2119] and 94 indicate requirement levels for compliant mechanisms. 96 2. Definitions 98 Session Recording Server (SRS): A Session Recording Server (SRS) is 99 a SIP User Agent (UA) that acts as the sink of the recorded media. 100 An SRS is a logical function that typically archives media for 101 extended durations of time and provides interfaces for search and 102 retrieval of the archived media. An SRS is typically implemented as 103 a multi-port device that is capable of receiving media from several 104 sources simultaneously. An SRS is typically also the sink of the 105 recorded session metadata. Note that the term "Server" does not 106 imply the SRS is the server side of a signaling protocol - the SRS 107 may be the initiator of recording requests, for example. 109 Session Recording Client (SRC): A Session Recording Client (SRC) is 110 a SIP User Agent (UA) that acts as the source of the recorded media, 111 sending it to the Session Recording Server. A Session Recording 112 Client is a logical function. Its capabilities may be implemented 113 across one or more physical devices. In practice, a Session 114 Recording Client could be a personal device (such as a SIP phone), a 115 SIP Media Gateway (MG), a Session Border Controller (SBC), Media 116 Server, or an Application Server. The Session Recording Client is 117 also the source of the recorded session metadata. 119 Communication Session (CS): A SIP session created between two or 120 more UA's for the purpose of communication which may be recorded. 122 Recording Session (RS): The session created between an Session 123 Recording Client and Session Recording Server for the purpose of 124 recording a Communication Session. 126 Recording aware UA: A SIP User Agent that can at a minimum 127 understand notifications indicating that a Communication Session in 128 which it is involved is being recorded. It may also be able to 129 express preferences relating to whether a Communication session can 130 or should be recorded. 132 Media Recording Metadata (MRM): The metadata describing the 133 communication session that is required by the Session Recording 134 Server. This will include for example the identity of users that 135 participate in the Communication Session and dialog state. Typically 136 this metadata is archived with the replicated media at the Session 137 Recording Server. The media recording metadata is delivered in real- 138 time to the Session Recording Server. 140 Replicated Media: A copy of the media associated with the 141 Communication Session created by the Session Recording Client and 142 sent to the Session Recording Server. It may contain all the media 143 associated with the communication session (E.g. Audio and Video) or 144 just a subset (E.g. Audio). 146 3. Introduction 148 Session recording is a critical requirement in many communications 149 environments such as call centers and financial trading. In some of 150 these environments, all calls must be recorded for regulatory, 151 compliance, and consumer protection reasons. Recording of a session 152 is typically performed by sending a copy of a media stream to a 153 recording device. This document describes architectures for 154 deploying session recording solutions in an environment which is 155 based on the Session Initiation Protocol (SIP) the requirements for 156 which are described in [I-D.ietf-siprec-req]. 158 This document focuses on how sessions are established between a 159 Session Recording Client (SRC) and the Session Recording Server (SRS) 160 for the purpose of conveying the Replicated Media and Media Recording 161 Metadata (e.g. Identity of parties involved) relating to the 162 Communication Session. 164 Once the Replicated Media and Media Recording Metadata have been 165 received by the Session Recording Server they will typically be 166 archived for retrieval at a later time. The procedures relating to 167 the archiving and retrieval of this information in outside the scope 168 of this document. 170 This document only considers active recording, where the Session 171 Recording Client purposefully streams media to a Session Recording 172 Server. Passive recording, where a recording device detects media 173 directly from the network (E.g. using port mirroring techniques), is 174 outside the scope of this document. In addition, lawful intercept is 175 outside the scope of this document which takes account of the IETF 176 policy on wiretapping [RFC2804]. 178 The Recording Session that is established between the Session 179 Recording Client and the Session Recording Server uses the normal 180 procedures for establishing INVITE initiated dialogs as specified in 181 [RFC3261] and uses SDP for describing the media to be used during the 182 session as specified in [RFC4566]. However it is intended that some 183 extensions to SIP (E.g. Headers, Option Tags, Etc.) will be defined 184 to support the requirements for media recording. The Replicated 185 Media is required to be sent in real-time to the Session Recording 186 Server and is not buffered by the Session Recording Client to allow 187 for real-time analysis of the media by the Session Recording Server. 189 4. Session Recording Architecture 191 4.1. Location of the Session Recording Client 193 This section contains some example session recording architectures 194 showing how the Session Recording Client is a logical function that 195 can be located in or split between various physical components. 197 4.1.1. B2BUA acts as a Session Recording Client 199 A SIP B2BUA which has access to the media that is to be recorded may 200 act as a Session Recording Client. The B2BUA may already be aware 201 that a session needs to be recorded before the initial establishment 202 of the communication session or the decision to record the session 203 may occur after the session has been established. 205 If the B2BUA/SRC makes the decision to initiate the Recording Session 206 (RS) then it will initiate the establishment of a SIP Session by 207 sending an INVITE to the Session Recording Server. 209 If the Session Recording Server makes the decision to initiate the 210 recording session then it will initiate the establishment of a SIP 211 Session by sending an INVITE to the B2BUA/Session Recording Client. 213 The RS INVITE will need to contain information which identifies the 214 session as being established for the purposes of recording and 215 prevents the session from being accidently rerouted to a UA which is 216 not a SRS. 218 The B2BUA/SRC is responsible for notifying the UA's involved in the 219 communication session that the session is being recorded. 221 The B2BUA/SRC is responsible for honoring any indication from 222 recording aware UA's or through some configured policies that the 223 communication session must not be recorded. 225 +-----------+ 226 (Recording Session) | Session | 227 +----SIP-------->| Recording | 228 | | Server | 229 | +----RTP---->| (SRS) | 230 | | +-----------+ 231 V | ^ 232 +-------------+ | 233 | | | 234 | |--- MetaData -+ 235 | | 236 | B2BUA | 237 | | 238 | Session | 239 +--------+ | Recording | +---------+ 240 | |<- SIP ->| Client |<- SIP ->| | 241 | UA-A | | (SRC) | | UA-B | 242 | |<- RTP ->| |<- RTP ->| | 243 +--------+ | | +---------+ 244 +-------------+ 245 (Communication Session) (Communication Session) 247 Figure 1: B2BUA Acts as the Session Recording Client. 249 4.1.2. Endpoint acts as Session Recording Client 251 A SIP Endpoint / User Agent may act as a Session Recording Client in 252 which case the endpoint sends the Replicated Media to the Session 253 Recording 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. 263 OPEN ISSUE - Need to state how the SRC and SRS address each other - 264 Use of GRUU etc. 266 (Recording Session) +-----------+ 267 +----------SIP------>| | 268 | +-------RTP------>| Session | 269 | | | Recording | 270 | | + Server | 271 | | +-- Metadata -->| (SRS) | 272 | | | | | 273 | | | +-----------+ 274 | | | 275 | | | 276 | | | 277 | | | 278 V | | (Communication Session) 279 +--+------+ +---------+ 280 | |<-------SIP--------->| | 281 | UA-A | | UA-B | 282 | (SRC) |<-------RTP--------->| | 283 +---------+ +---------+ 285 Figure 2: SIP Endpoint acts as the Session Recording Client 287 4.1.3. Interaction with MEDIACTRL 289 The mediactrl architecture [RFC5567] describes an architecure in 290 which an application server (AS) controls a Media Server (MS) which 291 may be used for purposes such as conferencing and recording media 292 streams. In this architecure the AS typically uses SIP Third Party 293 Call Control (3PCC) to instruct the SIP UA's to direct the media to 294 the Media Server. 296 The Session Recording Client and Session Recording Server described 297 in this document may act as an application server as described in 298 [RFC5567] and therefore may when further decomposed be made up of an 299 application server which uses a mediactrl interface to control a 300 media server for the purpose of recording the media streams however 301 this interface is considered outside the scope of this document. 303 Session Recording Server (SRS) 304 +----------------------------------------+ 305 (Recording Session) | +-----------+ | 306 +------------SIP------>| Session | +------------+ | 307 | | | Recording |MEDIACTRL | | | 308 | | | Server |<-------->| Media | | 309 | | | / | | Server | | 310 | +-----Metadata--->| MediaCtrl | | (Recorder)| | 311 | | | |Application| | | | 312 | | | | Server | +------------+ | 313 | | | +-----------+ ^ | 314 | | +------------------------------|---------+ 315 | | +--------------- RTP ----------------------- 316 | | | 317 V | V 318 +---+------+ +---------+ 319 | |<-------SIP--------->| | 320 | UA-A | | UA-B | 321 | (SRC) |<-------RTP--------->| | 322 +----------+ +---------+ 324 (Communication Session) 326 Figure 3: Example of Session Recording Server using MEDIACTRL 328 4.1.4. Interaction with Conference Focus 330 In the case of a centralised conference the conference focus 331 [RFC4353] may also act as a SRC and therefore provide the SRS with a 332 copy of the conferenced media or as a Recording Aware Client in the 333 case when recording is initiated by one of the conference 334 participants. 336 The SRC when co-located with a conference focus may provide the SRS 337 with information of all the conference participants within the 338 recording metadata and be able to correlate the media streams, in the 339 case of providing the SRS with separate streams for each participant, 340 by providing information in the metadata which identifies the media 341 stream for a given participant (E.g. SSRC). 343 4.2. Establishing the Recording Session 345 The Session Recording Client or the Session Recording Server may 346 initiate the Recording Session. 348 It should be noted that the Recording Session is a completely 349 independent from the Communication Session that is being recorded at 350 both the SIP dialog level and at the session level. For example if 351 media encryption is used for the Communication Session the Session 352 Recording Client must decrypt any media received on the Communication 353 Session and, if required, re-encrypt the media using a separate SRTP 354 key for the Recording Session before sending the media to the Session 355 Recording Server. 357 Concerning media negotiation, regular SIP/SDP capabilities should be 358 used, and existing transcoding capabilities should not be precluded 360 4.2.1. Session Recording Client Initiated Recording 362 When the Session Recording Client initiates the Recording Session for 363 the purpose of conveying media to the Session Recording Server it 364 performs the following actions. 366 o The SRC is provisioned with a URI for the SRS, which is resolved 367 through normal [RFC3263] procedures. 369 o Initiates the dialog by sending an INVITE request to the Session 370 Recording Server. The dialog is established according to the 371 normal procedures for establishing an INVITE initiated dialog as 372 specified in [RFC3261]. 374 o Include in the INVITE an indication that the session is 375 established for the purpose of recording the associated media. 376 Possible mechanisms for this include using the Require header 377 and/or a new media feature tag similar to the use of "isfocus" as 378 defined in [RFC3840] 380 o Indicate support for the recording metadata event package. 382 o If the Replicated Media is to be started immediately then the 383 Session Recording Client will include an SDP attribute of 384 "a=sendonly" for each media line or "a=inactive" if it is not 385 ready to transmit the media. 387 o The Recording Session may replicate all media associated with the 388 Communication Session or only a subset. 390 o Replicate the media streams that are to be recorded and transmit 391 the media to the Session Recording Server. 393 4.2.2. Session Recording Server Initiated Recording 395 When the Session Recording Server initiates the media recording 396 session with the Session Recording Client it performs the following 397 actions. 399 o Send an INVITE request to the Session Recording Client 401 o Include in the INVITE an indication that the session is 402 established for the purpose of recording the associated media. 403 Possible mechanisms for this include using the Require header or a 404 media feature tag similar to the use of "isfocus" as defined in 405 [RFC3840] 407 o Identify the session that is to be recorded - Possibly using the 408 Join header [RFC3911] 410 o If the Recording Session is to be started immediately then the 411 Session Recording Client will include an SDP attribute of 412 "a=recvonly" for each media line or "a=inactive" if it is not 413 ready to receive the media 415 If the Session Recording Server does not have prior knowledge of what 416 media streams are available to be recorded it can make use of an 417 offerless INVITE which allows the Session Recording Client to make 418 the initial SDP offer. 420 OPEN ISSUE: If the Session Recording Server wants to invoke 421 persistent recording (I.e. all calls) and establish the recording 422 session before the recorded session is established what are the 423 procedures for this ? 425 4.2.3. Pause/Resume Recording Session 427 The Session Recording Server or the Session Recording Client may 428 pause the recording by changing the SDP direction attribute to 429 "inactive" and resume the recording by changing the direction back to 430 "sendonly" or "recvonly" 432 4.2.4. Media Stream Mixing 434 In a basic session involving only audio there are typically two 435 audio/RTP streams between the two UA's involved transporting media in 436 each direction. When recording this media the two streams may be 437 mixed at the Session Recording Client before being transmitted to the 438 Session Recording Server or it may be a requirement of the recoding 439 server that the media streams are not mixed and are sent to the 440 Session Recording Server as two separate streams. The case when 441 media is mixed at the Session Recording Client is simple as only a 442 single media stream is required to be sent to the Session Recording 443 Server. However in the case when the media streams are not mixed 444 then the SDP offer sent to the Session Recording Server must describe 445 two separate media streams. 447 4.2.5. Media Transcoding 449 The communication session (CS) and the recording session (RS) are 450 negotiated separately using a standard SDP offer/answer exchange 451 which may result in the SRC having to perform media transcoding 452 between the two sessions. If the SRC is not capable of performing 453 media transcoding it may limit the media formats in the offer to the 454 SRS depending on what media is negotiated on the CS or may limit what 455 it includes in the offer on the CS if it has prior knowledge of the 456 media formats supported by the SRS. However typically the SRS will 457 be the more capable device which can provide a wide range of media 458 format options to the SRC and may also be able to make use of a media 459 transcoder as detailed in [RFC5369]. 461 4.3. Media Recording Metadata 463 4.3.1. Contents of recording metadata 465 The content of the recording metadata will be defined in a separate 466 specification and therefore the following list is just a guide to the 467 type of information that may be conveyed by the Session Recording 468 Client to the Session Recording Server in the recording metadata. 470 o Dialog identifiers for the Communication Session 472 o Identities of SIP UA's taking part in the Communication Session 474 o Dialog state of the Communication Session 476 o Session state relating to the Communication Session(i.e. sendonly, 477 inactive, sendrecv). 479 o Etc. 481 4.3.2. Mechanisms for delivery of metadata to Session Recording Server 483 The recording metadata definition will be described through an XML 484 schema. Typically the SRS will request metadata delivery from the 485 SRC and the SRC will following this provide unsolicited metadata 486 updates to the SRS. There are several potential mechanisms for 487 transporting metadata from SRC to SRS. They have their pros and 488 cons. These mechanisms include the following: 490 o Event Package: The metadata event XML documents may be conveyed 491 from SRC to SRS by defining an event-package and using it with the 492 SIP events notification mechanism [RFC3265]. This allows the 493 metadata to be communicated within its own SUBSCRIBE initiated 494 dialog as opposed to be in-band to the SIP INVITE RS dialog. This 495 allows for sending metadata where the CS and RS lifecycles are 496 different. 498 o INFO Package: The metadata event XML documents may be conveyed 499 from SRC to SRS by defining an INFO package 500 [I-D.ietf-sipcore-info-events]. Since INFO is a mid-dialog 501 request, this mechanism requires the metadata to be communicated 502 within the SIP INVITE RS dialog. 504 o Using Non-SIP Mechanism: The recording metadata may be conveyed 505 using some other non-SIP means (e.g. HTTP, WS-*), while still 506 adhering to the recording metadata XML. 508 4.4. Notifications to the Recorded User Agents 510 Typically a user that is involved in a session that is to be recorded 511 is notified by an announcement at the beginning of the session or may 512 receive some warning tones within the media. However the 513 standardization of media recording protocols when using SIP enable an 514 indication that the call is being recorded to be included in the 515 signaling associated with that communication session 517 It is the Session Recording Client that must provide a notification 518 to all users for which it is replicated received media for the 519 purpose of recording including the local user if the Session 520 Recording Client is a SIP endpoint. 522 If the Session Recording Client is aware that the remote UA is a 523 recording aware UA then it MUST notify the UA using a SIP based 524 mechanism. If the Session Recording Client is not aware that the 525 peer UA is a recording aware UA then it MUST use an in-band tone or 526 announcement to notify the remote UA. 528 4.5. Preventing the recording of a SIP session 530 A Recording Aware UA may include one of the following indications in 531 an INVITE request. 533 o No Recording Allowed 535 o Recording Required 537 OPEN ISSUES: How are these conveyed one possibility is to use the 538 require header so that if they are not understood the dialog will be 539 terminated. 541 5. IANA considerations 543 None. 545 6. Security considerations 547 The Recording Session is fundamentally a standard SIP dialog and 548 media session and therefore make use of existing SIP security 549 mechanisms for securing the Recording Session and Media Recording 550 Metadata. SRTP is used for securing the Replicated Media. 552 The intended use of this architecture is only for the case where the 553 users are aware of that they are being recorded and the architecture 554 provides the means for the Session Recording Client to notify users 555 that they are being recorded. 557 This architectural solution is not intended to support lawful 558 intercept which in contrast requires that users are not informed. 560 The Session Recording Client fact that the Recording Client decrypts 561 and re-encrypts media, means the Session Recording Client must take 562 precautions to prevent disclosure of media in the clear. Also the 563 Session Recording Client has to be trusted not to manipulate or 564 suppress media. 566 It is the responsibility of the Session Recording Server to protect 567 the Replicated Media and Media Recording Metadata once it has been 568 received and archived. 570 7. References 572 7.1. Normative References 574 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 575 A., Peterson, J., Sparks, R., Handley, M., and E. 576 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 577 June 2002. 579 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 580 Protocol (SIP): Locating SIP Servers", RFC 3263, 581 June 2002. 583 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 584 Description Protocol", RFC 4566, July 2006. 586 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 587 Jacobson, "RTP: A Transport Protocol for Real-Time 588 Applications", STD 64, RFC 3550, July 2003. 590 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 591 Requirement Levels", BCP 14, RFC 2119, March 1997. 593 [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol 594 (SIP) "Join" Header", RFC 3911, October 2004. 596 7.2. Informative References 598 [I-D.ietf-siprec-req] 599 Rehor, K., Jain, R., Portman, L., and A. Hutton, 600 "Requirements for SIP-based Media Recording (SIPREC)", 601 draft-ietf-siprec-req-00 (work in progress), May 2010. 603 [I-D.ietf-sipcore-info-events] 604 Holmberg, C., Burger, E., and H. Kaplan, "Session 605 Initiation Protocol (SIP) INFO Method and Package 606 Framework", draft-ietf-sipcore-info-events-08 (work in 607 progress), May 2010. 609 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 610 Event Notification", RFC 3265, June 2002. 612 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 613 "Indicating User Agent Capabilities in the Session 614 Initiation Protocol (SIP)", RFC 3840, August 2004. 616 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 617 Session Initiation Protocol (SIP)", RFC 4353, 618 February 2006. 620 [RFC5567] Melanchuk, T., "An Architectural Framework for Media 621 Server Control", RFC 5567, June 2009. 623 [RFC5369] Camarillo, G., "Framework for Transcoding with the Session 624 Initiation Protocol (SIP)", RFC 5369, October 2008. 626 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 627 May 2000. 629 Authors' Addresses 631 Andrew Hutton 632 Siemens Enterprise Communications 633 KG Hofmannstrasse 51 634 Munich D-81379 635 Germany 637 Email: andrew.hutton@siemens-enterprise.com 639 Leon Portman 640 Nice Systems 641 8 Hapnina 642 Ra'anana 43017 643 Israel 645 Email: leon.portman@nice.com 647 Rajnish Jain 648 IPC Systems 649 777 Commerce Drive 650 Fairfield, CT 06825 651 USA 653 Email: rajnish.jain@ipc.com 655 Ken Rehor 656 Cisco Systems, Inc. 657 170 West Tasman Drive 658 San Jose, CA 95134-1706 659 USA 661 Email: krehor@cisco.com