idnits 2.17.1 draft-ietf-siprec-req-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document 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 (March 07, 2011) is 4797 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4733' is mentioned on line 440, but not defined == Missing Reference: 'RFC4103' is mentioned on line 441, but not defined == Unused Reference: 'RFC2804' is defined on line 630, 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: September 8, 2011 NICE Systems 6 A. Hutton 7 Siemens Enterprise Communications 8 R. Jain 9 IPC Systems 10 March 07, 2011 12 Requirements for SIP-based Media Recording (SIPREC) 13 draft-ietf-siprec-req-07 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 performed by sending a copy of the session 24 media to the recording devices. This document specifies requirements 25 for extensions to SIP that will manage delivery of RTP media to a 26 recording device. This is being referred to as SIP-based Media 27 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 September 8, 2011. 46 Copyright Notice 48 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . 15 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 typically 168 implemented as a multi-port device that is capable of receiving media 169 from multiple sources simultaneously. An SRS is the sink of the 170 recorded session metadata. 172 Session Recording Client (SRC): A Session Recording Client (SRC) is a 173 SIP User Agent (UA) that acts as the source of the recorded media, 174 sending it to the SRS. An SRC is a logical function. Its 175 capabilities may be implemented across one or more physical devices. 176 In practice, an SRC could be a personal device (such as a SIP phone), 177 a SIP Media Gateway (MG), a Session Border Controller (SBC) or a SIP 178 Media Server (MS) integrated with an Application Server (AS). This 179 specification defines the term SRC such that all such SIP entities 180 can be generically addressed under one definition. The SRC provides 181 metadata to the SRS. 183 Communication Session (CS): A session created between two or more SIP 184 User Agents (UAs) that is the subject of recording. 186 Recording Session (RS): The SIP session created between an SRC and 187 SRS for the purpose of recording a Communication Session. 189 Figure 1 pictorially represents the relationship between a Recording 190 Session and Communication Session. 192 +-------------+ +-----------+ 193 | | Communication Session | | 194 | A |<------------------------------------>| B | 195 | | | | 196 +-------------+ +-----------+ 197 .................................................................. 198 . Session . 199 . Recording . 200 . Client . 201 .................................................................. 202 | 203 | Recording 204 | Session 205 | 206 v 207 +------------+ 208 | Session | 209 | Recording | 210 | Server | 211 +------------+ 213 Figure 1 215 Metadata: Information that describes recorded media and the CS to 216 which they relate. 218 Pause and Resume during a Communication Session: Pause: The action of 219 temporarily discontinuing the transmission and collection of RS media 220 Resume: The action of recommencing the transmission and collection of 221 RS media 223 4. Use Cases 225 Use Case 1: Full-time Recording: One Recording Session for each 226 Communication Session. 228 For example, the diagram below shows the lifecycle of Communication 229 Sessions (CS) and the relationship to the Recording Sessions (RS) 231 CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| 233 RS |--- RS 1 ---| |--- RS 2 ---| |--- RS 3 ---| 235 Figure 2 237 Record every CS for specific extension/person. 239 The need to record all calls is typically due to business process 240 purposes (such as transaction confirmation or dispute resolution) or 241 to ensure compliance with governmental regulations. Applications 242 include enterprise, contact center, and financial trading floors. 244 Also commonly known as Total Recording. 246 Use Case 2: Selective Recording: Start a Recording Session when a 247 Communication Session to be recorded is established. 249 In this example, Communication Sessions 1 and 3 are recorded but CS 2 250 is not. 252 CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| 254 RS |--- RS 1----| |--- RS 2 ---| 256 Figure 3 258 Use Case 3: Start/Stop a Recording Session during a Communication 259 Session. 261 The Recording Session starts during a Communication Session, either 262 manually via a user-controlled mechanism (e.g. button on user's 263 phone) or automatically via an application (e.g. a Contact Center 264 customer service application) or business event. A Recording Session 265 either ends during the Communication Session, or when the 266 Communication Session ends. One or more Recording Sessions may 267 record each Communication Session. 269 CS |------------- Communication Session -----------| 271 RS |---- RS 1 ----| |---- RS 2 -----| 273 Figure 4 275 Use Case 4: Persistent Recording: A single Recording Session captures 276 one or more Communication Sessions. 278 |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| 280 RS |---------------------- Recording Session ---------------------| 282 Figure 5 284 A Recording Session records continuously without interruption. 285 Periods when there is no CS in progress must be reproduced upon 286 playback (e.g. by recording silence during such periods or by not 287 recording such periods but marking them by means of metadata for 288 utilization on playback, etc.). Applications include financial 289 trading desks and emergency (first-responder) service bureaus. The 290 length of a Persistent Recording Session is independent from the 291 length of the actual Communication Sessions. Persistent Recording 292 Sessions avoid issues such as media clipping that can occur due to 293 delays in Recording Session establishment. 295 The connection and attributes of media in the Recording Session are 296 not dynamically signaled for each Communication Session before it can 297 be recorded; however, codec re-negotiation is possible. 299 In some cases, more than one concurrent Communication Session (on a 300 single end-user apparatus, e.g. trading floor turret) is mixed into 301 one Recording Session: 303 |-------- CS 1 -------| 304 |-------- CS 2 -------| 305 |-------- CS 3 -------| 307 RS |----------- Recording Session --------------| 309 Figure 6 311 Use Case 5: Real-time Recording Controls. 313 For an active Recording Session, privacy or security reasons may 314 demand not capturing a specific portion of a conversation. An 315 example is for PCI (payment card industry) compliance where credit 316 card info must be protected. One solution is to not record a caller 317 speaking their credit card information. 319 An example of a real-time controls is Pause/Resume. 321 Use Case 6: IVR / Voice Portal Recording. 323 Self-service Interactive Voice Response applications may need to be 324 recorded for application performance tuning or to meet compliance 325 requirements. 327 Metadata about an IVR session recording must include session 328 information and may include application context information (e.g. 329 VoiceXML session variables, dialog names, etc.) 331 Use Case 7: Enterprise Mobility Recording. 333 Many agents and enterprise workers whose calls are to be recorded are 334 not located on company premises. 336 Examples: 338 o Home-based agents or enterprise workers. 340 o Mobile phones of knowledge workers when they conduct work related 341 (and legally required recording) calls. e.g. insurance agents, 342 brokers, physicians. 344 Use Case 8: Geographically distributed or centralized recording. 346 Enterprises such as banks, insurance agencies, and retail stores may 347 have many locations, possibly up to thousands of small sites. 348 Frequently only phones and network infrastructure are installed in 349 branches, without local recording services. In cases where calls 350 inside or between branches must be recorded, a centralized recording 351 system in data centers together with telephony infrastructure (e.g. 352 PBX) me deployed. 354 Use Case 9: Record complex call scenarios. 356 The following is an example of a scenario where one call that is 357 recorded must be associated with a related call that also must be 358 recorded. 360 o A Customer is in a conversation with a Customer Service Agent. 362 o Agent puts Customer on hold in order to consult with a Supervisor. 364 o Agent enters into a conversation with Supervisor. 366 o Agent disconnects from Supervisor, then reconnects with Customer. 368 o The Supervisor call must be associated with the original customer 369 call. 371 Use case 10: High availability and continuous recording. 373 Specific deployment scenarios present different requirements for 374 system availability, error handling, etc. including: 376 o An SRS must always be available at call setup time. 378 o No loss of media recording, including during failure of an SRS. 380 o The Communication Session must be terminated (or suitable 381 notification given to parties) in the event of a recording failure. 383 Use Case 11: Record multi-channel, multi-media session. 385 Some applications require the recording of more than one media 386 stream, possibly of different types. Media are synchronized, either 387 at storage or at playback. 389 Speech analytics technologies (e.g. word spotting, emotion detection, 390 speaker identification) may require speaker-separated recordings for 391 optimum performance. 393 Multi-modal Contact Centers may include audio, video, IM or other 394 interaction modalities. 396 In trading floors environments, in order to minimize storage and 397 recording system resources, it may be preferable to mix multiple 398 concurrent calls (Communication Sessions) on different handsets/ 399 speakers on the same turret into single recording session. 401 Use Case 12: Real-time media processing. 403 It must be possible for an SRS to support real-time media processing, 404 such as speech analytics of trading floor interactions. Ral-time 405 analytics may be employed for automatic intervention (stopping 406 interaction or alerting) if for example, a trader is not following 407 regulations. 409 Speaker separation is required in order to reliably detect who is 410 saying specific phrases. 412 5. Requirements 414 The following are requirements for SIP-based Media Recording: 416 o REQ-001 The mechanism MUST provide a means for "using the SIP 417 protocol for" establishing, maintaining and terminating Recording 418 Sessions between a Session Recording Client and a Session Recording 419 Server. 421 o REQ-002 The mechanism MUST support the ability to record all CSs in 422 their entirety. 424 o REQ-003 The mechanism MUST support the ability to record selected 425 CSs in their entirety, according to policy. 427 o REQ-004 The mechanism MUST support the ability to record selected 428 parts of selected CSs. 430 o REQ-005 The mechanism MUST support the ability to record a CS 431 without loss of media (for example, clipping media at the beginning 432 of the CS) due to RS recording preparation and also, without 433 impacting the quality or timing of the CS (for example, delaying the 434 start of the CS while preparation for recording session). See Use 435 Case 4 in Section 4 for more details. 437 o REQ-006 The mechanism MUST support the recording of IVR sessions. 439 o REQ-007 The mechanism MUST support the recording of RTP media types 440 voice, DTMF (as defined by [RFC4733]), video, and text (as defined by 441 [RFC4103]). 443 o REQ-008 The mechanism MUST support the ability for an SRC to 444 deliver mixed audio streams from multiple Communication Sessions to 445 an SRS. 447 Note: A mixed audio stream is where several Communication Sessions 448 are carried in a single Recording Session. A mixed media stream is 449 typically produced by a mixer function. The RS MAY be informed about 450 the composition of the mixed streams through session metadata. 452 o REQ-009: The mechanism MUST support the ability for an SRC to 453 deliver mixed audio streams from different parties of a given 454 Communication Session to an SRS. 456 o REQ-010 The mechanism MUST support the ability to deliver to the 457 SRS multiple media streams for a given CS. 459 o REQ-011 The mechanism MUST support the ability to pause and resume 460 the transmission and collection of RS media. 462 o REQ-012 The mechanism MUST provide the SRS with metadata describing 463 CSs that are being recorded, including the media being used and the 464 identities of parties involved. 466 o REQ-013 The mechanism MUST provide the SRS with the means to 467 correlate RS media with CS participant media. 469 o REQ-014 Metadata format must be agnostic of the transport protocol. 471 o REQ-015: The mechanism MUST support a means to stop the recording. 473 o REQ-016: The mechanism MUST support a means for a recording-aware 474 UA involved in a CS to request at session establishment time that the 475 CS should be recorded or should not be recorded, the honoring of such 476 a request being dependent on policy. 478 o REQ-017: The mechanism MUST support a means for a recording-aware 479 UA involved in a CS to request during a session that the recording of 480 the CS should be started, paused, resumed or stopped, the honoring of 481 such a request being dependent on policy. 483 o REQ-018 The mechanism MUST NOT prevent the application of tones or 484 announcements during recording or at the start of a CS to support 485 notification to participants that the call is being recorded or may 486 be recorded. 488 o REQ-019 The mechanism MUST provide a means of indicating to 489 recording-aware UAs whether recording is taking place, for 490 appropriate rendering at the user interface. 492 o REQ-020 The mechanism MUST provide a way for metadata to be 493 conveyed to the SRS incrementally during the CS. 495 o REQ-021 The mechanism MUST NOT prevent high availability 496 deployments. 498 o REQ-022 The mechanism MUST provide the SRS the starting wall clock 499 time for each RS media stream corresponding to the CS participant 500 media. 502 o REQ-023 The mechanism MUST provide the SRS the wall clock time when 503 the Recording Session is paused and resumed. 505 o REQ-024 The mechanism MUST support functionality such that if the 506 CS is encrypted, the RS may use the same or different encryption 507 keys. 509 o REQ-025 The mechanism MUST provide means for an SRS to authenticate 510 the SRC on RS initiation. 512 o REQ-026 The mechanism MUST provide means for an SRC to authenticate 513 the SRS on RS initiation. 515 o REQ-027 The mechanism MUST ensure that the integrity of the 516 metadata sent from SRC to SRS is an accurate representation of the 517 original CS metadata. 519 o REQ-028 The mechanism MUST ensure that the integrity of the media 520 sent from SRC to SRS is an accurate representation of the original CS 521 media. 523 o REQ-029 The mechanism MUST ensure the confidentiality of the 524 Metadata sent from SRC to SRS. 526 o REQ-030 The mechanism MUST provide a means to support RS 527 confidentiality. 529 o REQ-031 The mechanism MUST support the ability to deliver to the 530 SRS multiple media streams of the same media type (e.g. audio, 531 video). For example in the case of delivering unmixed audio for each 532 participant in the CS. 534 6. Privacy Considerations 536 Respecting the privacy rights and wishes of users engaged in a call 537 is of paramount importance. In many jurisdictions participants have 538 a right to know that the session is being recorded or might be 539 recorded, and have a right to opt out, either by terminating the call 540 or by demanding that the call not be recorded. Therefore this 541 document contains requirements for being able to notify users that a 542 call is being recorded and for users to be able to request that a 543 call not be recorded. Use cases where users participating in a call 544 are not informed that the call is or might be recorded are outside 545 the scope of this document. In particular, lawful intercept is 546 outside the scope of this document. 548 Requirements for participant notification of recording varies widely 549 by jurisdiction. In a given deployment, not all users will be 550 authorized to stop the recording of a CS (although any user can 551 terminate a CS). Typically users within the domain that is carrying 552 out the recording will be subject to policies of that domain 553 concerning whether CSs are recorded. For example, in a call centre, 554 agents will be subject to policies of the call centre and may or may 555 not have the right to prevent the recording of a CS or part of a CS. 557 Users calling into the call centre, on the other hand, will typically 558 have to ask the agent not to record the CS. If the agent is unable 559 to prevent recording, or if the caller does not trust the agent, the 560 only option generally is to terminate the CS. 562 Privacy considerations also extend to what happens to a recording 563 once it has been created. Typical issues are who can access the 564 recording (e.g., receive a copy of the recording, view the metadata, 565 play back the media, etc.), for what purpose the recording can be 566 used (e.g., for non-repudiation, for training purposes, for quality 567 control purposes, etc.) and for how long the recording is to be 568 retained before deletion. These are typically policies of the domain 569 that makes the recording, rather than policies of individual users 570 involved in a recorded CS, whether those users be in the same domain 571 or in a different domain. Taking the call centre example again, 572 agents might be made aware of call centre policy regarding retention 573 and use of recordings as part of their employment contract, and 574 callers from outside the call centre might be given some information 575 about policy when notified that a CS will be recorded (e.g., through 576 an announcement that says that calls may be recorded for quality 577 purposes). 579 This document does not specify any requirements for a user engaged in 580 a CS to be able to dictate policy for what happens to a recording, or 581 for such information to be conveyed from an SRC to an SRS. It is 582 assumed that the SRS has access to policy applicable to its 583 environment and can ensure that recordings are stored and used in 584 accordance with that policy. 586 7. Security Considerations 588 Session recording has substantial security implications, for the SIP 589 UA's being recorded, the SRC, and the SRS. 591 For the SIP UA's involved in the Communication Session, the 592 requirements in this draft enable the UA to identify that a 593 Communication Session is being recorded and for the UA to request 594 that a given Communication Session is not subject to recording. 596 Since humans don't typically look at or know about protocol signaling 597 such as SIP, and indeed the SIP session might have originated through 598 a PSTN Gateway without any ability to pass on in-signaling 599 indications of recording, users can be notified of recording in the 600 media itself through voice announcements, a visual indicator on the 601 endpoint, or other means. 603 With regards to security implications of the protocol(s), clearly 604 there is a need for authentication, authorization, eavesdropping 605 protection, and non-repudiation for the solution. The SRC needs to 606 know the SRS it is communicating with is legitimate, and vice-versa, 607 even if they are in different domains. Both the signaling and media 608 for the Recording Session need the ability to be authenticated and 609 protected from eavesdropping and non-repudiation. Requirements are 610 detailed in the requirements section. 612 8. IANA Considerations 614 This document has no IANA actions. 616 9. Acknowledgements 618 Thanks to Dan Wing, Alan Johnson, Vijay Gurbani, Cullen Jennings, 619 Hadriel Kaplan, Henry Lum, Dave Smith, Martin Palmer, Alissa Cooper, 620 Deepanshu Gautam, Paul Kyzivat, Parthasarathi R, and Ram Mohan R for 621 their significant contributions and assistance with this document and 622 Working Group, and to all the members of the DISPATCH WG and SIPREC 623 WG mailing lists for providing valuable input to this work. 625 10. Normative References 627 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 628 Requirement Levels", BCP 14, RFC 2119, March 1997. 630 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 631 May 2000. 633 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 634 A., Peterson, J., Sparks, R., Handley, M., and E. 635 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 636 June 2002. 638 Authors' Addresses 640 Ken Rehor (editor) 641 Cisco Systems 642 170 West Tasman Dr. 643 Mail Stop SJC30/2/ 644 San Jose, CA 95134 645 USA 647 Email: krehor@cisco.com 649 Leon Portman (editor) 650 NICE Systems 651 8 Hapnina 652 Ra'anana 43017 653 Israel 655 Email: leon.portman@nice.com 657 Andrew Hutton 658 Siemens Enterprise Communications 660 Email: andrew.hutton@siemens-enterprise.com 661 URI: http://www.siemens-enterprise.com 663 Rajnish Jain 664 IPC Systems 665 777 Commerce Drive 666 Fairfield, CT 06825 667 USA 669 Email: rajnish.jain@ipc.com