idnits 2.17.1 draft-ietf-siprec-req-10.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 (May 03, 2011) is 4743 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: November 4, 2011 NICE Systems 6 A. Hutton 7 Siemens Enterprise 8 Communications 9 R. Jain 10 IPC Systems 11 May 03, 2011 13 Use Cases and Requirements for SIP-based Media Recording (SIPREC) 14 draft-ietf-siprec-req-10 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 November 4, 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 . . . . . . . . . . . . . . . . . . . . 12 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 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, the scale and cost burdens vary widely, in all markets, 104 where the different needs for solution capabilities such as media 105 injection, transcoding, and security-related needs do not conform 106 well to a one-size-fits-all model. If a standardized solution 107 supports all of the requirements from every recording market, but 108 doing so would be expensive for markets with lesser needs, then 109 proprietary solutions for those markets will continue to propagate. 110 Care must be taken, therefore, to make a standards-based solution 111 support optionality and 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 4. Use Cases 213 Use Case 1: Full-time Recording: One Recording Session for each 214 Communication Session. 216 For example, the diagram below shows the lifecycle of Communication 217 Sessions (CS) and the relationship to the Recording Sessions (RS) 219 CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| 221 RS |--- RS 1 ---| |--- RS 2 ---| |--- RS 3 ---| 223 Figure 2 225 Record every CS for specific extension/person. 227 The need to record all calls is typically due to business process 228 purposes (such as transaction confirmation or dispute resolution) or 229 to ensure compliance with governmental regulations. Applications 230 include enterprise, contact center, and financial trading floors. 232 Also commonly known as Total Recording. 234 Use Case 2: Selective Recording: Start a Recording Session when a 235 Communication Session to be recorded is established. 237 In this example, Communication Sessions 1 and 3 are recorded but CS 2 238 is not. 240 CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| 242 RS |--- RS 1----| |--- RS 2 ---| 244 Figure 3 246 Use Case 3: Start/Stop a Recording Session during a Communication 247 Session. 249 The Recording Session starts during a Communication Session, either 250 manually via a user-controlled mechanism (e.g. button on user's 251 phone) or automatically via an application (e.g. a Contact Center 252 customer service application) or business event. A Recording Session 253 either ends during the Communication Session, or when the 254 Communication Session ends. One or more Recording Sessions may 255 record each Communication Session. 257 CS |------------- Communication Session -----------| 259 RS |---- RS 1 ----| |---- RS 2 -----| 261 Figure 4 263 Use Case 4: Persistent Recording: A single Recording Session captures 264 one or more Communication Sessions. 266 |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| 268 RS |---------------------- Recording Session ---------------------| 270 Figure 5 272 A Recording Session records continuously without interruption. 273 Periods when there is no CS in progress must be reproduced upon 274 playback (e.g. by recording silence during such periods or by not 275 recording such periods but marking them by means of metadata for 276 utilization on playback, etc.). Applications include financial 277 trading desks and emergency (first-responder) service bureaus. The 278 length of a Persistent Recording Session is independent from the 279 length of the actual Communication Sessions. Persistent Recording 280 Sessions avoid issues such as media clipping that can occur due to 281 delays in Recording Session establishment. 283 The connection and attributes of media in the Recording Session are 284 not dynamically signaled for each Communication Session before it can 285 be recorded; however, codec re-negotiation is possible. 287 In some cases, more than one concurrent Communication Session (on a 288 single end-user apparatus, e.g. trading floor turret) is mixed into 289 one Recording Session: 291 |-------- CS 1 -------| 292 |-------- CS 2 -------| 293 |-------- CS 3 -------| 295 RS |----------- Recording Session --------------| 297 Figure 6 299 Use Case 5: Real-time Recording Controls. 301 For an active Recording Session, privacy or security reasons may 302 demand not capturing a specific portion of a conversation. An 303 example is for PCI (payment card industry) compliance where credit 304 card info must be protected. One solution is to not record a caller 305 speaking their credit card information. 307 An example of a real-time controls is Pause/Resume. 309 Use Case 6: IVR / Voice Portal Recording. 311 Self-service Interactive Voice Response applications may need to be 312 recorded for application performance tuning or to meet compliance 313 requirements. 315 Metadata about an IVR session recording must include session 316 information and may include application context information (e.g. 317 VoiceXML session variables, dialog names, etc.) 319 Use Case 7: Enterprise Mobility Recording. 321 Many agents and enterprise workers whose calls are to be recorded are 322 not located on company premises. 324 Examples: 326 o Home-based agents or enterprise workers. 328 o Mobile phones of knowledge workers when they conduct work related 329 (and legally required recording) calls. e.g. insurance agents, 330 brokers, physicians. 332 Use Case 8: Geographically distributed or centralized recording. 334 Enterprises such as banks, insurance agencies, and retail stores may 335 have many locations, possibly up to thousands of small sites. 336 Frequently only phones and network infrastructure are installed in 337 branches, without local recording services. In cases where calls 338 inside or between branches must be recorded, a centralized recording 339 system in data centers together with telephony infrastructure (e.g. 340 PBX) may be deployed. 342 Use Case 9: Record complex call scenarios. 344 The following is an example of a scenario where one call that is 345 recorded must be associated with a related call that also must be 346 recorded. 348 o A Customer is in a conversation with a Customer Service Agent. 350 o Agent puts Customer on hold in order to consult with a Supervisor. 352 o Agent enters into a conversation with Supervisor. 354 o Agent disconnects from Supervisor, then reconnects with Customer. 356 o The Supervisor call must be associated with the original customer 357 call. 359 Use case 10: High availability and continuous recording. 361 Specific deployment scenarios present different requirements for 362 system availability, error handling, etc. including: 364 o An SRS must always be available at call setup time. 366 o No loss of media recording, including during failure of an SRS. 368 o The Communication Session must be terminated (or suitable 369 notification given to parties) in the event of a recording failure. 371 Use Case 11: Record multi-channel, multi-media session. 373 Some applications require the recording of more than one media 374 stream, possibly of different types. Media are synchronized, either 375 at storage or at playback. 377 Speech analytics technologies (e.g. word spotting, emotion detection, 378 speaker identification) may require speaker-separated recordings for 379 optimum performance. 381 Multi-modal Contact Centers may include audio, video, IM or other 382 interaction modalities. 384 In trading floors environments, in order to minimize storage and 385 recording system resources, it may be preferable to mix multiple 386 concurrent calls (Communication Sessions) on different handsets/ 387 speakers on the same turret into single recording session. 389 Use Case 12: Real-time media processing. 391 It must be possible for an SRS to support real-time media processing, 392 such as speech analytics of trading floor interactions. Real-time 393 analytics may be employed for automatic intervention (stopping 394 interaction or alerting) if for example, a trader is not following 395 regulations. 397 Speaker separation is required in order to reliably detect who is 398 saying specific phrases. 400 5. Requirements 402 The following are requirements for SIP-based Media Recording: 404 o REQ-001 The mechanism MUST provide a means for using the SIP 405 protocol for establishing, maintaining and terminating Recording 406 Sessions between a Session Recording Client and a Session Recording 407 Server. 409 o REQ-002 The mechanism MUST support the ability to record all CSs in 410 their entirety. 412 o REQ-003 The mechanism MUST support the ability to record selected 413 CSs in their entirety, according to policy. 415 o REQ-004 The mechanism MUST support the ability to record selected 416 parts of selected CSs. 418 o REQ-005 The mechanism MUST support the ability to record a CS 419 without loss of media (for example, clipping media at the beginning 420 of the CS) due to RS recording preparation and also, without 421 impacting the quality or timing of the CS (for example, delaying the 422 start of the CS while preparation for recording session). See Use 423 Case 4 in Section 4 for more details. 425 o REQ-006 The mechanism MUST support the recording of IVR sessions. 427 o REQ-007 The mechanism MUST support the recording of RTP media types 428 voice, DTMF (as defined by [RFC4733]), video, and text (as defined by 429 [RFC4103]). 431 o REQ-008 The mechanism MUST support the ability for an SRC to 432 deliver mixed audio streams from multiple Communication Sessions to 433 an SRS. 435 Note: A mixed audio stream is where several related Communication 436 Sessions are carried in a single Recording Session. A mixed media 437 stream is typically produced by a mixer function. The RS MAY be 438 informed about the composition of the mixed streams through session 439 metadata. 441 o REQ-009: The mechanism MUST support the ability for an SRC to 442 deliver mixed audio streams from different parties of a given 443 Communication Session to an SRS. 445 o REQ-010 The mechanism MUST support the ability to deliver to the 446 SRS multiple media streams for a given CS. 448 o REQ-011 The mechanism MUST support the ability to pause and resume 449 the transmission and collection of RS media. 451 o REQ-012 The mechanism MUST include a means for providing the SRS 452 with metadata describing CSs that are being recorded, including the 453 media being used and the identities of parties involved. 455 o REQ-013 The mechanism MUST include a means for the SRS to be able 456 to correlate RS media with CS participant media. 458 o REQ-014 Metadata format must be agnostic of the transport protocol. 460 o REQ-015: The mechanism MUST support a means to stop the recording. 462 o REQ-016: The mechanism MUST support a means for a recording-aware 463 UA involved in a CS to request at session establishment time that the 464 CS should be recorded or should not be recorded, the honoring of such 465 a request being dependent on policy. 467 o REQ-017: The mechanism MUST support a means for a recording-aware 468 UA involved in a CS to request during a session that the recording of 469 the CS should be started, paused, resumed or stopped, the honoring of 470 such a request being dependent on policy. 472 o REQ-018 The mechanism MUST NOT prevent the application of tones or 473 announcements during recording or at the start of a CS to support 474 notification to participants that the call is being recorded or may 475 be recorded. 477 o REQ-019 The mechanism MUST provide a means of indicating to 478 recording-aware UAs whether recording is taking place, for 479 appropriate rendering at the user interface. 481 o REQ-020 The mechanism MUST provide a way for metadata to be 482 conveyed to the SRS incrementally during the CS. 484 o REQ-021 The mechanism MUST NOT prevent high availability 485 deployments. 487 o REQ-022 The mechanism MUST provide means for facilitating 488 synchronization of the recorded media streams and metadata. 490 o REQ-023 The mechanism MUST provide means for facilitating 491 synchronization among the recorded media streams. 493 o REQ-024 The mechanism MUST provide means to relate recording and 494 recording controls such as start/stop/pause/resume to the wall clock 495 time. 497 o REQ-025 The mechanism MUST support functionality such that if the 498 CS is encrypted, the RS may use the same or different encryption 499 keys. 501 o REQ-026 The mechanism MUST provide means for an SRS to authenticate 502 the SRC on RS initiation. 504 o REQ-027 The mechanism MUST provide means for an SRC to authenticate 505 the SRS on RS initiation. 507 o REQ-028 The mechanism MUST include a means for ensuring that the 508 integrity of the metadata sent from SRC to SRS is an accurate 509 representation of the original CS metadata. 511 o REQ-029 The mechanism MUST include a means for ensuring that the 512 integrity of the media sent from SRC to SRS is an accurate 513 representation of the original CS media. 515 o REQ-030 The mechanism MUST include a means for ensuring the 516 confidentiality of the Metadata sent from SRC to SRS. 518 o REQ-031 The mechanism MUST provide a means to support RS 519 confidentiality. 521 o REQ-032 The mechanism MUST support the ability to deliver to the 522 SRS multiple media streams of the same media type (e.g. audio, 523 video). For example in the case of delivering unmixed audio for each 524 participant in the CS. 526 6. Privacy Considerations 528 Respecting the privacy rights and wishes of users engaged in a call 529 is of paramount importance. In many jurisdictions participants have 530 a right to know that the session is being recorded or might be 531 recorded, and have a right to opt out, either by terminating the call 532 or by demanding that the call not be recorded. Therefore this 533 document contains requirements for being able to notify users that a 534 call is being recorded and for users to be able to request that a 535 call not be recorded. Use cases where users participating in a call 536 are not informed that the call is or might be recorded are outside 537 the scope of this document. In particular, lawful intercept is 538 outside the scope of this document. 540 Requirements for participant notification of recording vary widely by 541 jurisdiction. In a given deployment, not all users will be 542 authorized to stop the recording of a CS (although any user can 543 terminate its participation in a CS). Typically users within the 544 domain that is carrying out the recording will be subject to policies 545 of that domain concerning whether CSs are recorded. For example, in 546 a call centre, agents will be subject to policies of the call centre 547 and may or may not have the right to prevent the recording of a CS or 548 part of a CS. Users calling into the call centre, on the other hand, 549 will typically have to ask the agent not to record the CS. If the 550 agent is unable to prevent recording, or if the caller does not trust 551 the agent, the only option generally is to terminate the CS. 553 Privacy considerations also extend to what happens to a recording 554 once it has been created. Typical issues are who can access the 555 recording (e.g., receive a copy of the recording, view the metadata, 556 play back the media, etc.), for what purpose the recording can be 557 used (e.g., for non-repudiation, for training purposes, for quality 558 control purposes, etc.) and for how long the recording is to be 559 retained before deletion. These are typically policies of the domain 560 that makes the recording, rather than policies of individual users 561 involved in a recorded CS, whether those users be in the same domain 562 or in a different domain. Taking the call centre example again, 563 agents might be made aware of call centre policy regarding retention 564 and use of recordings as part of their employment contract, and 565 callers from outside the call centre might be given some information 566 about policy when notified that a CS will be recorded (e.g., through 567 an announcement that says that calls may be recorded for quality 568 purposes). 570 This document does not specify any requirements for a user engaged in 571 a CS to be able to dictate policy for what happens to a recording, or 572 for such information to be conveyed from an SRC to an SRS. It is 573 assumed that the SRS has access to policy applicable to its 574 environment and can ensure that recordings are stored and used in 575 accordance with that policy. 577 7. Security Considerations 579 Session recording has substantial security implications, for the SIP 580 UA's being recorded, the SRC, and the SRS. 582 For the SIP UA's involved in the Communication Session, the 583 requirements in this draft enable the UA to identify that a 584 Communication Session is being recorded and for the UA to request 585 that a given Communication Session is not subject to recording. 587 Since humans don't typically look at or know about protocol signaling 588 such as SIP, and indeed the SIP session might have originated through 589 a PSTN Gateway without any ability to pass on in-signaling 590 indications of recording, users can be notified of recording in the 591 media itself through voice announcements, a visual indicator on the 592 endpoint, or other means. 594 With regards to security implications of the protocol(s), clearly 595 there is a need for authentication, authorization, eavesdropping 596 protection, and non-repudiation for the solution. The SRC needs to 597 know the SRS it is communicating with is legitimate, and vice-versa, 598 even if they are in different domains. Both the signaling and media 599 for the Recording Session need the ability to be authenticated and 600 protected from eavesdropping and non-repudiation. Requirements are 601 detailed in the requirements section. 603 Communication Sessions and Recording Sessions can require different 604 security levels both for signaling and media, depending on deployment 605 configurations. For some environments, for example, SRS and SRC will 606 be collocated in a secure network region and therefore the RS will 607 not require the same protection level as a CS that extends over a 608 public network, for example. For other environments, the SRS can be 609 located in a public cloud, for example, and the RS will require a 610 higher protection level than the CS. For these reasons, there is not 611 a direct relationship between the security level of Communication 612 Sessions and the security level of Recording Sessions. 614 A malicious or corrupt SRC can tamper with media and metadata 615 relating to a CS before sending to an SRS. Also CS media and 616 signaling can be tampered with in the network prior to reaching an 617 SRC, unless proper means are provided to ensure integrity protection 618 during transmission on the CS. Means for ensuring the integrity and 619 correctness of media and metadata emitted by an SRC are outside the 620 scope of this work. Other organizational and technical controls will 621 need to be used to prevent tampering. 623 8. IANA Considerations 625 This document has no IANA actions. 627 9. Acknowledgements 629 Thanks to Dan Wing, Alan Johnson, Vijay Gurbani, Cullen Jennings, 630 Hadriel Kaplan, Henry Lum, Dave Smith, Martin Palmer, Alissa Cooper, 631 Deepanshu Gautam, Paul Kyzivat, Parthasarathi R, Ram Mohan R, and 632 Charles Eckel for their significant contributions and assistance with 633 this document and Working Group, and to all the members of the 634 DISPATCH WG and SIPREC WG mailing lists for providing valuable input 635 to this work. 637 10. Normative References 639 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 640 Requirement Levels", BCP 14, RFC 2119, March 1997. 642 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 643 A., Peterson, J., Sparks, R., Handley, M., and E. 644 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 645 June 2002. 647 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 648 Conversation", RFC 4103, June 2005. 650 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 651 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 652 December 2006. 654 Authors' Addresses 656 Ken Rehor (editor) 657 Cisco Systems 658 170 West Tasman Dr. 659 Mail Stop SJC30/2/ 660 San Jose, CA 95134 661 USA 663 Email: krehor@cisco.com 665 Leon Portman (editor) 666 NICE Systems 667 8 Hapnina 668 Ra'anana 43017 669 Israel 671 Email: leon.portman@nice.com 673 Andrew Hutton 674 Siemens Enterprise Communications 676 Email: andrew.hutton@siemens-enterprise.com 677 URI: http://www.siemens-enterprise.com 678 Rajnish Jain 679 IPC Systems 680 777 Commerce Drive 681 Fairfield, CT 06825 682 USA 684 Email: rajnish.jain@ipc.com