From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6341.txt | 899 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 899 insertions(+) create mode 100644 doc/rfc/rfc6341.txt (limited to 'doc/rfc/rfc6341.txt') diff --git a/doc/rfc/rfc6341.txt b/doc/rfc/rfc6341.txt new file mode 100644 index 0000000..e6397ae --- /dev/null +++ b/doc/rfc/rfc6341.txt @@ -0,0 +1,899 @@ + + + + + + +Internet Engineering Task Force (IETF) K. Rehor, Ed. +Request for Comments: 6341 Cisco Systems +Category: Informational L. Portman, Ed. +ISSN: 2070-1721 NICE Systems + A. Hutton + Siemens Enterprise Communications + R. Jain + IPC Systems + August 2011 + + + Use Cases and Requirements for SIP-Based Media Recording (SIPREC) + +Abstract + + Session recording is a critical requirement in many business + communications environments, such as call centers and financial + trading floors. In some of these environments, all calls must be + recorded for regulatory and compliance reasons. In others, calls may + be recorded for quality control or business analytics. + + Recording is typically performed by sending a copy of the session + media to the recording devices. This document specifies requirements + for extensions to SIP that will manage delivery of RTP media to a + recording device. This is being referred to as SIP-based Media + Recording. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6341. + + + + + + + + + +Rehor, et al. Informational [Page 1] + +RFC 6341 Requirements for SIPREC August 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Requirements Notation ...........................................4 + 3. Definitions .....................................................4 + 4. Use Cases .......................................................5 + 5. Requirements ...................................................10 + 6. Privacy Considerations .........................................13 + 7. Security Considerations ........................................14 + 8. Acknowledgements ...............................................15 + 9. Normative References ...........................................15 + +1. Introduction + + Session recording is a critical operational requirement in many + businesses, especially where voice is used as a medium for commerce + and customer support. A prime example where voice is used for trade + is the financial industry. The call recording requirements in this + industry are quite stringent. The recorded calls are used for + dispute resolution and compliance. Other businesses, such as + customer support call centers, typically employ call recording for + quality control or business analytics, with different requirements. + + Depending on the country and its regulatory requirements, financial + trading floors typically must record all calls. In contrast, call + centers typically only record a subset of the calls, and calls must + not fail, regardless of the availability of the recording device. + + Respecting the privacy rights and wishes of users engaged in a call + is of paramount importance. In many jurisdictions, participants have + a right to know that the session is being recorded or might be + recorded, and they have a right to opt out, either by terminating the + call or by demanding that the call not be recorded. Therefore, this + + + +Rehor, et al. Informational [Page 2] + +RFC 6341 Requirements for SIPREC August 2011 + + + document contains requirements for being able to notify users that a + call is being recorded and for users to be able to request that a + call not be recorded. Use cases where users participating in a call + are not informed that the call is or might be recorded are outside + the scope of this document. In particular, lawful intercept is + outside the scope of this document. + + Furthermore, a one-size-fits-all model will not fit all markets where + the scale and cost burdens vary widely and where needs differ for + such solution capabilities as media injection, transcoding, and + security. If a standardized solution supports all of the + requirements from every recording market but doing so would be + expensive for markets with lesser needs, then proprietary solutions + for those markets will continue to propagate. Care must be taken, + therefore, to make a standards-based solution support optionality and + flexibility. + + This document specifies requirements for using SIP [RFC3261] between + a Session Recording Client and a Session Recording Server to control + the recording of media that has been transmitted in the context of a + Communication Session. A Communication Session is the "call" between + participants. The Session Recording Client is the source of the + recorded media. The Session Recording Server is the sink of recorded + media. It should be noted that the requirements for the protocol + between a Session Recording Server and Session Recording Client have + very similar requirements (such as codec and transport negotiation, + encryption key interchange, and firewall traversal) as compared to + regular SIP media sessions. The choice of SIP for session recording + provides reuse of an existing protocol. + + The recorded sessions can be any RTP media sessions, including voice, + dual-tone multifrequency (DTMF) (as defined by [RFC4733]), video, and + text (as defined by [RFC4103]). + + An archived session recording is typically comprised of the + Communication Session media content and the Communication Session + Metadata. The Communication Session Metadata allows recording + archives to be searched and filtered at a later time and allows a + session to be played back in a meaningful way, e.g., with correct + synchronization between the media. The Communication Session + Metadata needs to be conveyed from the Session Recording Client to + the Session Recording Server. + + This document only considers active recording, where the Session + Recording Client purposefully streams media to a Session Recording + Server. Passive recording, where a recording device detects media + directly from the network, is outside the scope of this document. + + + + +Rehor, et al. Informational [Page 3] + +RFC 6341 Requirements for SIPREC August 2011 + + +2. Requirements Notation + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119] and indicate + requirement levels for compliant mechanisms. + +3. Definitions + + Session Recording Server (SRS): A Session Recording Server (SRS) is a + SIP User Agent (UA) that is a specialized media server or + collector that acts as the sink of the recorded media. An SRS is + typically implemented as a multi-port device that is capable of + receiving media from multiple sources simultaneously. An SRS is + the sink of the recorded session metadata. + + Session Recording Client (SRC): A Session Recording Client (SRC) is a + SIP User Agent (UA) that acts as the source of the recorded media, + sending it to the SRS. An SRC is a logical function. Its + capabilities may be implemented across one or more physical + devices. In practice, an SRC could be a personal device (such as + a SIP phone), a SIP Media Gateway (MG), a Session Border + Controller (SBC), or a SIP Media Server (MS) integrated with an + Application Server (AS). This specification defines the term + "SRC" such that all such SIP entities can be generically addressed + under one definition. The SRC provides metadata to the SRS. + + Communication Session (CS): A session created between two or more SIP + User Agents (UAs) that is the subject of recording. + + Recording Session (RS): The SIP session created between an SRC and + SRS for the purpose of recording a Communication Session. + + Figure 1 pictorially represents the relationship between a Recording + Session and Communication Session. + + + + + + + + + + + + + + + + +Rehor, et al. Informational [Page 4] + +RFC 6341 Requirements for SIPREC August 2011 + + + +-------------+ +-----------+ + | | Communication Session | | + | A |<------------------------------------>| B | + | | | | + +-------------+ +-----------+ + .................................................................. + . Session . + . Recording . + . Client . + .................................................................. + | + | Recording + | Session + | + v + +------------+ + | Session | + | Recording | + | Server | + +------------+ + + Figure 1 + + Metadata: Information that describes recorded media and the CS to + which they relate. + + Pause and Resume during a Communication Session: + Pause: The action of temporarily discontinuing the transmission + and collection of RS media. + Resume: The action of recommencing the transmission and collection + of RS media. + + Most security-related terms in this document are to be understood in + the sense defined in [RFC4949]; such terms include, but are not + limited to, "authentication", "confidentiality", "encryption", + "identity", and "integrity". + +4. Use Cases + + Use Case 1: Full-time Recording: One Recording Session for each + Communication Session. + + For example, the diagram below shows the life cycle of + Communication Sessions (CSs) and the relationship to the Recording + Sessions (RS). + + + + + + +Rehor, et al. Informational [Page 5] + +RFC 6341 Requirements for SIPREC August 2011 + + + CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| + + RS |--- RS 1 ---| |--- RS 2 ---| |--- RS 3 ---| + t---> + + Figure 2 + + Record every CS for each specific extension/person. + + The need to record all calls is typically due to business process + purposes (such as transaction confirmation or dispute resolution) + or to ensure compliance with governmental regulations. + Applications include enterprise, contact center, and financial + trading floors. + + This is also commonly known as Total Recording. + + Use Case 2: Selective Recording: Start a Recording Session when a + Communication Session to be recorded is established. + + In this example, Communication Sessions 1 and 3 are recorded but + CS 2 is not. + + CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| + + RS |--- RS 1----| |--- RS 2 ---| + t---> + + Figure 3 + + Use Case 3: Start/Stop a Recording Session during a Communication + Session. + + The Recording Session starts during a Communication Session, + either manually via a user-controlled mechanism (e.g., a button on + a user's phone) or automatically via an application (e.g., a + contact center customer service application) or business event. A + Recording Session ends either during the Communication Session or + when the Communication Session ends. One or more Recording + Sessions may record each Communication Session. + + + + + + + + + + + +Rehor, et al. Informational [Page 6] + +RFC 6341 Requirements for SIPREC August 2011 + + + CS |------------- Communication Session -----------| + + RS |---- RS 1 ----| |---- RS 2 -----| + t---> + + Figure 4 + + Use Case 4: Persistent Recording: A single Recording Session captures + one or more Communication Sessions. + + |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| + + RS |------------------- Recording Session ------------------| + t---> + + Figure 5 + + A Recording Session records continuously without interruption. + Periods when there is no CS in progress must be reproduced upon + playback (e.g., by recording silence during such periods, or by + not recording such periods but marking them by means of metadata + for utilization on playback, etc.). Applications include + financial trading desks and emergency (first-responder) service + bureaus. The length of a Persistent Recording Session is + independent from the length of the actual Communication Sessions. + Persistent Recording Sessions avoid issues such as media clipping + that can occur due to delays in Recording Session establishment. + + The connection and attributes of media in the Recording Session + are not dynamically signaled for each Communication Session before + it can be recorded; however, codec re-negotiation is possible. + + In some cases, more than one concurrent Communication Session (on + a single end-user apparatus, e.g., trading-floor turret) is mixed + into one Recording Session: + + |-------- CS 1 -------| + |-------- CS 2 -------| + |-------- CS 3 -------| + + RS |----------- Recording Session --------------| + t---> + + Figure 6 + + + + + + + +Rehor, et al. Informational [Page 7] + +RFC 6341 Requirements for SIPREC August 2011 + + + Use Case 5: Real-time Recording Controls. + + For an active Recording Session, privacy or security reasons may + demand not capturing a specific portion of a conversation. An + example is for PCI (payment card industry) compliance where credit + card information must be protected. One solution is not to record + a caller speaking their credit card information. + + An example of a real-time control is Pause/Resume. + + Use Case 6: IVR / Voice Portal Recording. + + Self-service Interactive Voice Response (IVR) applications may + need to be recorded for application performance tuning or to meet + compliance requirements. + + Metadata about an IVR session recording must include session + information and may include application context information (e.g., + VoiceXML session variables, dialog names, etc.). + + Use Case 7: Enterprise Mobility Recording. + + Many agents and enterprise workers whose calls are to be recorded + are not located on company premises. + + Examples: + + o Home-based agents or enterprise workers. + + o Mobile phones of knowledge workers (e.g., insurance agents, + brokers, or physicians) when they conduct work-related (and + legally required recording) calls. + + Use Case 8: Geographically distributed or centralized recording. + + Enterprises such as banks, insurance agencies, and retail stores + may have many locations, possibly up to thousands of small sites. + Frequently, only phones and network infrastructure are installed + in branches, without local recording services. In cases where + calls inside or between branches must be recorded, a centralized + recording system in data centers together with telephony + infrastructure (e.g., Private Branch Exchange (PBX)) may be + deployed. + + + + + + + + +Rehor, et al. Informational [Page 8] + +RFC 6341 Requirements for SIPREC August 2011 + + + Use Case 9: Record complex call scenarios. + + The following is an example of a scenario where one call that is + recorded must be associated with a related call that also must be + recorded. + + o A Customer is in a conversation with a Customer Service Agent. + + o The Agent puts the Customer on hold in order to consult with a + Supervisor. + + o The Agent enters into a conversation with the Supervisor. + + o The Agent disconnects from the Supervisor, then reconnects with + the Customer. + + o The Supervisor call must be associated with the original + Customer call. + + Use Case 10: High availability and continuous recording. + + Specific deployment scenarios present different requirements for + system availability, error handling, etc., including the + following: + + o An SRS must always be available at call setup time. + + o No loss of media recording can occur, including during failure + of an SRS. + + o The Communication Session must be terminated (or suitable + notification given to parties) in the event of a recording + failure. + + Use Case 11: Record multi-channel, multimedia session. + + Some applications require the recording of more than one media + stream, possibly of different types. Media are synchronized, + either at storage or at playback. + + Speech analytics technologies (e.g., word spotting, emotion + detection, speaker identification) may require speaker-separated + recordings for optimum performance. + + Multi-modal contact centers may include audio, video, IM, or other + interaction modalities. + + + + + +Rehor, et al. Informational [Page 9] + +RFC 6341 Requirements for SIPREC August 2011 + + + In trading-floor environments, in order to minimize storage and + recording system resources, it may be preferable to mix multiple + concurrent calls (Communication Sessions) on different handsets/ + speakers on the same turret into a single recording session. + + Use Case 12: Real-time media processing. + + It must be possible for an SRS to support real-time media + processing, such as speech analytics of trading-floor + interactions. Real-time analytics may be employed for automatic + intervention (stopping interaction or alerting) if, for example, a + trader is not following regulations. + + Speaker separation is required in order to reliably detect who is + saying specific phrases. + +5. Requirements + + The following are requirements for SIP-based Media Recording: + + o REQ-001: The mechanism MUST provide a means for using the SIP + protocol for establishing, maintaining, and terminating Recording + Sessions between a Session Recording Client and a Session + Recording Server. + + o REQ-002: The mechanism MUST support the ability to record all CSs + in their entirety. + + o REQ-003: The mechanism MUST support the ability to record selected + CSs in their entirety, according to policy. + + o REQ-004: The mechanism MUST support the ability to record selected + parts of selected CSs. + + o REQ-005: The mechanism MUST support the ability to record a CS + without loss of media of RS (for example, clipping media at the + beginning of the CS) due to RS recording preparation and also + without impacting the quality or timing of the CS (for example, + delaying the start of the CS while preparing for a recording + session). See Use Case 4 in Section 4 for more details. + + o REQ-006: The mechanism MUST support the recording of IVR sessions. + + o REQ-007: The mechanism MUST support the recording of the following + RTP media types: voice, DTMF (as defined by [RFC4733]), video, and + text (as defined by [RFC4103]). + + + + + +Rehor, et al. Informational [Page 10] + +RFC 6341 Requirements for SIPREC August 2011 + + + o REQ-008: The mechanism MUST support the ability for an SRC to + deliver mixed audio streams from multiple Communication Sessions + to an SRS. + + Note: A mixed audio stream is where several related Communication + Sessions are carried in a single Recording Session. A mixed-media + stream is typically produced by a mixer function. The RS MAY be + informed about the composition of the mixed streams through + session metadata. + + o REQ-009: The mechanism MUST support the ability for an SRC to + deliver mixed audio streams from different parties of a given + Communication Session to an SRS. + + o REQ-010: The mechanism MUST support the ability to deliver to the + SRS multiple media streams for a given CS. + + o REQ-011: The mechanism MUST support the ability to pause and + resume the transmission and collection of RS media. + + o REQ-012: The mechanism MUST include a means for providing the SRS + with metadata describing CSs that are being recorded, including + the media being used and the identifiers of parties involved. + + o REQ-013: The mechanism MUST include a means for the SRS to be able + to correlate RS media with CS participant media. + + o REQ-014: Metadata format must be agnostic of the transport + protocol. + + o REQ-015: The mechanism MUST support a means to stop the recording. + + o REQ-016: The mechanism MUST support a means for a recording-aware + UA involved in a CS to request at session establishment time that + the CS should be recorded or should not be recorded, the honoring + of such a request being dependent on policy. + + o REQ-017: The mechanism MUST support a means for a recording-aware + UA involved in a CS to request during a session that the recording + of the CS should be started, paused, resumed, or stopped, the + honoring of such a request being dependent on policy. Such + recording-aware UAs MUST be notified about the outcome of such + requests. + + o REQ-018: The mechanism MUST NOT prevent the application of tones + or announcements during recording or at the start of a CS to + support notification to participants that the call is being + recorded or may be recorded. + + + +Rehor, et al. Informational [Page 11] + +RFC 6341 Requirements for SIPREC August 2011 + + + o REQ-019: The mechanism MUST provide a means of indicating to + recording-aware UAs whether recording is taking place, for + appropriate rendering at the user interface. + + o REQ-020: The mechanism MUST provide a way for metadata to be + conveyed to the SRS incrementally during the CS. + + o REQ-021: The mechanism MUST NOT prevent high-availability + deployments. + + o REQ-022: The mechanism MUST provide means for facilitating + synchronization of the recorded media streams and metadata. + + o REQ-023: The mechanism MUST provide means for facilitating + synchronization among the recorded media streams. + + o REQ-024: The mechanism MUST provide means to relate recording and + recording controls, such as start/stop/pause/resume, to the wall + clock time. + + o REQ-025: The mechanism MUST provide means for an SRS to + authenticate the SRC on RS initiation. + + o REQ-026: The mechanism MUST provide means for an SRC to + authenticate the SRS on RS initiation. + + o REQ-027: The mechanism MUST include a means for ensuring that the + integrity of the metadata sent from the SRC to the SRS is an + accurate representation of the original CS metadata. + + o REQ-028: The mechanism MUST include a means for ensuring that the + integrity of the media sent from the SRC to the SRS is an accurate + representation of the original CS media. + + o REQ-029: The mechanism MUST include a means for ensuring the + confidentiality of the metadata sent from the SRC to the SRS. + + o REQ-030: The mechanism MUST provide a means to support RS + confidentiality. + + o REQ-031: The mechanism MUST support the ability to deliver to the + SRS multiple media streams of the same media type (e.g., audio, + video). One example is the case of delivering unmixed audio for + each participant in the CS. + + + + + + + +Rehor, et al. Informational [Page 12] + +RFC 6341 Requirements for SIPREC August 2011 + + +6. Privacy Considerations + + Respecting the privacy rights and wishes of users engaged in a call + is of paramount importance. In many jurisdictions, participants have + a right to know that the session is being recorded or might be + recorded, and they have a right to opt out, either by terminating the + call or by demanding that the call not be recorded. Therefore, this + document contains requirements for being able to notify users that a + call is being recorded and for users to be able to request that a + call not be recorded. Use cases where users participating in a call + are not informed that the call is or might be recorded are outside + the scope of this document. In particular, lawful intercept is + outside the scope of this document. + + Requirements for participant notification of recording vary widely by + jurisdiction. In a given deployment, not all users will be + authorized to stop the recording of a CS (although any user can + terminate its participation in a CS). Typically, users within the + domain that is carrying out the recording will be subject to policies + of that domain concerning whether CSs are recorded. For example, in + a call center, agents will be subject to policies of the call center + and may or may not have the right to prevent the recording of a CS or + part of a CS. Users calling into the call center, on the other hand, + will typically have to ask the agent not to record the CS. If the + agent is unable to prevent recording, or if the caller does not trust + the agent, the only option generally is to terminate the CS. + + Privacy considerations also extend to what happens to a recording + once it has been created. Typical issues are who can access the + recording (e.g., receive a copy of the recording, view the metadata, + play back the media, etc.), for what purpose the recording can be + used (e.g., for training purposes, for quality control purposes, + etc.), and for how long the recording is to be retained before + deletion. These are typically policies of the domain that makes the + recording, rather than policies of individual users involved in a + recorded CS, whether those users be in the same domain or in a + different domain. Taking the call center example again, agents might + be made aware of call center policy regarding retention and use of + recordings as part of their employment contract, and callers from + outside the call center might be given some information about policy + when notified that a CS will be recorded (e.g., through an + announcement that says that calls may be recorded for quality + purposes). + + + + + + + + +Rehor, et al. Informational [Page 13] + +RFC 6341 Requirements for SIPREC August 2011 + + + This document does not specify any requirements for a user engaged in + a CS to be able to dictate policy for what happens to a recording, or + for such information to be conveyed from an SRC to an SRS. It is + assumed that the SRS has access to policy applicable to its + environment and can ensure that recordings are stored and used in + accordance with that policy. + +7. Security Considerations + + Session recording has substantial security implications, for the SIP + UAs being recorded, the SRC, and the SRS. + + For the SIP UAs involved in the Communication Session, the + requirements in this document enable the UA to identify that a + Communication Session is being recorded and to request that a given + Communication Session not be subject to recording. + + Since humans don't typically look at or know about protocol signaling + such as SIP, and indeed the SIP session might have originated through + a Public Switched Telephone Network (PSTN) gateway without any + ability to pass on in-signaling indications of recording, users can + be notified of recording in the media itself through voice + announcements, a visual indicator on the endpoint, or other means. + + With regard to security implications of the protocol(s), clearly + there is a need for authentication, authorization, and eavesdropping + protection for the solution. The SRC needs to know the SRS it is + communicating with is legitimate, and vice versa, even if they are in + different domains. Both the signaling and media for the Recording + Session need the ability to be authenticated and protected from + eavesdropping. Requirements are detailed in Section 5. + + Communication Sessions and Recording Sessions can require different + security levels both for signaling and media, depending on deployment + configurations. For some environments, e.g., the SRS and SRC will be + collocated in a secure network region, and therefore the RS will not + require the same protection level as a CS that extends over a public + network, for example. For other environments, the SRS can be located + in a public cloud, for example, and the RS will require a higher + protection level than the CS. For these reasons, there is not a + direct relationship between the security level of Communication + Sessions and the security level of Recording Sessions. + + A malicious or corrupt SRC can tamper with media and metadata + relating to a CS before sending the data to an SRS. Also, CS media + and signaling can be tampered with in the network prior to reaching + an SRC, unless proper means are provided to ensure integrity + protection during transmission on the CS. Means for ensuring the + + + +Rehor, et al. Informational [Page 14] + +RFC 6341 Requirements for SIPREC August 2011 + + + correctness of media and metadata emitted by an SRC are outside the + scope of this work. Other organizational and technical controls will + need to be used to prevent tampering. + +8. Acknowledgements + + Thanks to Dan Wing, Alan Johnson, Vijay Gurbani, Cullen Jennings, + Hadriel Kaplan, Henry Lum, Dave Smith, Martin Palmer, Alissa Cooper, + Deepanshu Gautam, Paul Kyzivat, Parthasarathi R, Ram Mohan R, and + Charles Eckel for their significant contributions and assistance with + this document and the SIPREC WG, and to all the members of the + DISPATCH WG and SIPREC WG mailing lists for providing valuable input + to this work. + +9. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + June 2002. + + [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text + Conversation", RFC 4103, June 2005. + + [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF + Digits, Telephony Tones, and Telephony Signals", RFC 4733, + December 2006. + + [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", + FYI 36, RFC 4949, August 2007. + + + + + + + + + + + + + + + + + + +Rehor, et al. Informational [Page 15] + +RFC 6341 Requirements for SIPREC August 2011 + + +Authors' Addresses + + Ken Rehor (editor) + Cisco Systems + 170 West Tasman Dr. + Mail Stop SJC30/2/ + San Jose, CA 95134 + USA + + EMail: krehor@cisco.com + + + Leon Portman (editor) + NICE Systems + 8 Hapnina + Ra'anana 43017 + Israel + + EMail: leon.portman@nice.com + + + Andrew Hutton + Siemens Enterprise Communications + + EMail: andrew.hutton@siemens-enterprise.com + URI: http://www.siemens-enterprise.com + + + Rajnish Jain + IPC Systems + 777 Commerce Drive + Fairfield, CT 06825 + USA + + EMail: rajnish.jain@ipc.com + + + + + + + + + + + + + + + + +Rehor, et al. Informational [Page 16] + -- cgit v1.2.3