idnits 2.17.1 draft-ietf-siprec-req-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 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 (August 31, 2010) is 4979 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4103' is mentioned on line 139, but not defined == Unused Reference: 'RFC2804' is defined on line 675, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 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 R. Jain 5 Expires: February 2, 2011 IPC Systems 6 L. Portman 7 NICE Systems 8 A. Hutton 9 Siemens Enterprise Communications 10 August 31, 2010 12 Requirements for SIP-based Media Recording (SIPREC) 13 draft-ietf-siprec-req-01 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 February 2, 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. Example Deployment Architectures . . . . . . . . . . . . . . . 6 79 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 84 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 11. Normative References . . . . . . . . . . . . . . . . . . . . . 16 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 88 1. Requirements notation 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119] and indicate 93 requirement levels for compliant mechanisms. 95 2. Introduction 97 Session recording is a critical operational requirement in many 98 businesses, especially where voice is used as a medium for commerce 99 and customer support. A prime example where voice is used for trade 100 is the financial industry. The call recording requirements in this 101 industry are quite stringent. The recorded calls are used for 102 dispute resolution and compliance. Other businesses such as customer 103 support call centers typically employ call recording for quality 104 control or business analytics, with different requirements. 106 Depending on the country and its regulatory requirements, financial 107 trading floors typically must record all calls. The recorded media 108 content must be an exact copy of the actual conversation (i.e. 109 clipping and loss of media are unacceptable). A new call attempt 110 would be automatically rejected if the recording device becomes 111 temporarily unavailable. An existing call would be dropped in the 112 same situation. In contrast, support call centers typically only 113 record a subset of the calls, and calls must not fail regardless of 114 the availability of the recording device. 116 Furthermore, the scale and cost burdens vary widely, in all markets, 117 where the different needs for solution capabilities such as media 118 injection, transcoding, and security-related needs do not conform 119 well to a one-size-fits-all model. If a standardized solution 120 supports all of the requirements from every recording market, but 121 doing so would be expensive for markets with lesser needs, then 122 proprietary solutions for those markets will continue to propagate. 123 Care must be taken, therefore, to make a standards-based solution 124 support optionality and flexibility. 126 It should be noted that the requirements for the protocol between a 127 Session Recording Server and Session Recording Client have very 128 similar requirements (such as codec and transport negotiation, 129 encryption key interchange, firewall traversal) as compared to 130 regular SIP media sessions. The choice of SIP for session recording 131 provides reuse of an existing protocol. This document specifies 132 requirements for using SIP [RFC3261] to record a media session 133 between a Session Recording Client and a Session Recording Server, 134 The Session Recording Client is the source of the recorded media. 136 The Session Recording Server is the sink of recorded media. 138 The recorded sessions can be any SIP-based RTP media sessions 139 including voice, video, and text (as defined by [RFC4103]). 141 An archived session recording is typically comprised of the session 142 media content and the session metadata. The session metadata allows 143 recording archives to be searched and filtered at a later time. The 144 conveyance of session metadata from the Session Recording Client to 145 the Session Recording Server may or may not be over SIP. The 146 requirements for session metadata delivery will be specified in a 147 future revision of this document or in a separate document. 149 In some situations it may be advantageous to correlate the 150 Communication Session with other information, such as an IM or other 151 text chat session. 153 This document only considers active recording, where the Session 154 Recording Client purposefully streams media to a Session Recording 155 Server. Passive recording, where a recording device detects media 156 directly from the network, is outside the scope of this document. In 157 addition, lawful intercept is outside the scope of this document. 159 3. Definitions 161 Session Recording Server (SRS): A Session Recording Server (SRS) is a 162 SIP User Agent (UA) that is a specialized media server or collector 163 that acts as the sink of the recorded media. An SRS is a logical 164 function that typically archives media for extended durations of time 165 and provides interfaces for search and retrieval of the archived 166 media. An SRS is typically implemented as a multi-port device that 167 is capable of receiving media from several sources simultaneously. 168 An SRS is typically also the sink of the recorded session metadata. 169 Note that the term "Server" does not imply the SRS is the server side 170 of a signaling protocol - the SRS may be the initiator of recording 171 requests, for example. 173 Session Recording Client (SRC): A Recording Client (SRC) is a SIP 174 User Agent (UA) that acts as the source of the recorded media, 175 sending it to the SRS. An SRC is a logical function. Its 176 capabilities may be implemented across one or more physical devices. 177 In practice, an SRC could be a personal device (such as a SIP phone), 178 a SIP Media Gateway (MG), a Session Border Controller (SBC) or a SIP 179 Media Server (MS) integrated with an Application Server (AS). This 180 specification defines the term SRC such that all such SIP entities 181 can be generically addressed under one definition. The SRC itself or 182 another entity working on its behalf (such as a SIP Application 183 Server) may act as the source of the recording metadata. 185 Communication Session (CS): A session created between two or more SIP 186 User Agents (UAs) that is the target for recording. 188 Recording Session (RS): The SIP session created between an SRC and 189 SRS for the purpose of recording a Communication Session. 191 +---------------------------------------------------------------+ 192 | (Session Recording Client) | 193 | +-------------+ +-----------+ | 194 | | | Communication Session | | | 195 | | A |<------------------------->| B | | 196 | | | | | | 197 | +-------------+ +-----------+ | 198 +---------------------------------------------------------------+ 199 | 200 | Recording 201 | Session 202 | 203 v 204 +-------------+ 205 | | 206 | Session | 207 | Recording | 208 | Server | 209 | | 210 +-------------+ 212 Figure 1 214 Metadata: Data that describes the Communication Session and Recording 215 Session.. 217 SIPREC: The set of SIP extensions that supports recording of 218 Communication Sessions. 220 Pause/Resume recording: Pause: Temporarily discontinue capture and 221 storage of the incoming media stream. Recording may continue via the 222 Resume command. Resume: Continue capture and storage of the incoming 223 media stream into the same recording session. 225 4. Example Deployment Architectures 227 A recording system deployment consists of the Recording Client and 228 Recording Server. Recording Control is bi-directional; Recording 229 Media and Call Metadata are sent from the RC to RS. 231 +-------------+ +--------------+ 232 | | Call Metadata | | 233 | Session |-------------------------->| Session | 234 | Recording | | Recording | 235 | Client | Recording Control | Server | 236 | (SRC) |<------------------------->| (SRS) | 237 | | | | 238 | | Recorded Media | | 239 | |-------------------------->| | 240 | | | | 241 +-------------+ +--------------+ 243 Figure 2 245 5. Use Cases 247 Use Case 1: Full-time Recording: One (or more, in the case of 248 redundant recording) Recording Session for each Communication 249 Session. 251 For example, the diagram below shows the lifecycle of Communication 252 Sessions (CS) and the relationship to the Recording Sessions (RS) 254 CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| 256 RS |--- RS 1 ---| |--- RS 2 ---| |--- RS 3 ---| 258 Figure 3 260 Record every call for specific extension/person. One Recording 261 Session is created per Communication Session. 263 The need to record all calls is typically due to business process 264 purposes (such as transaction confirmation or dispute resolution) or 265 to ensure compliance with governmental regulations. Applications 266 include enterprise, contact center, and financial trading floors. 268 Also commonly known as Total Recording. 270 Use Case 2: Selective Recording: Start a Recording Session when a 271 Communication Session is established. Only specific calls are 272 recorded, possibly based on business rules. A Communication Session 273 may or may not have a Recording Session (record only specific calls). 275 In this example, Communication Sessions 1 and 3 are recorded but CS 2 276 is not. 278 CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| 280 RS |--- RS 1----| |--- RS 2 ---| 282 Figure 4 284 Use Case 3: Dynamic Recording: Start/Stop a Recording Session during 285 a Communication Session. 287 The Recording Session starts during a Communication Session, either 288 manually via a user-controlled mechanism (e.g. button on user's 289 phone) or automatically via an application (e.g. a Contact Center 290 customer service application) or business event. A Recording Session 291 either ends during the Communication Session, or when the 292 Communication Session ends. 294 One or more Recording Sessions per Communication Session: 296 CS |------------- Communication Session -----------| 298 RS |---- RS 1 ----| |---- RS 2 -----| 300 Figure 5 302 Also known as Mid-session or Mid-call Recording. 304 Applications include: 306 o Enterprise back office recording where only specific calls (based 307 on privacy) have to be recorded 309 o A user requests session recording at call setup time or during a 310 call. 312 Use Case 4: Persistent Recording: A single Recording Session captures 313 one or more Communication Sessions, in sequence (Fig. 6) or in 314 parallel (Fig. 7). The recording session is a single RTP stream, 315 therefore consists of a single offer/answer exchange. There may be 316 mid-session RE-INVITE offer/answer exchanges for codec changes or for 317 moving the RTP streams to handle failure scenarios. 319 |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| 321 RS |---------------------- Recording Session ---------------------| 323 Figure 6 325 A Recording Session records continuously without interruption. 326 Applications include financial trading desks and emergency (first- 327 responder) service bureaus. The length of a Persistent Recording 328 Sessions is independent from the length of the actual Communication 329 Sessions. Persistent Recording Sessions avoid issues such as media 330 clipping that can occur due to delays in Recording Session 331 establishment. 333 The connection and attributes of media in the Recording Session are 334 not dynamically signaled for each Communication Session before it can 335 be recorded; however, codec re-negotiation is possible. Call details 336 and metadata will still be signaled, but can be post- correlated to 337 the recorded media. There will still need to be a means of 338 correlating the recorded media connection/packets to the 339 Communication Session, however this may be on a permanent filter-type 340 basis, such as based on a SIP AoR of an agent that is always 341 recorded. 343 In some cases, more than one concurrent Communication Session (on a 344 single end-user apparatus, e.g. trading floor turret) is mixed into 345 one Recording Session: 347 |-------- CS 1 -------| 348 |-------- CS 2 -------| 349 |-------- CS 3 -------| 351 RS |----------- Recording Session --------------| 353 Figure 7 355 Use Case 5: Real-time Recording Controls. 357 For an active Recording Session, privacy or security reasons may 358 demand not capturing a specific portion of a conversation. An 359 example is for PCI (payment card industry) compliance where credit 360 card info must be protected. One solution is to not record a caller 361 speaking their credit card information. 363 Real-time controls may include Pause/Resume, or Mute/Unmute. 365 Use Case 6: IVR / Voice Portal Recording. 367 Self-service Interactive Voice Response (DTMF or ASR) applications 368 may need to be recorded for application performance tuning or to meet 369 compliance requirements. 371 Metadata about an IVR session recording must include session 372 information and may include application context information (e.g. 373 VoiceXML session variables, dialog names, etc.) 375 Use Case 7: Enterprise Mobility Recording. 377 Many agents and enterprise workers are not located on company 378 premises. 380 Examples: 382 o Home-based agents or enterprise workers. 384 o Mobile phones of knowledge workers when they conduct work related 385 (and legally required recording) calls. i.e. insurance agents, 386 brokers, physicians. 388 Use Case 8: Geographically distributed or centralized recording. 390 Global banks with multiple branches up to thousands of small sites. 392 o Only phones and network infrastructure in branches, no recording 393 services. 395 o Internal calls inside or between branches must be recorded. 397 o Centralized recording system in data centers together with 398 telephony infrastructure (e.g. PBX). 400 Obtain media by forking: 402 o In data centers (inbound/outbound): fork media in gateway. 404 o At branch locations (internal): fork from end points or from site 405 level gateways. 407 Use Case 9: Record complex call scenarios. 409 Record a call that is associated with another call. 411 Example: 413 o Customer in conversation with Agent 414 o Agent puts customer on hold in order to consult with a Supervisor. 416 o Agent in conversation with Supervisor. 418 o Agent disconnects from Supervisor, reconnects with Customer. 420 o The Supervisor call must be associated with the original customer 421 call. 423 Use case 10: High availability and continuous recording. 425 Specific deployment scenarios present different requirements for 426 system availability, error handling, etc. including: 428 o An SRS must always be available at call setup time. 430 o No loss of media recording, including during failure of an SRS. 432 o The Communication Session must be terminated (or suitable 433 notification) in the event of a recording failure. 435 Use Case 11: Record multi-channel, multi-media session. 437 Some applications require the recording of more than one media 438 stream, possibly of different types. Media is synchronized, either 439 at storage or at playback. 441 Speech analytics technologies (e.g. word spotting, emotion detection, 442 speaker identification) may require speaker-separated recordings for 443 optimum performance. 445 Multi-modal Contact Centers may include audio, video, IM or other 446 interaction modalities. 448 In trading floors environments, in order to save resources, it may be 449 preferable to mix multiple concurrent calls (Communication Sessions) 450 on different handsets/speakers on the same turret into single 451 recording session. 453 Use Case 12: Real-time media processing. 455 Recorder must support real-time media processing, such as speech 456 analytics. 458 Recording and real-time analytics of trading floor interactions 459 (including video and instant messaging). Real time analytics is 460 required for automatic intervention (stopping interaction or alert) 461 if for example, trader is not following regulations. 463 Speaker separation is required in order to reliably detect who is 464 saying specific phrases. 466 6. Requirements 468 The following are requirements for the Session Recording Protocol: 470 o REQ-000 The mechanism MUST provide a means for establishing, 471 maintaining and clearing Recording Sessions between a Session 472 Recording Client and a Session Recording Server for the purpose of 473 recording, at the Session Recording Server, media from Communication 474 Sessions. 476 o REQ-001 The mechanism MUST support Full-time Recording Sessions. 478 o REQ-002 The mechanism MUST support Selective Recording Sessions. 480 o REQ-003 The mechanism MUST support Dynamic (on-demand) Recording 481 Sessions. 483 o REQ-004 The mechanism MUST support Persistent Recording Sessions. 485 o REQ-005 The mechanism MUST support establishing Recording Sessions 486 from the SRC to the SRS. This requirement typically applies when the 487 decision about whether a session should be recorded or not resides in 488 the SRC. 490 o REQ-006 The mechanism MUST support establishing Recording Sessions 491 from the SRS to the SRC (SRS initiates recording). This requirement 492 typically applies when the decision about whether a session should be 493 recorded or not resides in the SRS. 495 o REQ-007 The mechanism MUST support the recording of IVR sessions. 497 o REQ-008 The mechanism SHOULD support SRS failover and migration of 498 Recording Sessions to a working SRS without disconnecting the 499 Communication Sessions. 501 o REQ-009 A request for a new Recording Session MUST be rejected by 502 the SRS if service is unavailable (e.g. system overload, disk full, 503 etc.) 505 o REQ-010 A request for a new Recording Session MUST be redirected to 506 an available SRS. 508 o REQ-011 If no recording resources are available, appropriate error 509 message MUST be returned. 511 o REQ-012 The mechanism MUST support the ability for an SRC to 512 deliver mixed audio streams from multiple Communication Sessions to 513 an SRS. 515 Note: A mixed audio stream is where several Communication Sessions 516 are carried in a single Recording Session. A mixed media stream is 517 typically produced by a mixer function. The RS MAY be informed about 518 the composition of the mixed streams through session metadata. 520 o REQ-012bis: The mechanism MUST support the ability for an SRC to 521 deliver mixed audio streams from different parties of a given 522 Communication Session to an SRS. 524 o REQ-013 The mechanism MUST support the ability to deliver multiple 525 media streams for a given Communication Session over separate 526 Recording Sessions to the SRS. 528 o REQ-014 The mechanism MUST support the ability to deliver multiple 529 media streams for a given Communication Session over a single 530 Recording Session to the SRS. 532 o REQ-015 The mechanism MUST support the ability to pause and resume 533 the Recording Session from the SRC. 535 o REQ-016 The mechanism MUST support the ability to pause and resume 536 the Recording Session from the SRS. 538 o REQ-017 The mechanism MUST provide the SRS with metadata describing 539 CSs that are being recorded, including the media being used and the 540 identities of parties involved. 542 o REQ-018 The mechanism MUST provide the SRS with the means to 543 correlate RS media with CS participant media described in metadata 545 o REQ-019 The mechanism MUST support the ability to transport the 546 metadata in the same SIP dialog as the Recording Session. 548 o REQ-020 The mechanism MUST support the ability to transport the 549 metadata outside of the Recording Session SIP dialog. 551 o REQ-021 Metadata format must be agnostic of the transport protocol. 553 o REQ-022: The mechanism MUST support a means to cancel and discard a 554 Recording Session during a Communication Session. 556 o REQ-023 The mechanism MUST support a means for a SIP UA to request 557 that a Communication Session is not recorded prior to recording. 559 o REQ-024 The mechanism MUST provide a means of indicating to the end 560 users of a Communication Session that the session in which they are 561 participating is being recorded. 563 Examples include: inject tones into the Communication Session from 564 the SRC, play a message at the beginning of a session, a visual 565 indicator on a display, etc. 567 o REQ-025 The mechanism MUST support the initiation of a Recording 568 Session at the beginning of a Communication Session. 570 o REQ-026 The mechanism MUST support the initiation of a Recording 571 Session during a Communication Session. 573 o REQ-027 The mechanism SHOULD support means to avoid clipping media 574 (leading or trailing samples) when the media is transported from the 575 SRC to the SRS. 577 Note: Media clipping can occur due to delays in recording session 578 establishment. SRC implementations typically buffer some portion of 579 the media to overcome this problem. 581 o REQ-028 The mechanism MUST NOT prevent high availability 582 deployments. 584 o REQ-029 The mechanism MUST support a means of providing security 585 (confidentiality, integrity and authentication) for the SIPREC. 587 o REQ-030 The mechanism MUST provide a means for the Recording 588 Session identifier so that the Recording Session itself is labeled as 589 a SIP session that is established for the purpose of recording. 591 o REQ-031 The mechanism MUST support the existing SIP security model, 592 including eavesdropping protection, authorization and authentication. 594 o REQ-032 If the Communication Session is encrypted, the Recording 595 Session MUST use different keys. 597 o REQ-033 The mechanism SHALL support means to relate Recording 598 Session(s) with Communication Session(s). 600 7. Security Considerations 602 Session recording has substantial security implications, both for the 603 SIP UA's being recorded, and for the Session Recording Protocol 604 itself in terms of the SRC and SRS. 606 For the SIP UA's involved in the Communication Session, the 607 requirements in this draft enable the UA to identify that a session 608 is being recorded and for the UA to request that a given session is 609 not subject to recording. 611 Since humans don't typically look at or know about protocol signaling 612 such as SIP, and indeed the SIP session might have originated through 613 a PSTN Gateway without any ability to pass on in-signaling 614 indications of recording, users can be notified of recording in the 615 media itself through voice announcements, a visual indicator on the 616 endpoint, or other means. 618 With regards to security implications of the protocol(s), clearly 619 there is a need for authentication, authorization, eavesdropping 620 protection, and non-repudiation for the solution. The SRC needs to 621 know the SRS it is communicating with is legitimate, and vice-versa, 622 even if they are in different domains. Both the signaling and media 623 for the SIPREC needs the ability to be authenticated and protected 624 from eavesdropping and non-repudiation. Requirements are detailed in 625 the requirements section. 627 8. IANA Considerations 629 This document has no IANA actions. 631 9. Acknowledgements 633 Thanks to Dan Wing, Alan Johnson, Vijay Gurbani, and Cullen Jennings 634 for their help with this document, and to all the members of the 635 DISPATCH WG mailing list for providing valuable input to this work. 637 10. Contributors 639 In addition to the editors, the following people provided substantial 640 technical and writing contributions to this document, listed 641 alphabetically: 643 Hadriel Kaplan 644 Acme Packet 645 71 Third Ave. 646 Burlington, MA 01803 647 USA 648 hkaplan@acmepacket.com 650 Henry Lum 651 Genesys, Alcatel-Lucent 652 1380 Rodick Road, Suite 200 653 Markham, Ontario L3R 4G5 654 Canada 655 henry.lum@genesyslab.com 657 Martin Palmer 658 BT Global Services 659 Annandale House,1 Hanworth Road, 660 Sunbury on Thames Middlesex TW16 5DJ 661 UK 662 martin.4.palmer@bt.com 664 Dave Smith 665 Genesys, Alcatel-Lucent 666 2001 Junipero Serra Blvd, Daly City, CA 94014 667 USA 668 dsmith@genesyslab.com 670 11. Normative References 672 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 673 Requirement Levels", BCP 14, RFC 2119, March 1997. 675 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 676 May 2000. 678 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 679 A., Peterson, J., Sparks, R., Handley, M., and E. 680 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 681 June 2002. 683 Authors' Addresses 685 Ken Rehor (editor) 686 Cisco Systems 687 170 West Tasman Dr. 688 Mail Stop SJC30/2/ 689 San Jose, CA 95134 690 USA 692 Email: krehor@cisco.com 693 Rajnish Jain 694 IPC Systems 695 777 Commerce Drive 696 Fairfield, CT 06825 697 USA 699 Email: rajnish.jain@ipc.com 701 Leon Portman 702 NICE Systems 703 8 Hapnina 704 Ra'anana 43017 705 Israel 707 Email: leon.portman@nice.com 709 Andrew Hutton 710 Siemens Enterprise Communications 712 Email: andrew.hutton@siemens-enterprise.com 713 URI: http://www.siemens-enterprise.com