idnits 2.17.1 draft-ietf-siprec-req-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 12, 2010) is 4943 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4103' is mentioned on line 139, but not defined == Unused Reference: 'RFC2804' is defined on line 634, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DISPATCH K. Rehor, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Informational R. Jain 5 Expires: April 15, 2011 IPC Systems 6 L. Portman 7 NICE Systems 8 A. Hutton 9 Siemens Enterprise Communications 10 October 12, 2010 12 Requirements for SIP-based Media Recording (SIPREC) 13 draft-ietf-siprec-req-03 15 Abstract 17 Session recording is a critical requirement in many business 18 communications environments such as call centers and financial 19 trading floors. In some of these environments, all calls must be 20 recorded for regulatory and compliance reasons. In others, calls may 21 be recorded for quality control or business analytics. 23 Recording is typically done by sending a copy of the session media to 24 the recording devices. This document specifies requirements for 25 extensions to SIP that will manage delivery of RTP media from an end- 26 point that originates media (or that has access to it) to a recording 27 device. This is being referred to as SIP-based Media Recording. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 15, 2011. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 76 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 4. Example Deployment Architectures . . . . . . . . . . . . . . . 6 79 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 84 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 11. Normative References . . . . . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Requirements notation 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119] and indicate 93 requirement levels for compliant mechanisms. 95 2. Introduction 97 Session recording is a critical operational requirement in many 98 businesses, especially where voice is used as a medium for commerce 99 and customer support. A prime example where voice is used for trade 100 is the financial industry. The call recording requirements in this 101 industry are quite stringent. The recorded calls are used for 102 dispute resolution and compliance. Other businesses such as customer 103 support call centers typically employ call recording for quality 104 control or business analytics, with different requirements. 106 Depending on the country and its regulatory requirements, financial 107 trading floors typically must record all calls. The recorded media 108 content must be an exact copy of the actual conversation (i.e. 109 clipping and loss of media are unacceptable). A new call attempt 110 would be automatically rejected if the recording device becomes 111 temporarily unavailable. An existing call would be dropped in the 112 same situation. In contrast, support call centers typically only 113 record a subset of the calls, and calls must not fail regardless of 114 the availability of the recording device. 116 Furthermore, the scale and cost burdens vary widely, in all markets, 117 where the different needs for solution capabilities such as media 118 injection, transcoding, and security-related needs do not conform 119 well to a one-size-fits-all model. If a standardized solution 120 supports all of the requirements from every recording market, but 121 doing so would be expensive for markets with lesser needs, then 122 proprietary solutions for those markets will continue to propagate. 123 Care must be taken, therefore, to make a standards-based solution 124 support optionality and flexibility. 126 This document specifies requirements for using SIP [RFC3261] between 127 a Session Recording Client and a Session Recording Server to control 128 the recording of media that has been transmitted in the context of a 129 Communication Session." The Session Recording Client is the source 130 of the recorded media. The Session Recording Server is the sink of 131 recorded media. It should be noted that the requirements for the 132 protocol between a Session Recording Server and Session Recording 133 Client have very similar requirements (such as codec and transport 134 negotiation, encryption key interchange, firewall traversal) as 135 compared to regular SIP media sessions. The choice of SIP for 136 session recording provides reuse of an existing protocol. 138 The recorded sessions can be any RTP media sessions including voice, 139 video, and text (as defined by [RFC4103]). 141 An archived session recording is typically comprised of the 142 Communication Session media content and the Communication Session 143 Metadata. The Communication Session Metadata allows recording 144 archives to be searched and filtered at a later time and allows a 145 session to be played back in a meaningful way, e.g., with correct 146 synchronization between the media. The Communication Session 147 Metadata needs to be conveyed from the Session Recording Client to 148 the Session Recording Server. (The requirements for session metadata 149 delivery are specified separately [draft-ram-siprec-metadata-00]). 151 This document only considers active recording, where the Session 152 Recording Client purposefully streams media to a Session Recording 153 Server. Passive recording, where a recording device detects media 154 directly from the network, is outside the scope of this document. In 155 addition, lawful intercept is outside the scope of this document. 157 3. Definitions 159 Session Recording Server (SRS): A Session Recording Server (SRS) is a 160 SIP User Agent (UA) that is a specialized media server or collector 161 that acts as the sink of the recorded media. An SRS is a logical 162 function that typically archives media for extended durations of time 163 and provides interfaces for search and retrieval of the archived 164 media. An SRS is typically implemented as a multi-port device that 165 is capable of receiving media from several sources simultaneously. 166 An SRS is typically also the sink of the recorded session metadata. 168 Session Recording Client (SRC): A Session Recording Client (SRC) is a 169 SIP User Agent (UA) that acts as the source of the recorded media, 170 sending it to the SRS. An SRC is a logical function. Its 171 capabilities may be implemented across one or more physical devices. 172 In practice, an SRC could be a personal device (such as a SIP phone), 173 a SIP Media Gateway (MG), a Session Border Controller (SBC) or a SIP 174 Media Server (MS) integrated with an Application Server (AS). This 175 specification defines the term SRC such that all such SIP entities 176 can be generically addressed under one definition. The SRC itself or 177 another entity working on its behalf (such as a SIP Application 178 Server) may act as the source of the recording metadata. 180 Communication Session (CS): A session created between two or more SIP 181 User Agents (UAs) that is the target for recording. 183 Recording Session (RS): The SIP session created between an SRC and 184 SRS for the purpose of recording a Communication Session. 186 Figure 1 pictorially represents the relationship between a Recording 187 Session and Communication Session. 189 +---------------------------------------------------------------+ 190 | (Session Recording Client) | 191 | +-------------+ +-----------+ | 192 | | | Communication Session | | | 193 | | A |<------------------------->| B | | 194 | | | | | | 195 | +-------------+ +-----------+ | 196 +---------------------------------------------------------------+ 197 | 198 | Recording 199 | Session 200 | 201 v 202 +-------------+ 203 | | 204 | Session | 205 | Recording | 206 | Server | 207 | | 208 +-------------+ 210 Figure 1 212 Metadata: Information that describes recorded media and the CS to 213 which they relate. 215 SIPREC: The set of SIP extensions that supports recording of 216 Communication Sessions. 218 Pause and Resume during a Communication Session: Pause: The action of 219 temporarily discontinuing the recording of media during a CS. 220 Resume: The action of recommencing the recording of media for a CS 221 following a pause. 223 4. Example Deployment Architectures 225 A recording system deployment consists of the Recording Client and 226 Recording Server. Recording Control is bi-directional; Recording 227 Media and Communication Session (CS) Metadata are sent from the SRC 228 to SRS. 230 +-------------+ +--------------+ 231 | | CS Metadata | | 232 | Session |-------------------------->| Session | 233 | Recording | | Recording | 234 | Client | Recording Control | Server | 235 | (SRC) |<------------------------->| (SRS) | 236 | | | | 237 | | Recorded Media | | 238 | |-------------------------->| | 239 | | | | 240 +-------------+ +--------------+ 242 Figure 2 244 5. Use Cases 246 Use Case 1: Full-time Recording: One (or more, in the case of 247 redundant recording) Recording Session for each Communication 248 Session. 250 For example, the diagram below shows the lifecycle of Communication 251 Sessions (CS) and the relationship to the Recording Sessions (RS) 253 CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| 255 RS |--- RS 1 ---| |--- RS 2 ---| |--- RS 3 ---| 257 Figure 3 259 Record every call for specific extension/person. 261 The need to record all calls is typically due to business process 262 purposes (such as transaction confirmation or dispute resolution) or 263 to ensure compliance with governmental regulations. Applications 264 include enterprise, contact center, and financial trading floors. 266 Also commonly known as Total Recording. 268 Use Case 2: Selective Recording: Start a Recording Session when a 269 Communication Session to be recorded is established. 271 In this example, Communication Sessions 1 and 3 are recorded but CS 2 272 is not. 274 CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| 276 RS |--- RS 1----| |--- RS 2 ---| 278 Figure 4 280 Use Case 3: Dynamic Recording: Start/Stop a Recording Session during 281 a Communication Session. 283 The Recording Session starts during a Communication Session, either 284 manually via a user-controlled mechanism (e.g. button on user's 285 phone) or automatically via an application (e.g. a Contact Center 286 customer service application) or business event. A Recording Session 287 either ends during the Communication Session, or when the 288 Communication Session ends. 290 One or more Recording Sessions per Communication Session: 292 CS |------------- Communication Session -----------| 294 RS |---- RS 1 ----| |---- RS 2 -----| 296 Figure 5 298 Also known as Mid-session or Mid-call Recording. 300 Use Case 4: Persistent Recording: A single Recording Session captures 301 one or more Communication Sessions, in sequence (Fig. 6) or in 302 parallel (Fig. 7). 304 |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| 306 RS |---------------------- Recording Session ---------------------| 308 Figure 6 310 A Recording Session records continuously without interruption. 311 Silent periods must be reproduced upon playback (e.g. by recording 312 the silent period, by not recording the silent periods but marking 313 them as metadata for a player to utilize, etc.) Applications include 314 financial trading desks and emergency (first-responder) service 315 bureaus. The length of a Persistent Recording Sessions is 316 independent from the length of the actual Communication Sessions. 317 Persistent Recording Sessions avoid issues such as media clipping 318 that can occur due to delays in Recording Session establishment. 320 The connection and attributes of media in the Recording Session are 321 not dynamically signaled for each Communication Session before it can 322 be recorded; however, codec re-negotiation is possible. CS details 323 and CS metadata will still be signaled, and can be correlated to the 324 recorded media. There will still need to be a means of correlating 325 the recorded media connection/packets to the Communication Session. 327 In some cases, more than one concurrent Communication Session (on a 328 single end-user apparatus, e.g. trading floor turret) is mixed into 329 one Recording Session: 331 |-------- CS 1 -------| 332 |-------- CS 2 -------| 333 |-------- CS 3 -------| 335 RS |----------- Recording Session --------------| 337 Figure 7 339 Use Case 5: Real-time Recording Controls. 341 For an active Recording Session, privacy or security reasons may 342 demand not capturing a specific portion of a conversation. An 343 example is for PCI (payment card industry) compliance where credit 344 card info must be protected. One solution is to not record a caller 345 speaking their credit card information. 347 An example of a real-time controls is Pause/Resume. 349 Use Case 6: IVR / Voice Portal Recording. 351 Self-service Interactive Voice Response (DTMF or ASR) applications 352 may need to be recorded for application performance tuning or to meet 353 compliance requirements. 355 Metadata about an IVR session recording must include session 356 information and may include application context information (e.g. 357 VoiceXML session variables, dialog names, etc.) 359 Use Case 7: Enterprise Mobility Recording. 361 Many agents and enterprise workers are not located on company 362 premises. 364 Examples: 366 o Home-based agents or enterprise workers. 368 o Mobile phones of knowledge workers when they conduct work related 369 (and legally required recording) calls. i.e. insurance agents, 370 brokers, physicians. 372 Use Case 8: Geographically distributed or centralized recording. 374 Global banks with multiple branches up to thousands of small sites. 376 o Only phones and network infrastructure in branches, no recording 377 services. 379 o Internal calls inside or between branches must be recorded. 381 o Centralized recording system in data centers together with 382 telephony infrastructure (e.g. PBX). 384 Use Case 9: Record complex call scenarios. 386 Record a call that is associated with another call. 388 Example: 390 o Customer in conversation with Agent 392 o Agent puts customer on hold in order to consult with a Supervisor. 394 o Agent in conversation with Supervisor. 396 o Agent disconnects from Supervisor, reconnects with Customer. 398 o The Supervisor call must be associated with the original customer 399 call. 401 Use case 10: High availability and continuous recording. 403 Specific deployment scenarios present different requirements for 404 system availability, error handling, etc. including: 406 o An SRS must always be available at call setup time. 408 o No loss of media recording, including during failure of an SRS. 410 o The Communication Session must be terminated (or suitable 411 notification) in the event of a recording failure. 413 Use Case 11: Record multi-channel, multi-media session. 415 Some applications require the recording of more than one media 416 stream, possibly of different types. Media is synchronized, either 417 at storage or at playback. 419 Speech analytics technologies (e.g. word spotting, emotion detection, 420 speaker identification) may require speaker-separated recordings for 421 optimum performance. 423 Multi-modal Contact Centers may include audio, video, IM or other 424 interaction modalities. 426 In trading floors environments, in order to save resources, it may be 427 preferable to mix multiple concurrent calls (Communication Sessions) 428 on different handsets/speakers on the same turret into single 429 recording session. 431 Use Case 12: Real-time media processing. 433 Recorder must support real-time media processing, such as speech 434 analytics. 436 Recording and real-time analytics of trading floor interactions 437 (including video and instant messaging). Real time analytics is 438 required for automatic intervention (stopping interaction or alert) 439 if for example, trader is not following regulations. 441 Speaker separation is required in order to reliably detect who is 442 saying specific phrases. 444 6. Requirements 446 The following are requirements for SIP-based Media Recording: 448 o REQ-000 The mechanism MUST provide a means for "using the SIP 449 protocol for" establishing, maintaining and terminating Recording 450 Sessions between a Session Recording Client and a Session Recording 451 Server. 453 o REQ-001 The mechanism MUST support the ability to record all CSs in 454 their entirety. 456 o REQ-002 The mechanism MUST support the ability to record selected 457 CSs in their entirety, according to policy. 459 o REQ-003 The mechanism MUST support the ability to record selected 460 parts of selected CSs. 462 o REQ-004 The mechanism MUST support the ability to record a CS 463 without an intentional loss of media (for example, clipping media at 464 the beginning of the CS) and without impacting the quality or timing 465 of the CS (for example, delaying the start of the CS while 466 preparation for recording takes place). See Use Case 4 in Section 5. 468 o REQ-007 The mechanism MUST support the recording of IVR sessions. 470 o REQ-007bis1 The mechanism MUST support the recording of DTMF in- 471 band audio. 473 o REQ-007bis2 The mechanism MUST support the recording of DTMF out- 474 of-band according to RFC2833. 476 o REQ-012 The mechanism MUST support the ability for an SRC to 477 deliver mixed audio streams from multiple Communication Sessions to 478 an SRS. 480 Note: A mixed audio stream is where several Communication Sessions 481 are carried in a single Recording Session. A mixed media stream is 482 typically produced by a mixer function. The RS MAY be informed about 483 the composition of the mixed streams through session metadata. 485 o REQ-012bis: The mechanism MUST support the ability for an SRC to 486 deliver mixed audio streams from different parties of a given 487 Communication Session to an SRS. 489 o REQ-013 The mechanism MUST support the ability to deliver multiple 490 media streams for a given Communication Session over separate 491 Recording Sessions to the SRS. 493 o REQ-014 The mechanism MUST support the ability to deliver multiple 494 media streams for a given Communication Session over a single 495 Recording Session to the SRS. 497 o REQ-015 The mechanism MUST support the ability to pause and resume 498 the Recording Session from the SRC. 500 o REQ-016 The mechanism MUST support the ability to pause and resume 501 the Recording Session from the SRS. 503 o REQ-017 The mechanism MUST provide the SRS with metadata describing 504 CSs that are being recorded, including the media being used and the 505 identities of parties involved. 507 o REQ-018 The mechanism MUST provide the SRS with the means to 508 correlate RS media with CS participant media described in metadata. 510 o REQ-019 The mechanism MUST support the ability to transport the 511 metadata in the same SIP dialog as the Recording Session. 513 o REQ-020 The mechanism MUST support the ability to transport the 514 metadata outside of the Recording Session SIP dialog. 516 o REQ-021 Metadata format must be agnostic of the transport protocol. 518 o REQ-022: The mechanism MUST support a means to cancel and discard 519 the recording and associated metadata for a Communication Session. 521 o REQ-022bis: The mechanism MUST support a means to cancel and 522 discard the recording but not the associated metadata for a 523 Communication Session. 525 o REQ-023 The mechanism MUST support a means for a SIP UA involved in 526 a CS to request, prior to the start of recording, that the CS not be 527 recorded 529 o REQ-024 The mechanism MUST provide a means of indicating to the end 530 users of a Communication Session that the session in which they are 531 participating is being recorded. 533 Examples include: inject tones into the Communication Session from 534 the SRC, play a message at the beginning of a session, a visual 535 indicator on a display, etc. 537 o REQ-025 The mechanism MUST provide a way for metadata to be 538 conveyed to the SRS incrementally. 540 o REQ-028 The mechanism MUST NOT prevent high availability 541 deployments. 543 o REQ-029 The mechanism MUST support a means of providing security 544 (confidentiality, integrity and authentication) for the SIPREC. 546 o REQ-030 The mechanism MUST provide a means for the Recording 547 Session identifier so that the Recording Session itself is labeled as 548 a SIP session that is established for the purpose of recording. 550 o REQ-031 If the Communication Session is encrypted, the Recording 551 Session MUST be able to use the same keys. 553 o REQ-032 If the Communication Session is encrypted, the Recording 554 Session MUST be able to use different keys. 556 o REQ-033 The mechanism SHALL support means to relate Recording 557 Session(s) with Communication Session(s). 559 7. Security Considerations 561 Session recording has substantial security implications, for the SIP 562 UA's being recorded, the SRC, and the SRS. 564 For the SIP UA's involved in the Communication Session, the 565 requirements in this draft enable the UA to identify that a 566 Communication Session is being recorded and for the UA to request 567 that a given Communication Session is not subject to recording. 569 Since humans don't typically look at or know about protocol signaling 570 such as SIP, and indeed the SIP session might have originated through 571 a PSTN Gateway without any ability to pass on in-signaling 572 indications of recording, users can be notified of recording in the 573 media itself through voice announcements, a visual indicator on the 574 endpoint, or other means. 576 With regards to security implications of the protocol(s), clearly 577 there is a need for authentication, authorization, eavesdropping 578 protection, and non-repudiation for the solution. The SRC needs to 579 know the SRS it is communicating with is legitimate, and vice-versa, 580 even if they are in different domains. Both the signaling and media 581 for the SIPREC needs the ability to be authenticated and protected 582 from eavesdropping and non-repudiation. Requirements are detailed in 583 the requirements section. 585 8. IANA Considerations 587 This document has no IANA actions. 589 9. Acknowledgements 591 Thanks to Dan Wing, Alan Johnson, Vijay Gurbani, and Cullen Jennings 592 for their help with this document, and to all the members of the 593 DISPATCH WG mailing list for providing valuable input to this work. 595 10. Contributors 597 In addition to the editors, the following people provided substantial 598 technical and writing contributions to this document, listed 599 alphabetically: 601 Hadriel Kaplan 602 Acme Packet 603 71 Third Ave. 605 Burlington, MA 01803 606 USA 607 hkaplan@acmepacket.com 609 Henry Lum 610 Genesys, Alcatel-Lucent 611 1380 Rodick Road, Suite 200 612 Markham, Ontario L3R 4G5 613 Canada 614 henry.lum@genesyslab.com 616 Martin Palmer 617 BT Global Services 618 Annandale House,1 Hanworth Road, 619 Sunbury on Thames Middlesex TW16 5DJ 620 UK 621 martin.4.palmer@bt.com 623 Dave Smith 624 Genesys, Alcatel-Lucent 625 2001 Junipero Serra Blvd, Daly City, CA 94014 626 USA 627 dsmith@genesyslab.com 629 11. Normative References 631 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 632 Requirement Levels", BCP 14, RFC 2119, March 1997. 634 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 635 May 2000. 637 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 638 A., Peterson, J., Sparks, R., Handley, M., and E. 639 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 640 June 2002. 642 Authors' Addresses 644 Ken Rehor (editor) 645 Cisco Systems 646 170 West Tasman Dr. 647 Mail Stop SJC30/2/ 648 San Jose, CA 95134 649 USA 651 Email: krehor@cisco.com 653 Rajnish Jain 654 IPC Systems 655 777 Commerce Drive 656 Fairfield, CT 06825 657 USA 659 Email: rajnish.jain@ipc.com 661 Leon Portman 662 NICE Systems 663 8 Hapnina 664 Ra'anana 43017 665 Israel 667 Email: leon.portman@nice.com 669 Andrew Hutton 670 Siemens Enterprise Communications 672 Email: andrew.hutton@siemens-enterprise.com 673 URI: http://www.siemens-enterprise.com