idnits 2.17.1 draft-ietf-siprec-req-12.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 date (June 09, 2011) is 4703 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPREC K. Rehor, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Informational L. Portman, Ed. 5 Expires: December 11, 2011 NICE Systems 6 A. Hutton 7 Siemens Enterprise 8 Communications 9 R. Jain 10 IPC Systems 11 June 09, 2011 13 Use Cases and Requirements for SIP-based Media Recording (SIPREC) 14 draft-ietf-siprec-req-12 16 Abstract 18 Session recording is a critical requirement in many business 19 communications environments such as call centers and financial 20 trading floors. In some of these environments, all calls must be 21 recorded for regulatory and compliance reasons. In others, calls may 22 be recorded for quality control or business analytics. 24 Recording is typically performed by sending a copy of the session 25 media to the recording devices. This document specifies requirements 26 for extensions to SIP that will manage delivery of RTP media to a 27 recording device. This is being referred to as SIP-based Media 28 Recording. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 11, 2011. 47 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 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 65 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 72 10. Normative References . . . . . . . . . . . . . . . . . . . . . 15 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 75 1. Introduction 77 Session recording is a critical operational requirement in many 78 businesses, especially where voice is used as a medium for commerce 79 and customer support. A prime example where voice is used for trade 80 is the financial industry. The call recording requirements in this 81 industry are quite stringent. The recorded calls are used for 82 dispute resolution and compliance. Other businesses such as customer 83 support call centers typically employ call recording for quality 84 control or business analytics, with different requirements. 86 Depending on the country and its regulatory requirements, financial 87 trading floors typically must record all calls. In contrast, call 88 centers typically only record a subset of the calls, and calls must 89 not fail regardless of the availability of the recording device. 91 Respecting the privacy rights and wishes of users engaged in a call 92 is of paramount importance. In many jurisdictions participants have 93 a right to know that the session is being recorded or might be 94 recorded, and have a right to opt out, either by terminating the call 95 or by demanding that the call not be recorded. Therefore this 96 document contains requirements for being able to notify users that a 97 call is being recorded and for users to be able to request that a 98 call not be recorded. Use cases where users participating in a call 99 are not informed that the call is or might be recorded are outside 100 the scope of this document. In particular, lawful intercept is 101 outside the scope of this document. 103 Furthermore, one-size-fits-all model will not fit all markets where 104 the scale and cost burdens vary widely having different needs for 105 solution capabilities such as media injection, transcoding, and 106 security. If a standardized solution supports all of the 107 requirements from every recording market, but doing so would be 108 expensive for markets with lesser needs, then proprietary solutions 109 for those markets will continue to propagate. Care must be taken, 110 therefore, to make a standards-based solution support optionality and 111 flexibility. 113 This document specifies requirements for using SIP [RFC3261] between 114 a Session Recording Client and a Session Recording Server to control 115 the recording of media that has been transmitted in the context of a 116 Communication Session. A Communication Session is the "call" between 117 participants. The Session Recording Client is the source of the 118 recorded media. The Session Recording Server is the sink of recorded 119 media. It should be noted that the requirements for the protocol 120 between a Session Recording Server and Session Recording Client have 121 very similar requirements (such as codec and transport negotiation, 122 encryption key interchange, firewall traversal) as compared to 123 regular SIP media sessions. The choice of SIP for session recording 124 provides reuse of an existing protocol. 126 The recorded sessions can be any RTP media sessions including voice, 127 DTMF (as defined by [RFC4733]), video, and text (as defined by 128 [RFC4103]). 130 An archived session recording is typically comprised of the 131 Communication Session media content and the Communication Session 132 Metadata. The Communication Session Metadata allows recording 133 archives to be searched and filtered at a later time and allows a 134 session to be played back in a meaningful way, e.g., with correct 135 synchronization between the media. The Communication Session 136 Metadata needs to be conveyed from the Session Recording Client to 137 the Session Recording Server. 139 This document only considers active recording, where the Session 140 Recording Client purposefully streams media to a Session Recording 141 Server. Passive recording, where a recording device detects media 142 directly from the network, is outside the scope of this document. 144 2. Requirements notation 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119] and indicate 149 requirement levels for compliant mechanisms. 151 3. Definitions 153 Session Recording Server (SRS): A Session Recording Server (SRS) is a 154 SIP User Agent (UA) that is a specialized media server or collector 155 that acts as the sink of the recorded media. An SRS is typically 156 implemented as a multi-port device that is capable of receiving media 157 from multiple sources simultaneously. An SRS is the sink of the 158 recorded session metadata. 160 Session Recording Client (SRC): A Session Recording Client (SRC) is a 161 SIP User Agent (UA) that acts as the source of the recorded media, 162 sending it to the SRS. An SRC is a logical function. Its 163 capabilities may be implemented across one or more physical devices. 164 In practice, an SRC could be a personal device (such as a SIP phone), 165 a SIP Media Gateway (MG), a Session Border Controller (SBC) or a SIP 166 Media Server (MS) integrated with an Application Server (AS). This 167 specification defines the term SRC such that all such SIP entities 168 can be generically addressed under one definition. The SRC provides 169 metadata to the SRS. 171 Communication Session (CS): A session created between two or more SIP 172 User Agents (UAs) that is the subject of recording. 174 Recording Session (RS): The SIP session created between an SRC and 175 SRS for the purpose of recording a Communication Session. 177 Figure 1 pictorially represents the relationship between a Recording 178 Session and Communication Session. 180 +-------------+ +-----------+ 181 | | Communication Session | | 182 | A |<------------------------------------>| B | 183 | | | | 184 +-------------+ +-----------+ 185 .................................................................. 186 . Session . 187 . Recording . 188 . Client . 189 .................................................................. 190 | 191 | Recording 192 | Session 193 | 194 v 195 +------------+ 196 | Session | 197 | Recording | 198 | Server | 199 +------------+ 201 Figure 1 203 Metadata: Information that describes recorded media and the CS to 204 which they relate. 206 Pause and Resume during a Communication Session: Pause: The action of 207 temporarily discontinuing the transmission and collection of RS media 208 Resume: The action of recommencing the transmission and collection of 209 RS media 211 Most security-related terms in this document are to be understood in 212 the sense defined in [RFC4949]; such terms include, but are not 213 limited to, "authentication", "confidentiality", "encryption", 214 "identity", and "integrity". 216 4. Use Cases 218 Use Case 1: Full-time Recording: One Recording Session for each 219 Communication Session. 221 For example, the diagram below shows the lifecycle of Communication 222 Sessions (CS) and the relationship to the Recording Sessions (RS) 224 CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| 226 RS |--- RS 1 ---| |--- RS 2 ---| |--- RS 3 ---| 227 t---> 229 Figure 2 231 Record every CS for specific extension/person. 233 The need to record all calls is typically due to business process 234 purposes (such as transaction confirmation or dispute resolution) or 235 to ensure compliance with governmental regulations. Applications 236 include enterprise, contact center, and financial trading floors. 238 Also commonly known as Total Recording. 240 Use Case 2: Selective Recording: Start a Recording Session when a 241 Communication Session to be recorded is established. 243 In this example, Communication Sessions 1 and 3 are recorded but CS 2 244 is not. 246 CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| 248 RS |--- RS 1----| |--- RS 2 ---| 249 t---> 251 Figure 3 253 Use Case 3: Start/Stop a Recording Session during a Communication 254 Session. 256 The Recording Session starts during a Communication Session, either 257 manually via a user-controlled mechanism (e.g. button on user's 258 phone) or automatically via an application (e.g. a Contact Center 259 customer service application) or business event. A Recording Session 260 either ends during the Communication Session, or when the 261 Communication Session ends. One or more Recording Sessions may 262 record each Communication Session. 264 CS |------------- Communication Session -----------| 266 RS |---- RS 1 ----| |---- RS 2 -----| 267 t---> 269 Figure 4 271 Use Case 4: Persistent Recording: A single Recording Session captures 272 one or more Communication Sessions. 274 |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| 276 RS |---------------------- Recording Session ---------------------| 277 t---> 279 Figure 5 281 A Recording Session records continuously without interruption. 282 Periods when there is no CS in progress must be reproduced upon 283 playback (e.g. by recording silence during such periods or by not 284 recording such periods but marking them by means of metadata for 285 utilization on playback, etc.). Applications include financial 286 trading desks and emergency (first-responder) service bureaus. The 287 length of a Persistent Recording Session is independent from the 288 length of the actual Communication Sessions. Persistent Recording 289 Sessions avoid issues such as media clipping that can occur due to 290 delays in Recording Session establishment. 292 The connection and attributes of media in the Recording Session are 293 not dynamically signaled for each Communication Session before it can 294 be recorded; however, codec re-negotiation is possible. 296 In some cases, more than one concurrent Communication Session (on a 297 single end-user apparatus, e.g. trading floor turret) is mixed into 298 one Recording Session: 300 |-------- CS 1 -------| 301 |-------- CS 2 -------| 302 |-------- CS 3 -------| 304 RS |----------- Recording Session --------------| 305 t---> 307 Figure 6 309 Use Case 5: Real-time Recording Controls. 311 For an active Recording Session, privacy or security reasons may 312 demand not capturing a specific portion of a conversation. An 313 example is for PCI (payment card industry) compliance where credit 314 card info must be protected. One solution is to not record a caller 315 speaking their credit card information. 317 An example of a real-time controls is Pause/Resume. 319 Use Case 6: IVR / Voice Portal Recording. 321 Self-service Interactive Voice Response applications may need to be 322 recorded for application performance tuning or to meet compliance 323 requirements. 325 Metadata about an IVR session recording must include session 326 information and may include application context information (e.g. 327 VoiceXML session variables, dialog names, etc.) 329 Use Case 7: Enterprise Mobility Recording. 331 Many agents and enterprise workers whose calls are to be recorded are 332 not located on company premises. 334 Examples: 336 o Home-based agents or enterprise workers. 338 o Mobile phones of knowledge workers when they conduct work related 339 (and legally required recording) calls. e.g. insurance agents, 340 brokers, physicians. 342 Use Case 8: Geographically distributed or centralized recording. 344 Enterprises such as banks, insurance agencies, and retail stores may 345 have many locations, possibly up to thousands of small sites. 346 Frequently only phones and network infrastructure are installed in 347 branches, without local recording services. In cases where calls 348 inside or between branches must be recorded, a centralized recording 349 system in data centers together with telephony infrastructure (e.g. 350 PBX) may be deployed. 352 Use Case 9: Record complex call scenarios. 354 The following is an example of a scenario where one call that is 355 recorded must be associated with a related call that also must be 356 recorded. 358 o A Customer is in a conversation with a Customer Service Agent. 360 o Agent puts Customer on hold in order to consult with a Supervisor. 362 o Agent enters into a conversation with Supervisor. 364 o Agent disconnects from Supervisor, then reconnects with Customer. 366 o The Supervisor call must be associated with the original customer 367 call. 369 Use case 10: High availability and continuous recording. 371 Specific deployment scenarios present different requirements for 372 system availability, error handling, etc. including: 374 o An SRS must always be available at call setup time. 376 o No loss of media recording, including during failure of an SRS. 378 o The Communication Session must be terminated (or suitable 379 notification given to parties) in the event of a recording failure. 381 Use Case 11: Record multi-channel, multi-media session. 383 Some applications require the recording of more than one media 384 stream, possibly of different types. Media are synchronized, either 385 at storage or at playback. 387 Speech analytics technologies (e.g. word spotting, emotion detection, 388 speaker identification) may require speaker-separated recordings for 389 optimum performance. 391 Multi-modal Contact Centers may include audio, video, IM or other 392 interaction modalities. 394 In trading floors environments, in order to minimize storage and 395 recording system resources, it may be preferable to mix multiple 396 concurrent calls (Communication Sessions) on different handsets/ 397 speakers on the same turret into single recording session. 399 Use Case 12: Real-time media processing. 401 It must be possible for an SRS to support real-time media processing, 402 such as speech analytics of trading floor interactions. Real-time 403 analytics may be employed for automatic intervention (stopping 404 interaction or alerting) if for example, a trader is not following 405 regulations. 407 Speaker separation is required in order to reliably detect who is 408 saying specific phrases. 410 5. Requirements 412 The following are requirements for SIP-based Media Recording: 414 o REQ-001 The mechanism MUST provide a means for using the SIP 415 protocol for establishing, maintaining and terminating Recording 416 Sessions between a Session Recording Client and a Session Recording 417 Server. 419 o REQ-002 The mechanism MUST support the ability to record all CSs in 420 their entirety. 422 o REQ-003 The mechanism MUST support the ability to record selected 423 CSs in their entirety, according to policy. 425 o REQ-004 The mechanism MUST support the ability to record selected 426 parts of selected CSs. 428 o REQ-005 The mechanism MUST support the ability to record a CS 429 without loss of media of RS (for example, clipping media at the 430 beginning of the CS) due to RS recording preparation and also, 431 without impacting the quality or timing of the CS (for example, 432 delaying the start of the CS while preparation for recording 433 session). See Use Case 4 in Section 4 for more details. 435 o REQ-006 The mechanism MUST support the recording of IVR sessions. 437 o REQ-007 The mechanism MUST support the recording of RTP media types 438 voice, DTMF (as defined by [RFC4733]), video, and text (as defined by 440 [RFC4103]). 442 o REQ-008 The mechanism MUST support the ability for an SRC to 443 deliver mixed audio streams from multiple Communication Sessions to 444 an SRS. 446 Note: A mixed audio stream is where several related Communication 447 Sessions are carried in a single Recording Session. A mixed media 448 stream is typically produced by a mixer function. The RS MAY be 449 informed about the composition of the mixed streams through session 450 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 include a means for providing the SRS 463 with metadata describing CSs that are being recorded, including the 464 media being used and the identifiers of parties involved. 466 o REQ-013 The mechanism MUST include a means for the SRS to be able 467 to 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. Such recording-aware UA 482 MUST be notified about outcome of such requests. 484 o REQ-018 The mechanism MUST NOT prevent the application of tones or 485 announcements during recording or at the start of a CS to support 486 notification to participants that the call is being recorded or may 487 be recorded. 489 o REQ-019 The mechanism MUST provide a means of indicating to 490 recording-aware UAs whether recording is taking place, for 491 appropriate rendering at the user interface. 493 o REQ-020 The mechanism MUST provide a way for metadata to be 494 conveyed to the SRS incrementally during the CS. 496 o REQ-021 The mechanism MUST NOT prevent high availability 497 deployments. 499 o REQ-022 The mechanism MUST provide means for facilitating 500 synchronization of the recorded media streams and metadata. 502 o REQ-023 The mechanism MUST provide means for facilitating 503 synchronization among the recorded media streams. 505 o REQ-024 The mechanism MUST provide means to relate recording and 506 recording controls such as start/stop/pause/resume to the wall clock 507 time. 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 include a means for ensuring that the 516 integrity of the metadata sent from SRC to SRS is an accurate 517 representation of the original CS metadata. 519 o REQ-028 The mechanism MUST include a means for ensuring that the 520 integrity of the media sent from SRC to SRS is an accurate 521 representation of the original CS media. 523 o REQ-029 The mechanism MUST include a means for ensuring the 524 confidentiality of the 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 vary widely by 549 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 its participation in a CS). Typically users within the 552 domain that is carrying out the recording will be subject to policies 553 of that domain concerning whether CSs are recorded. For example, in 554 a call centre, agents will be subject to policies of the call centre 555 and may or may not have the right to prevent the recording of a CS or 556 part of a CS. Users calling into the call centre, on the other hand, 557 will typically have to ask the agent not to record the CS. If the 558 agent is unable to prevent recording, or if the caller does not trust 559 the agent, the only option generally is to terminate the CS. 561 Privacy considerations also extend to what happens to a recording 562 once it has been created. Typical issues are who can access the 563 recording (e.g., receive a copy of the recording, view the metadata, 564 play back the media, etc.), for what purpose the recording can be 565 used (e.g., for training purposes, for quality control purposes, 566 etc.) and for how long the recording is to be retained before 567 deletion. These are typically policies of the domain that makes the 568 recording, rather than policies of individual users involved in a 569 recorded CS, whether those users be in the same domain or in a 570 different domain. Taking the call centre example again, agents might 571 be made aware of call centre policy regarding retention and use of 572 recordings as part of their employment contract, and callers from 573 outside the call centre might be given some information about policy 574 when notified that a CS will be recorded (e.g., through an 575 announcement that says that calls may be recorded for quality 576 purposes). 578 This document does not specify any requirements for a user engaged in 579 a CS to be able to dictate policy for what happens to a recording, or 580 for such information to be conveyed from an SRC to an SRS. It is 581 assumed that the SRS has access to policy applicable to its 582 environment and can ensure that recordings are stored and used in 583 accordance with that policy. 585 7. Security Considerations 587 Session recording has substantial security implications, for the SIP 588 UA's being recorded, the SRC, and the SRS. 590 For the SIP UA's involved in the Communication Session, the 591 requirements in this draft enable the UA to identify that a 592 Communication Session is being recorded and for the UA to request 593 that a given Communication Session is not subject to recording. 595 Since humans don't typically look at or know about protocol signaling 596 such as SIP, and indeed the SIP session might have originated through 597 a PSTN Gateway without any ability to pass on in-signaling 598 indications of recording, users can be notified of recording in the 599 media itself through voice announcements, a visual indicator on the 600 endpoint, or other means. 602 With regards to security implications of the protocol(s), clearly 603 there is a need for authentication, authorization and eavesdropping 604 protection for the solution. The SRC needs to know the SRS it is 605 communicating with is legitimate, and vice-versa, even if they are in 606 different domains. Both the signaling and media for the Recording 607 Session need the ability to be authenticated and protected from 608 eavesdropping. Requirements are detailed in the requirements 609 section. 611 Communication Sessions and Recording Sessions can require different 612 security levels both for signaling and media, depending on deployment 613 configurations. For some environments, for example, SRS and SRC will 614 be collocated in a secure network region and therefore the RS will 615 not require the same protection level as a CS that extends over a 616 public network, for example. For other environments, the SRS can be 617 located in a public cloud, for example, and the RS will require a 618 higher protection level than the CS. For these reasons, there is not 619 a direct relationship between the security level of Communication 620 Sessions and the security level of Recording Sessions. 622 A malicious or corrupt SRC can tamper with media and metadata 623 relating to a CS before sending to an SRS. Also CS media and 624 signaling can be tampered with in the network prior to reaching an 625 SRC, unless proper means are provided to ensure integrity protection 626 during transmission on the CS. Means for ensuring the correctness of 627 media and metadata emitted by an SRC are outside the scope of this 628 work. Other organizational and technical controls will need to be 629 used to prevent tampering. 631 8. IANA Considerations 633 This document has no IANA actions. 635 9. Acknowledgements 637 Thanks to Dan Wing, Alan Johnson, Vijay Gurbani, Cullen Jennings, 638 Hadriel Kaplan, Henry Lum, Dave Smith, Martin Palmer, Alissa Cooper, 639 Deepanshu Gautam, Paul Kyzivat, Parthasarathi R, Ram Mohan R, and 640 Charles Eckel for their significant contributions and assistance with 641 this document and Working Group, and to all the members of the 642 DISPATCH WG and SIPREC WG mailing lists for providing valuable input 643 to this work. 645 10. Normative References 647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 648 Requirement Levels", BCP 14, RFC 2119, March 1997. 650 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 651 A., Peterson, J., Sparks, R., Handley, M., and E. 652 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 653 June 2002. 655 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 656 Conversation", RFC 4103, June 2005. 658 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 659 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 660 December 2006. 662 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 663 RFC 4949, August 2007. 665 Authors' Addresses 667 Ken Rehor (editor) 668 Cisco Systems 669 170 West Tasman Dr. 670 Mail Stop SJC30/2/ 671 San Jose, CA 95134 672 USA 674 Email: krehor@cisco.com 676 Leon Portman (editor) 677 NICE Systems 678 8 Hapnina 679 Ra'anana 43017 680 Israel 682 Email: leon.portman@nice.com 684 Andrew Hutton 685 Siemens Enterprise Communications 687 Email: andrew.hutton@siemens-enterprise.com 688 URI: http://www.siemens-enterprise.com 690 Rajnish Jain 691 IPC Systems 692 777 Commerce Drive 693 Fairfield, CT 06825 694 USA 696 Email: rajnish.jain@ipc.com