idnits 2.17.1 draft-ietf-siprec-architecture-01.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 (October 20, 2010) is 4937 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-12) exists of draft-ietf-siprec-req-03 -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) Summary: 1 error (**), 0 flaws (~~), 3 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: April 23, 2011 Nice Systems 6 R. Jain 7 IPC Systems 8 K. Rehor 9 Cisco Systems, Inc. 10 October 20, 2010 12 An Architecture for Media Recording using the Session Initiation 13 Protocol 14 draft-ietf-siprec-architecture-01 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 April 23, 2011. 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. A SIP Proxy cannot be a Session Recording Client . . . 7 69 4.1.4. Interaction with MEDIACTRL . . . . . . . . . . . . . . 7 70 4.1.5. Interaction with Conference Focus . . . . . . . . . . 8 71 4.2. Establishing the Recording Session . . . . . . . . . . . . 9 72 4.2.1. Session Recording Client Initiated Recording . . . . . 9 73 4.2.2. Session Recording Server Initiated Recording . . . . . 10 74 4.2.3. Pause/Resume Recording Session . . . . . . . . . . . . 10 75 4.2.4. Media Stream Mixing . . . . . . . . . . . . . . . . . 10 76 4.2.5. Media Transcoding . . . . . . . . . . . . . . . . . . 11 77 4.3. Media Recording Metadata . . . . . . . . . . . . . . . . . 11 78 4.3.1. Contents of recording metadata . . . . . . . . . . . . 11 79 4.3.2. Mechanisms for delivery of metadata to Session 80 Recording Server . . . . . . . . . . . . . . . . . . . 11 81 4.4. Notifications to the Recorded User Agents . . . . . . . . 12 82 4.5. Preventing the recording of a SIP session . . . . . . . . 12 83 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 84 6. Security considerations . . . . . . . . . . . . . . . . . . . 13 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 87 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 90 1. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 93 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 94 this document are to be interpreted as described in [RFC2119] and 95 indicate requirement levels for compliant mechanisms. 97 2. Definitions 99 Session Recording Server (SRS): A Session Recording Server (SRS) is 100 a SIP User Agent (UA) that acts as the sink of the recorded media. 101 An SRS is a logical function that typically archives media for 102 extended durations of time and provides interfaces for search and 103 retrieval of the archived media. An SRS is typically implemented as 104 a multi-port device that is capable of receiving media from several 105 sources simultaneously. An SRS is typically also the sink of the 106 recorded session metadata. Note that the term "Server" does not 107 imply the SRS is the server side of a signaling protocol - the SRS 108 may be the initiator of recording requests, for example. 110 Session Recording Client (SRC): A Session Recording Client (SRC) is 111 a SIP User Agent (UA) that acts as the source of the recorded media, 112 sending it to the Session Recording Server. A Session Recording 113 Client is a logical function. Its capabilities may be implemented 114 across one or more physical devices. In practice, a Session 115 Recording Client could be a personal device (such as a SIP phone), a 116 SIP Media Gateway (MG), a Session Border Controller (SBC), Media 117 Server, or an Application Server. The Session Recording Client is 118 also the source of the recorded session metadata. 120 Communication Session (CS): A SIP session created between two or 121 more UA's for the purpose of communication which may be recorded. 123 Recording Session (RS): The session created between an Session 124 Recording Client and Session Recording Server for the purpose of 125 recording a Communication Session. 127 Recording aware UA: A SIP User Agent that can at a minimum 128 understand notifications indicating that a Communication Session in 129 which it is involved is being recorded. It may also be able to 130 express preferences relating to whether a Communication session can 131 or should be recorded. 133 Media Recording Metadata (MRM): The metadata describing the 134 communication session that is required by the Session Recording 135 Server. This will include for example the identity of users that 136 participate in the Communication Session and dialog state. Typically 137 this metadata is archived with the replicated media at the Session 138 Recording Server. The media recording metadata is delivered in real- 139 time to the Session Recording Server. 141 Replicated Media: A copy of the media associated with the 142 Communication Session created by the Session Recording Client and 143 sent to the Session Recording Server. It may contain all the media 144 associated with the communication session (E.g. Audio and Video) or 145 just a subset (E.g. Audio). 147 3. Introduction 149 Session recording is a critical requirement in many communications 150 environments such as call centers and financial trading. In some of 151 these environments, all calls must be recorded for regulatory, 152 compliance, and consumer protection reasons. Recording of a session 153 is typically performed by sending a copy of a media stream to a 154 recording device. This document describes architectures for 155 deploying session recording solutions in an environment which is 156 based on the Session Initiation Protocol (SIP) the requirements for 157 which are described in [I-D.ietf-siprec-req]. 159 This document focuses on how sessions are established between a 160 Session Recording Client (SRC) and the Session Recording Server (SRS) 161 for the purpose of conveying the Replicated Media and Media Recording 162 Metadata (e.g. Identity of parties involved) relating to the 163 Communication Session. 165 Once the Replicated Media and Media Recording Metadata have been 166 received by the Session Recording Server they will typically be 167 archived for retrieval at a later time. The procedures relating to 168 the archiving and retrieval of this information in outside the scope 169 of this document. 171 This document only considers active recording, where the Session 172 Recording Client purposefully streams media to a Session Recording 173 Server. Passive recording, where a recording device detects media 174 directly from the network (E.g. using port mirroring techniques), is 175 outside the scope of this document. In addition, lawful intercept is 176 outside the scope of this document which takes account of the IETF 177 policy on wiretapping [RFC2804]. 179 The Recording Session that is established between the Session 180 Recording Client and the Session Recording Server uses the normal 181 procedures for establishing INVITE initiated dialogs as specified in 182 [RFC3261] and uses SDP for describing the media to be used during the 183 session as specified in [RFC4566]. However it is intended that some 184 extensions to SIP (E.g. Headers, Option Tags, Etc.) will be defined 185 to support the requirements for media recording. The Replicated 186 Media is required to be sent in real-time to the Session Recording 187 Server and is not buffered by the Session Recording Client to allow 188 for real-time analysis of the media by the Session Recording Server. 190 4. Session Recording Architecture 192 4.1. Location of the Session Recording Client 194 This section contains some example session recording architectures 195 showing how the Session Recording Client is a logical function that 196 can be located in or split between various physical components. 198 4.1.1. B2BUA acts as a Session Recording Client 200 A SIP B2BUA which has access to the media that is to be recorded may 201 act as a Session Recording Client. The B2BUA may already be aware 202 that a session needs to be recorded before the initial establishment 203 of the communication session or the decision to record the session 204 may occur after the session has been established. 206 If the B2BUA/SRC makes the decision to initiate the Recording Session 207 (RS) then it will initiate the establishment of a SIP Session by 208 sending an INVITE to the Session Recording Server. 210 If the Session Recording Server makes the decision to initiate the 211 recording session then it will initiate the establishment of a SIP 212 Session by sending an INVITE to the B2BUA/Session Recording Client. 214 The RS INVITE will need to contain information which identifies the 215 session as being established for the purposes of recording and 216 prevents the session from being accidently rerouted to a UA which is 217 not a SRS. 219 The B2BUA/SRC is responsible for notifying the UA's involved in the 220 communication session that the session is being recorded. 222 The B2BUA/SRC is responsible for honoring any indication from 223 recording aware UA's or through some configured policies that the 224 communication session must not be recorded. 226 +-----------+ 227 (Recording Session) | Session | 228 +----SIP-------->| Recording | 229 | | Server | 230 | +----RTP---->| (SRS) | 231 | | +-----------+ 232 V | ^ 233 +-------------+ | 234 | | | 235 | |--- MetaData -+ 236 | | 237 | B2BUA | 238 | | 239 | Session | 240 +--------+ | Recording | +---------+ 241 | |<- SIP ->| Client |<- SIP ->| | 242 | UA-A | | (SRC) | | UA-B | 243 | |<- RTP ->| |<- RTP ->| | 244 +--------+ | | +---------+ 245 +-------------+ 246 (Communication Session) (Communication Session) 248 Figure 1: B2BUA Acts as the Session Recording Client. 250 4.1.2. Endpoint acts as Session Recording Client 252 A SIP Endpoint / User Agent may act as a Session Recording Client in 253 which case the endpoint sends the Replicated Media to the Session 254 Recording Server 256 If the endpoint makes the decision to initiate the Recording Session 257 then it will initiate the establishment of a SIP Session by sending 258 an INVITE to the Session Recording Server. 260 If the Session Recording Server makes the decision to initiate the 261 Recording Session then it will initiate the establishment of a SIP 262 Session by sending an INVITE to the endpoint. 264 (Recording Session) +-----------+ 265 +----------SIP------>| | 266 | +-------RTP------>| Session | 267 | | | Recording | 268 | | + Server | 269 | | +-- Metadata -->| (SRS) | 270 | | | | | 271 | | | +-----------+ 272 | | | 273 | | | 274 | | | 275 | | | 276 V | | (Communication Session) 277 +--+------+ +---------+ 278 | |<-------SIP--------->| | 279 | UA-A | | UA-B | 280 | (SRC) |<-------RTP--------->| | 281 +---------+ +---------+ 283 Figure 2: SIP Endpoint acts as the Session Recording Client 285 4.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 4.1.4. Interaction with MEDIACTRL 293 The mediactrl architecture [RFC5567] describes an architecure 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 this architecure the AS typically uses SIP Third Party 297 Call Control (3PCC) to instruct the SIP UA's to direct the media to 298 the Media Server. 300 The Session Recording Client and Session Recording Server described 301 in this document may act as an application server as described in 302 [RFC5567] and therefore may when further decomposed be made up of an 303 application server which uses a mediactrl interface to control a 304 media server for the purpose of recording the media streams however 305 this interface is considered outside the scope of this document. 307 Session Recording Server (SRS) 308 +----------------------------------------+ 309 (Recording Session) | +-----------+ | 310 +------------SIP------>| Session | +------------+ | 311 | | | Recording |MEDIACTRL | | | 312 | | | Server |<-------->| Media | | 313 | | | / | | Server | | 314 | +-----Metadata--->| MediaCtrl | | (Recorder)| | 315 | | | |Application| | | | 316 | | | | Server | +------------+ | 317 | | | +-----------+ ^ | 318 | | +------------------------------|---------+ 319 | | +--------------- RTP ----------------------- 320 | | | 321 V | V 322 +---+------+ +---------+ 323 | |<-------SIP--------->| | 324 | UA-A | | UA-B | 325 | (SRC) |<-------RTP--------->| | 326 +----------+ +---------+ 328 (Communication Session) 330 Figure 3: Example of Session Recording Server using MEDIACTRL 332 4.1.5. Interaction with Conference Focus 334 In the case of a centralised conference a combination of the 335 conference focus and mixer [RFC4353] may act as a SRC and therefore 336 provide the SRS with the replicated media and associated media 337 recording metadata. In this arrangement the SRC is able to provide 338 media and metadata relating to each of the participants, including, 339 for example, any side conversations where the media passes through 340 the mixer 342 The conference focus may also act as a Recording Aware UA in the case 343 when one of the participants acts as a SRC. 345 In an alternative arrangement a SIP endpoint which is as a conference 346 participant can act as an SRC. The SRC will in this case have access 347 to the media and metadata relating to that particular participant and 348 may be able to obtain additional metadata from the conference focus. 349 The SRC may for example use the conference event package as described 350 in [RFC4575] or [I-D.ietf-xcon-event-package] to obtain information 351 about other participants which it provides to the SRS within the 352 media recording metadata. 354 The SRC may be involved in the conference from the very beginning or 355 may join at some later point of time. 357 4.2. Establishing the Recording Session 359 The Session Recording Client or the Session Recording Server may 360 initiate the Recording Session. 362 It should be noted that the Recording Session is a completely 363 independent from the Communication Session that is being recorded at 364 both the SIP dialog level and at the session level. For example if 365 media encryption is used for the Communication Session the Session 366 Recording Client must decrypt any media received on the Communication 367 Session and, if required, re-encrypt the media using a separate SRTP 368 key for the Recording Session before sending the media to the Session 369 Recording Server. 371 Concerning media negotiation, regular SIP/SDP capabilities should be 372 used, and existing transcoding capabilities should not be precluded 374 4.2.1. Session Recording Client Initiated Recording 376 When the Session Recording Client initiates the Recording Session for 377 the purpose of conveying media to the Session Recording Server it 378 performs the following actions. 380 o The SRC is provisioned with a URI for the SRS, which is resolved 381 through normal [RFC3263] procedures. 383 o Initiates the dialog by sending an INVITE request to the Session 384 Recording Server. The dialog is established according to the 385 normal procedures for establishing an INVITE initiated dialog as 386 specified in [RFC3261]. 388 o Include in the INVITE an indication that the session is 389 established for the purpose of recording the associated media. 390 Possible mechanisms for this include using the Require header 391 and/or a new media feature tag similar to the use of "isfocus" as 392 defined in [RFC3840] 394 o Indicate support for the recording metadata event package. 396 o If the Replicated Media is to be started immediately then the 397 Session Recording Client will include an SDP attribute of 398 "a=sendonly" for each media line or "a=inactive" if it is not 399 ready to transmit the media. 401 o The Recording Session may replicate all media associated with the 402 Communication Session or only a subset. 404 o Replicate the media streams that are to be recorded and transmit 405 the media to the Session Recording Server. 407 4.2.2. Session Recording Server Initiated Recording 409 When the Session Recording Server initiates the media recording 410 session with the Session Recording Client it performs the following 411 actions. 413 o Send an INVITE request to the Session Recording Client 415 o Include in the INVITE an indication that the session is 416 established for the purpose of recording the associated media. 417 Possible mechanisms for this include using the Require header or a 418 media feature tag similar to the use of "isfocus" as defined in 419 [RFC3840] 421 o Identify the session that is to be recorded - Possibly using the 422 Join header [RFC3911] 424 o If the Recording Session is to be started immediately then the 425 Session Recording Client will include an SDP attribute of 426 "a=recvonly" for each media line or "a=inactive" if it is not 427 ready to receive the media 429 If the Session Recording Server does not have prior knowledge of what 430 media streams are available to be recorded it can make use of an 431 offerless INVITE which allows the Session Recording Client to make 432 the initial SDP offer. 434 4.2.3. Pause/Resume Recording Session 436 The Session Recording Server or the Session Recording Client may 437 pause the recording by changing the SDP direction attribute to 438 "inactive" and resume the recording by changing the direction back to 439 "sendonly" or "recvonly" 441 4.2.4. Media Stream Mixing 443 In a basic session involving only audio there are typically two 444 audio/RTP streams between the two UA's involved transporting media in 445 each direction. When recording this media the two streams may be 446 mixed at the SRC before being transmitted to the SRS or it may be a 447 requirement of the recoding server that the media streams are not 448 mixed and are sent to the SRS as two separate streams. The case when 449 media is mixed at the SRC is simple as only a single media stream is 450 required to be sent to the SRS. However in the case when the media 451 streams are not mixed then the SDP offer sent to the SRS must 452 describe two separate media streams. 454 4.2.5. Media Transcoding 456 The communication session (CS) and the recording session (RS) are 457 negotiated separately using a standard SDP offer/answer exchange 458 which may result in the SRC having to perform media transcoding 459 between the two sessions. If the SRC is not capable of performing 460 media transcoding it may limit the media formats in the offer to the 461 SRS depending on what media is negotiated on the CS or may limit what 462 it includes in the offer on the CS if it has prior knowledge of the 463 media formats supported by the SRS. However typically the SRS will 464 be the more capable device which can provide a wide range of media 465 format options to the SRC and may also be able to make use of a media 466 transcoder as detailed in [RFC5369]. 468 4.3. Media Recording Metadata 470 4.3.1. Contents of recording metadata 472 The content of the recording metadata will be defined in a separate 473 specification and therefore the following list is just a guide to the 474 type of information that may be conveyed by the Session Recording 475 Client to the Session Recording Server in the recording metadata. 477 o Dialog identifiers for the Communication Session 479 o Identities of SIP UA's taking part in the Communication Session 481 o Dialog state of the Communication Session 483 o Session state relating to the Communication Session(i.e. sendonly, 484 inactive, sendrecv). 486 o Etc. 488 4.3.2. Mechanisms for delivery of metadata to Session Recording Server 490 The SRS obtains session recording metadata from the SRC. There are 491 several potential sources of information received from the SRC that 492 can be used by the SRS to obtain recording metadata. These 493 mechanisms include the following: 495 o SIP Headers: Metadata may be obtained from SIP Headers received 496 within the Recording Session 498 o SDP: Metadata may be obtained from within SDP [RFC4566] 500 o Event Package: The metadata may be conveyed from the SRC to SRS 501 by defining an event-package and using it with the SIP events 502 notification mechanism [RFC3265]. This allows the metadata to be 503 communicated within its own SUBSCRIBE initiated dialog as opposed 504 to being within the INVITE-initiated dialog of the Recording 505 Session. This allows for sending metadata where the CS and RS 506 lifecycles are different. 508 o INFO Package: The metadata may be conveyed from SRC to SRS by 509 defining an INFO package [I-D.ietf-sipcore-info-events]. Since 510 INFO is a mid-dialog request, this mechanism requires the metadata 511 to be communicated within the SIP INVITE RS dialog. 513 o Using Non-SIP Mechanism: The recording metadata may be conveyed 514 using some other non-SIP means (e.g. HTTP, WS-*). 516 OPEN ISSUE: SIPREC may need to choose a mechanism for metadata 517 delivery for standarisation. 519 4.4. Notifications to the Recorded User Agents 521 Typically a user that is involved in a session that is to be recorded 522 is notified by an announcement at the beginning of the session or may 523 receive some warning tones within the media. However the 524 standardization of media recording protocols when using SIP enable an 525 indication that the call is being recorded to be included in the 526 signaling associated with that communication session 528 It is the Session Recording Client that must provide a notification 529 to all users for which it is replicated received media for the 530 purpose of recording including the local user if the Session 531 Recording Client is a SIP endpoint. 533 If the Session Recording Client is aware that the remote UA is a 534 recording aware UA then it MUST notify the UA using a SIP based 535 mechanism. If the Session Recording Client is not aware that the 536 peer UA is a recording aware UA then it MUST use an in-band tone or 537 announcement to notify the remote UA. 539 4.5. Preventing the recording of a SIP session 541 A Recording Aware UA may during the initial session establishment or 542 during an established session provide one of the following 543 indications. 545 o No Recording Allowed 547 o Recording Required 549 5. IANA considerations 551 None. 553 6. Security considerations 555 The Recording Session is fundamentally a standard SIP dialog and 556 media session and therefore make use of existing SIP security 557 mechanisms for securing the Recording Session and Media Recording 558 Metadata. SRTP is used for securing the Replicated Media. 560 The intended use of this architecture is only for the case where the 561 users are aware of that they are being recorded and the architecture 562 provides the means for the Session Recording Client to notify users 563 that they are being recorded. 565 This architectural solution is not intended to support lawful 566 intercept which in contrast requires that users are not informed. 568 The Session Recording Client fact that the Recording Client decrypts 569 and re-encrypts media, means the Session Recording Client must take 570 precautions to prevent disclosure of media in the clear. Also the 571 Session Recording Client has to be trusted not to manipulate or 572 suppress media. 574 It is the responsibility of the Session Recording Server to protect 575 the Replicated Media and Media Recording Metadata once it has been 576 received and archived. 578 7. References 580 7.1. Normative References 582 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 583 A., Peterson, J., Sparks, R., Handley, M., and E. 584 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 585 June 2002. 587 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 588 Protocol (SIP): Locating SIP Servers", RFC 3263, 589 June 2002. 591 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 592 Description Protocol", RFC 4566, July 2006. 594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, March 1997. 597 [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol 598 (SIP) "Join" Header", RFC 3911, October 2004. 600 7.2. Informative References 602 [I-D.ietf-siprec-req] 603 Rehor, K., Jain, R., Portman, L., and A. Hutton, 604 "Requirements for SIP-based Media Recording (SIPREC)", 605 draft-ietf-siprec-req-03 (work in progress), October 2010. 607 [I-D.ietf-sipcore-info-events] 608 Holmberg, C., Burger, E., and H. Kaplan, "Session 609 Initiation Protocol (SIP) INFO Method and Package 610 Framework", draft-ietf-sipcore-info-events-10 (work in 611 progress), October 2010. 613 [I-D.ietf-xcon-event-package] 614 Camarillo, G., Srinivasan, S., Even, R., and J. 615 Urpalainen, "Conference Event Package Data Format 616 Extension for Centralized Conferencing (XCON)", 617 draft-ietf-xcon-event-package-01 (work in progress), 618 September 2008. 620 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 621 Event Notification", RFC 3265, June 2002. 623 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 624 "Indicating User Agent Capabilities in the Session 625 Initiation Protocol (SIP)", RFC 3840, August 2004. 627 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 628 Session Initiation Protocol (SIP)", RFC 4353, 629 February 2006. 631 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 632 Initiation Protocol (SIP) Event Package for Conference 633 State", RFC 4575, August 2006. 635 [RFC5567] Melanchuk, T., "An Architectural Framework for Media 636 Server Control", RFC 5567, June 2009. 638 [RFC5369] Camarillo, G., "Framework for Transcoding with the Session 639 Initiation Protocol (SIP)", RFC 5369, October 2008. 641 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 642 May 2000. 644 Authors' Addresses 646 Andrew Hutton 647 Siemens Enterprise Communications 648 Hofmannstrasse 51 649 Munich D-81379 650 Germany 652 Email: andrew.hutton@siemens-enterprise.com 654 Leon Portman 655 Nice Systems 656 8 Hapnina 657 Ra'anana 43017 658 Israel 660 Email: leon.portman@nice.com 662 Rajnish Jain 663 IPC Systems 664 777 Commerce Drive 665 Fairfield, CT 06825 666 USA 668 Email: rajnish.jain@ipc.com 670 Ken Rehor 671 Cisco Systems, Inc. 672 170 West Tasman Drive 673 San Jose, CA 95134-1706 674 USA 676 Email: krehor@cisco.com