idnits 2.17.1 draft-ietf-siprec-req-06.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 contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 31, 2010) is 4864 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4733' is mentioned on line 453, but not defined == Missing Reference: 'RFC4103' is mentioned on line 454, but not defined == Unused Reference: 'RFC2804' is defined on line 636, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DISPATCH K. Rehor, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Informational L. Portman, Ed. 5 Expires: July 4, 2011 NICE Systems 6 A. Hutton 7 Siemens Enterprise Communications 8 R. Jain 9 IPC Systems 10 December 31, 2010 12 Requirements for SIP-based Media Recording (SIPREC) 13 draft-ietf-siprec-req-06 15 Abstract 17 Session recording is a critical requirement in many business 18 communications environments such as call centers and financial 19 trading floors. In some of these environments, all calls must be 20 recorded for regulatory and compliance reasons. In others, calls may 21 be recorded for quality control or business analytics. 23 Recording is typically done by sending a copy of the session media to 24 the recording devices. This document specifies requirements for 25 extensions to SIP that will manage delivery of RTP media from an end- 26 point that originates media (or that has access to it) to a recording 27 device. This is being referred to as SIP-based Media Recording. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on July 4, 2011. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 76 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 84 10. Normative References . . . . . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 87 1. Requirements notation 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119] and indicate 92 requirement levels for compliant mechanisms. 94 2. Introduction 96 Session recording is a critical operational requirement in many 97 businesses, especially where voice is used as a medium for commerce 98 and customer support. A prime example where voice is used for trade 99 is the financial industry. The call recording requirements in this 100 industry are quite stringent. The recorded calls are used for 101 dispute resolution and compliance. Other businesses such as customer 102 support call centers typically employ call recording for quality 103 control or business analytics, with different requirements. 105 Depending on the country and its regulatory requirements, financial 106 trading floors typically must record all calls. In contrast, call 107 centers typically only record a subset of the calls, and calls must 108 not fail regardless of the availability of the recording device. 110 Respecting the privacy rights and wishes of users engaged in a call 111 is of paramount importance. In many jurisdictions participants have 112 a right to know that the session is being recorded or might be 113 recorded, and have a right to opt out, either by terminating the call 114 or by demanding that the call not be recorded. Therefore this 115 document contains requirements for being able to notify users that a 116 call is being recorded and for users to be able to request that a 117 call not be recorded. Use cases where users participating in a call 118 are not informed that the call is or might be recorded are outside 119 the scope of this document. In particular, lawful intercept is 120 outside the scope of this document. 122 Furthermore, the scale and cost burdens vary widely, in all markets, 123 where the different needs for solution capabilities such as media 124 injection, transcoding, and security-related needs do not conform 125 well to a one-size-fits-all model. If a standardized solution 126 supports all of the requirements from every recording market, but 127 doing so would be expensive for markets with lesser needs, then 128 proprietary solutions for those markets will continue to propagate. 129 Care must be taken, therefore, to make a standards-based solution 130 support optionality and flexibility. 132 This document specifies requirements for using SIP [RFC3261] between 133 a Session Recording Client and a Session Recording Server to control 134 the recording of media that has been transmitted in the context of a 135 Communication Session. A Communication Session is the "call" between 136 participants. The Session Recording Client is the source of the 137 recorded media. The Session Recording Server is the sink of recorded 138 media. It should be noted that the requirements for the protocol 139 between a Session Recording Server and Session Recording Client have 140 very similar requirements (such as codec and transport negotiation, 141 encryption key interchange, firewall traversal) as compared to 142 regular SIP media sessions. The choice of SIP for session recording 143 provides reuse of an existing protocol. 145 The recorded sessions can be any RTP media sessions including voice, 146 DTMF (as defined by [RFC4733]), video, and text (as defined by 147 [RFC4103]). 149 An archived session recording is typically comprised of the 150 Communication Session media content and the Communication Session 151 Metadata. The Communication Session Metadata allows recording 152 archives to be searched and filtered at a later time and allows a 153 session to be played back in a meaningful way, e.g., with correct 154 synchronization between the media. The Communication Session 155 Metadata needs to be conveyed from the Session Recording Client to 156 the Session Recording Server. 158 This document only considers active recording, where the Session 159 Recording Client purposefully streams media to a Session Recording 160 Server. Passive recording, where a recording device detects media 161 directly from the network, is outside the scope of this document. 163 3. Definitions 165 Session Recording Server (SRS): A Session Recording Server (SRS) is a 166 SIP User Agent (UA) that is a specialized media server or collector 167 that acts as the sink of the recorded media. An SRS is a logical 168 function that typically archives media for extended durations of time 169 and provides interfaces for search and retrieval of the archived 170 media. An SRS is typically implemented as a multi-port device that 171 is capable of receiving media from several sources simultaneously. 172 An SRS is typically also the sink of the recorded session metadata. 174 Session Recording Client (SRC): A Session Recording Client (SRC) is a 175 SIP User Agent (UA) that acts as the source of the recorded media, 176 sending it to the SRS. An SRC is a logical function. Its 177 capabilities may be implemented across one or more physical devices. 178 In practice, an SRC could be a personal device (such as a SIP phone), 179 a SIP Media Gateway (MG), a Session Border Controller (SBC) or a SIP 180 Media Server (MS) integrated with an Application Server (AS). This 181 specification defines the term SRC such that all such SIP entities 182 can be generically addressed under one definition. The SRC itself or 183 another entity working on its behalf (such as a SIP Application 184 Server) may act as the source of the recording metadata. 186 Communication Session (CS): A session created between two or more SIP 187 User Agents (UAs) that is the target for recording. 189 Recording Session (RS): The SIP session created between an SRC and 190 SRS for the purpose of recording a Communication Session. 192 Figure 1 pictorially represents the relationship between a Recording 193 Session and Communication Session. 195 +-------------+ +-----------+ 196 | | Communication Session | | 197 | A |<------------------------------------>| B | 198 | | | | 199 +-------------+ +-----------+ 200 .................................................................. 201 . Session . 202 . Recording . 203 . Client . 204 .................................................................. 205 | 206 | Recording 207 | Session 208 | 209 v 210 +------------+ 211 | Session | 212 | Recording | 213 | Server | 214 +------------+ 216 Figure 1 218 Metadata: Information that describes recorded media and the CS to 219 which they relate. 221 Pause and Resume during a Communication Session: Pause: The action of 222 temporarily discontinuing the transmission and collection of RS media 223 Resume: The action of recommencing the transmission and collection of 224 RS media 226 4. Use Cases 228 Use Case 1: Full-time Recording: One (or more, in the case of 229 redundant recording) Recording Session for each Communication 230 Session. 232 For example, the diagram below shows the lifecycle of Communication 233 Sessions (CS) and the relationship to the Recording Sessions (RS) 235 CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| 237 RS |--- RS 1 ---| |--- RS 2 ---| |--- RS 3 ---| 239 Figure 2 241 Record every CS for specific extension/person. 243 The need to record all calls is typically due to business process 244 purposes (such as transaction confirmation or dispute resolution) or 245 to ensure compliance with governmental regulations. Applications 246 include enterprise, contact center, and financial trading floors. 248 Also commonly known as Total Recording. 250 Use Case 2: Selective Recording: Start a Recording Session when a 251 Communication Session to be recorded is established. 253 In this example, Communication Sessions 1 and 3 are recorded but CS 2 254 is not. 256 CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| 258 RS |--- RS 1----| |--- RS 2 ---| 260 Figure 3 262 Use Case 3: Dynamic Recording: Start/Stop a Recording Session during 263 a Communication Session. 265 The Recording Session starts during a Communication Session, either 266 manually via a user-controlled mechanism (e.g. button on user's 267 phone) or automatically via an application (e.g. a Contact Center 268 customer service application) or business event. A Recording Session 269 either ends during the Communication Session, or when the 270 Communication Session ends. 272 One or more Recording Sessions per Communication Session: 274 CS |------------- Communication Session -----------| 276 RS |---- RS 1 ----| |---- RS 2 -----| 278 Figure 4 280 Also known as Mid-session or Mid-call Recording. 282 Use Case 4: Persistent Recording: A single Recording Session captures 283 one or more Communication Sessions, in sequence (Fig. 6) or in 284 parallel (Fig. 7). 286 |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| 288 RS |---------------------- Recording Session ---------------------| 290 Figure 5 292 A Recording Session records continuously without interruption. 293 Silent periods must be reproduced upon playback (e.g. by recording 294 the silent period, by not recording the silent periods but marking 295 them as metadata for a player to utilize, etc.) Applications include 296 financial trading desks and emergency (first-responder) service 297 bureaus. The length of a Persistent Recording Sessions is 298 independent from the length of the actual Communication Sessions. 299 Persistent Recording Sessions avoid issues such as media clipping 300 that can occur due to delays in Recording Session establishment. 302 The connection and attributes of media in the Recording Session are 303 not dynamically signaled for each Communication Session before it can 304 be recorded; however, codec re-negotiation is possible. CS details 305 and CS metadata will still be signaled, and can be correlated to the 306 recorded media. There will still need to be a means of correlating 307 the recorded media connection/packets to the Communication Session. 309 In some cases, more than one concurrent Communication Session (on a 310 single end-user apparatus, e.g. trading floor turret) is mixed into 311 one Recording Session: 313 |-------- CS 1 -------| 314 |-------- CS 2 -------| 315 |-------- CS 3 -------| 317 RS |----------- Recording Session --------------| 319 Figure 6 321 Use Case 5: Real-time Recording Controls. 323 For an active Recording Session, privacy or security reasons may 324 demand not capturing a specific portion of a conversation. An 325 example is for PCI (payment card industry) compliance where credit 326 card info must be protected. One solution is to not record a caller 327 speaking their credit card information. 329 An example of a real-time controls is Pause/Resume. 331 Use Case 6: IVR / Voice Portal Recording. 333 Self-service Interactive Voice Response (DTMF or ASR) applications 334 may need to be recorded for application performance tuning or to meet 335 compliance requirements. 337 Metadata about an IVR session recording must include session 338 information and may include application context information (e.g. 339 VoiceXML session variables, dialog names, etc.) 341 Use Case 7: Enterprise Mobility Recording. 343 Many agents and enterprise workers are not located on company 344 premises. 346 Examples: 348 o Home-based agents or enterprise workers. 350 o Mobile phones of knowledge workers when they conduct work related 351 (and legally required recording) calls. i.e. insurance agents, 352 brokers, physicians. 354 Use Case 8: Geographically distributed or centralized recording. 356 Global banks with multiple branches up to thousands of small sites. 358 o Only phones and network infrastructure in branches, no recording 359 services. 361 o Internal calls inside or between branches must be recorded. 363 o Centralized recording system in data centers together with 364 telephony infrastructure (e.g. PBX). 366 Use Case 9: Record complex call scenarios. 368 Record a call that is associated with another call. 370 Example: 372 o Customer in conversation with Agent 374 o Agent puts customer on hold in order to consult with a Supervisor. 376 o Agent in conversation with Supervisor. 378 o Agent disconnects from Supervisor, reconnects with Customer. 380 o The Supervisor call must be associated with the original customer 381 call. 383 Use case 10: High availability and continuous recording. 385 Specific deployment scenarios present different requirements for 386 system availability, error handling, etc. including: 388 o An SRS must always be available at call setup time. 390 o No loss of media recording, including during failure of an SRS. 392 o The Communication Session must be terminated (or suitable 393 notification) in the event of a recording failure. 395 Use Case 11: Record multi-channel, multi-media session. 397 Some applications require the recording of more than one media 398 stream, possibly of different types. Media is synchronized, either 399 at storage or at playback. 401 Speech analytics technologies (e.g. word spotting, emotion detection, 402 speaker identification) may require speaker-separated recordings for 403 optimum performance. 405 Multi-modal Contact Centers may include audio, video, IM or other 406 interaction modalities. 408 In trading floors environments, in order to save resources, it may be 409 preferable to mix multiple concurrent calls (Communication Sessions) 410 on different handsets/speakers on the same turret into single 411 recording session. 413 Use Case 12: Real-time media processing. 415 Recorder must support real-time media processing, such as speech 416 analytics. 418 Recording and real-time analytics of trading floor interactions 419 (including video and instant messaging). Real time analytics is 420 required for automatic intervention (stopping interaction or alert) 421 if for example, trader is not following regulations. 423 Speaker separation is required in order to reliably detect who is 424 saying specific phrases. 426 5. Requirements 428 The following are requirements for SIP-based Media Recording: 430 o REQ-001 The mechanism MUST provide a means for "using the SIP 431 protocol for" establishing, maintaining and terminating Recording 432 Sessions between a Session Recording Client and a Session Recording 433 Server. 435 o REQ-002 The mechanism MUST support the ability to record all CSs in 436 their entirety. 438 o REQ-003 The mechanism MUST support the ability to record selected 439 CSs in their entirety, according to policy. 441 o REQ-004 The mechanism MUST support the ability to record selected 442 parts of selected CSs. 444 o REQ-005 The mechanism MUST support the ability to record a CS 445 without an intentional loss of media (for example, clipping media at 446 the beginning of the CS) and without impacting the quality or timing 447 of the CS (for example, delaying the start of the CS while 448 preparation for recording takes place). See Use Case 4 in Section 5. 450 o REQ-006 The mechanism MUST support the recording of IVR sessions. 452 o REQ-007 The mechanism MUST support the recording of RTP media types 453 voice, DTMF (as defined by [RFC4733]), video, and text (as defined by 454 [RFC4103]). 456 o REQ-008 The mechanism MUST support the ability for an SRC to 457 deliver mixed audio streams from multiple Communication Sessions to 458 an SRS. 460 Note: A mixed audio stream is where several Communication Sessions 461 are carried in a single Recording Session. A mixed media stream is 462 typically produced by a mixer function. The RS MAY be informed about 463 the composition of the mixed streams through session metadata. 465 o REQ-009: The mechanism MUST support the ability for an SRC to 466 deliver mixed audio streams from different parties of a given 467 Communication Session to an SRS. 469 o REQ-010 The mechanism MUST support the ability to deliver to the 470 SRS multiple media streams for a given CS. 472 o REQ-011 The mechanism MUST support the ability to pause and resume 473 the transmission and collection of RS media. 475 o REQ-012 The mechanism MUST provide the SRS with metadata describing 476 CSs that are being recorded, including the media being used and the 477 identities of parties involved. 479 o REQ-013 The mechanism MUST provide the SRS with the means to 480 correlate RS media with CS participant media described in metadata. 482 o REQ-014 Metadata format must be agnostic of the transport protocol. 484 o REQ-015: The mechanism MUST support a means to cancel and discard 485 the recording and associated metadata for a CS. 487 o REQ-016: The mechanism MUST support a means to cancel and discard 488 the recording but not the associated metadata for a CS. 490 o REQ-017 The mechanism MUST support a means for an authorized 491 participant involved in a CS to request, prior to the start of 492 recording, that the CS not be recorded 494 o REQ-018 The mechanism MUST provide a means of indicating to the 495 participants involved in a CS that their session is being recorded. 497 Examples include: inject tones into the CS from the SRC, play a 498 message at the beginning of a session, a visual indicator on a 499 display, etc. 501 o REQ-019 The mechanism MUST provide a way for metadata to be 502 conveyed to the SRS incrementally during the CS. 504 o REQ-020 The mechanism MUST NOT prevent high availability 505 deployments. 507 o REQ-021 The mechanism MUST support means to relate Recording 508 Session(s) with Communication Session(s). 510 o REQ-022 The mechanism MUST provide the SRS the starting wall clock 511 time for each RS media stream corresponding to the CS participant 512 media. 514 o REQ-023 The mechanism MUST provide the SRS the wall clock time when 515 the Recording Session is paused and resumed. 517 o REQ-024 The mechanism MUST support functionality such that if the 518 CS is encrypted, the RS may use the same or different encryption 519 keys. 521 o REQ-025 The mechanism MUST provide means for an SRS to authenticate 522 the SRC on RS initiation. 524 o REQ-026 The mechanism MUST provide means for an SRC to authenticate 525 the SRS on RS initiation. 527 o REQ-027 The mechanism MUST ensure that the integrity of the 528 metadata sent from SRC to SRS is an accurate representation of the 529 original CS metadata. 531 o REQ-028 The mechanism MUST ensure that the integrity of the media 532 sent from SRC to SRS is an accurate representation of the original CS 533 media. 535 o REQ-029 The mechanism MUST ensure the confidentiality of the 536 Metadata sent from SRC to SRS. 538 o REQ-030 The mechanism MUST provide a means to support RS 539 confidentiality. 541 6. Privacy Considerations 543 Respecting the privacy rights and wishes of users engaged in a call 544 is of paramount importance. In many jurisdictions participants have 545 a right to know that the session is being recorded or might be 546 recorded, and have a right to opt out, either by terminating the call 547 or by demanding that the call not be recorded. Therefore this 548 document contains requirements for being able to notify users that a 549 call is being recorded and for users to be able to request that a 550 call not be recorded. Use cases where users participating in a call 551 are not informed that the call is or might be recorded are outside 552 the scope of this document. In particular, lawful intercept is 553 outside the scope of this document. 555 Requirements for participant notification of recording varies widely 556 by jurisdiction. In a given deployment, not all users will be 557 authorized to stop the recording of a CS (although any user can 558 terminate a CS). Typically users within the domain that is carrying 559 out the recording will be subject to policies of that domain 560 concerning whether CSs are recorded. For example, in a call centre, 561 agents will be subject to policies of the call centre and may or may 562 not have the right to prevent the recording of a CS or part of a CS. 563 Users calling into the call centre, on the other hand, will typically 564 have to ask the agent not to record the CS. If the agent is unable 565 to prevent recording, or if caller does not trust the agent, the only 566 option generally is to terminate the CS. 568 Privacy considerations also extend to what happens to a recording 569 once it has been created. Typical issues are who can access the 570 recording (e.g., receive a copy of the recording, view the metadata, 571 play back the media, etc.), for what purpose can the recording be 572 used (e.g., for non-repudiation, for training purposes, for quality 573 control purposes, etc.) and for how long the recording is to be 574 retained before deletion. These are typically policies of the domain 575 that makes the recording, rather than policies of individual users 576 involved in a recorded CS, whether those users be in the same domain 577 or in a different domain. Taking the call centre example again, 578 agents might be made aware of call centre policy regarding retention 579 and use of recordings as part of their employment contract, and 580 callers from outside the call centre might be given some information 581 about policy when notified that a CS will be recorded (e.g., through 582 an announcement that says that calls may be recorded for quality 583 purposes). 585 This document does not specify any requirements for a user engaged in 586 a CS to be able to dictate policy for what happens to a recording, or 587 for such information to be conveyed from an SRC to an SRS. It is 588 assumed that the SRS has access to policy applicable to its 589 environment and can ensure that recordings are stored and used in 590 accordance with that policy. 592 7. Security Considerations 594 Session recording has substantial security implications, for the SIP 595 UA's being recorded, the SRC, and the SRS. 597 For the SIP UA's involved in the Communication Session, the 598 requirements in this draft enable the UA to identify that a 599 Communication Session is being recorded and for the UA to request 600 that a given Communication Session is not subject to recording. 602 Since humans don't typically look at or know about protocol signaling 603 such as SIP, and indeed the SIP session might have originated through 604 a PSTN Gateway without any ability to pass on in-signaling 605 indications of recording, users can be notified of recording in the 606 media itself through voice announcements, a visual indicator on the 607 endpoint, or other means. 609 With regards to security implications of the protocol(s), clearly 610 there is a need for authentication, authorization, eavesdropping 611 protection, and non-repudiation for the solution. The SRC needs to 612 know the SRS it is communicating with is legitimate, and vice-versa, 613 even if they are in different domains. Both the signaling and media 614 for the Recording Session need the ability to be authenticated and 615 protected from eavesdropping and non-repudiation. Requirements are 616 detailed in the requirements section. 618 8. IANA Considerations 620 This document has no IANA actions. 622 9. Acknowledgements 624 Thanks to Dan Wing, Alan Johnson, Vijay Gurbani, Cullen Jennings, 625 Hadriel Kaplan, Henry Lum, Dave Smith, Martin Palmer, Alissa Cooper, 626 Deepanshu Gautam, Paul Kyzivat, Parthasarathi R, and Ram Mohan R for 627 their significant contributions and assistance with this document and 628 Working Group, and to all the members of the DISPATCH WG and SIPREC 629 WG mailing lists for providing valuable input to this work. 631 10. Normative References 633 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 634 Requirement Levels", BCP 14, RFC 2119, March 1997. 636 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 637 May 2000. 639 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 640 A., Peterson, J., Sparks, R., Handley, M., and E. 641 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 642 June 2002. 644 Authors' Addresses 646 Ken Rehor (editor) 647 Cisco Systems 648 170 West Tasman Dr. 649 Mail Stop SJC30/2/ 650 San Jose, CA 95134 651 USA 653 Email: krehor@cisco.com 655 Leon Portman (editor) 656 NICE Systems 657 8 Hapnina 658 Ra'anana 43017 659 Israel 661 Email: leon.portman@nice.com 663 Andrew Hutton 664 Siemens Enterprise Communications 666 Email: andrew.hutton@siemens-enterprise.com 667 URI: http://www.siemens-enterprise.com 669 Rajnish Jain 670 IPC Systems 671 777 Commerce Drive 672 Fairfield, CT 06825 673 USA 675 Email: rajnish.jain@ipc.com