One document matched: draft-rehor-dispatch-session-recording-req-00.txt
DISPATCH K. Rehor, Ed.
Internet-Draft Cisco Systems
Intended status: Standards Track R. Jain
Expires: April 29, 2010 IPC Systems
L. Portman
NICE Systems
V. Gurbani
Bell Laboratories, Alcatel-Lucent
H. Kaplan
Acme Packet
A. Hutton
Siemens Enterprise Communications
October 26, 2009
Requirements for Session Recording Protocol (SRP)
draft-rehor-dispatch-session-recording-req-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Rehor, et al. Expires April 29, 2010 [Page 1]
Internet-Draft Requirements for SRP October 2009
This Internet-Draft will expire on April 29, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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 done by sending a copy of the media to the recording
devices. This document specifies requirements for a protocol that
will manage delivery of media from an end-point that originates media
or that has access to it to a recording device. This protocol is
being referred to as Session Recording Protocol and will most likely
be based on SIP.
Rehor, et al. Expires April 29, 2010 [Page 2]
Internet-Draft Requirements for SRP October 2009
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Example Deployment Architectures . . . . . . . . . . . . . . . 9
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Rehor, et al. Expires April 29, 2010 [Page 3]
Internet-Draft Requirements for SRP October 2009
1. 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.
2. 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. The recorded media
content must be an exact copy of the actual conversation (i.e.
clipping and loss of media are unacceptable). A new call attempt
would be automatically rejected if the recording device becomes
temporarily unavailable. An existing call would be dropped in the
same situation. In contrast, support call centers typically only
record a subset of the calls, and calls must not fail regardless of
the availability of the recording device.
Furthermore, the scale and cost burdens vary widely, in all markets,
where the different needs for solution capabilities such as media
injection, transcoding, and security-related needs do not conform
well to a one-size-fits-all model. 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.
It should be noted that the requirements for the protocol between a
Recording Server and Recording Client have very similar requirements
(such as codec and transport negotiation, encryption key interchange,
firewall traversal) as compared to regular SIP media sessions. The
choice of SIP for session recording provides reuse of an existing
protocol. This document specifies requirements for a protocol
between a Recording Client and a Recording Server, which is most
likely going to be SIP[RFC3261] itself. The Recording Client is the
source of the recorded media. The Recording Server is the sink of
Rehor, et al. Expires April 29, 2010 [Page 4]
Internet-Draft Requirements for SRP October 2009
recorded media.
The recorded sessions can be of any kind such as voice, video and
instant messaging. An archived session recording is typically
comprised of the session media content and the session metadata. The
session metadata allows recording archives to be searched and
filtered at a later time. The conveyance of session metadata from
the Recording Client to the Recording Server may or may not be over
SIP. The requirements for session metadata delivery will be
specified in a future revision of this document or in a separate
document.
This document only looks into active recording, where the Recording
Client purposefully streams media to a Recording Server. Passive
recording, where a recording device detects media directly from the
network, is outside the scope of this document. In addition, lawful
intercept is outside the scope of this document.
Another, related IETF draft is draft-wing-sipping-srtp-key
[I-D.wing-sipping-srtp-key], which describes an approach for
providing SRTP session keys to a recorder-type server. That draft
focuses on the mechanism to provide the SRTP session key, rather than
the mechanism to invoke and sustain recording sessions themselves.
There are already IETF Working Groups focusing on related or similar
concepts: Mediactrl and Xcon. The work to address the requirements
outlined in this draft may end up being done in those Working Groups,
or a new one may be formed.
3. Definitions
Recording Server (RS): A Recording Server (RS) is a specialized media
server or collector that acts as the sink of the recorded media. An
RS typically archives media for extended durations of time and
provides interfaces for search and retrieval of the archived media.
An RS is typically implemented as a multi-port device that is capable
of receiving media from several sources simultaneously. An RS is
typically also the sink of the recorded session metadata. Note that
the term "Server" does not imply the RS is the server side of a
signaling protocol - the RS may be the initiator of recording
requests, for example.
Recording Client (RC): A Recording Client (RC) is a SIP User Agent
(UA) or a Back-to-Back User Agent (B2BUA) that acts as the source of
the recorded media, sending it to the RS. An RC is a logical
function. Its capabilities may be implemented across one or more
physical devices. In practice, an RC could be a personal device
Rehor, et al. Expires April 29, 2010 [Page 5]
Internet-Draft Requirements for SRP October 2009
(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 RC such
that all such SIP entities can be generically addressed under one
definition. The RC itself or another entity working on its behalf
(such as a SIP Application Server) may act as the source of the
recording metadata.
Session Recording Protocol (SRP): The Session Recording Protocol
(SRP) is a to-be-defined protocol that will be used to establish
media sessions between an RC and RS, for the purpose of delivering
media from the RC to the RS. It may, for example, be SIP.
Recording Session: The session created between an RC and RS for the
purpose of recording a Recorded Session. The Recorded Session may
itself be based on SIP, but it is a separate session from the
Recording Session.
Recorded Session: A session created between a UAC and UAS that is
recorded by the RC and RS systems.
Dynamic Recording: Dynamic recording is a mode of recording where the
recording sessions are established on an as needed basis. The length
of these sessions is typically same as the length of the actual media
sessions.
Persistent Recording: Persistent recording is a mode of recording
where the recording sessions are established at system start-up and
kept-alive from that point on. The length of these sessions is
independent from the length of the actual recorded media sessions.
Persistent recording sessions avoid issues such as media clipping
that can occur due to delays in recording session establishment.
Business Analytics: Business analytics refers to analyzing recorded
media and the related metadata for various kinds of business goals
such as decision making, statistical and quantitative analysis.
4. Use Cases
Use Case 1: Full-time Recording
Record all calls:
o Regulatory compliance or business process purposes.
o Enterprise or Contact Center.
Rehor, et al. Expires April 29, 2010 [Page 6]
Internet-Draft Requirements for SRP October 2009
Use Case 2: Selective recording
Record only specific calls. Selection of a call to be recorded may
be made automatically based on business rules, or manually via a
user-controlled mechanism (e.g. button on user&rsquos phone):
o Enterprise back office recording where only specific calls (based
on privacy) have to be recorded
o A user requests session recording at call setup time or during a
call.
Use Case 3: Persistent recording
Record continuously without interruption. Applications include
financial trading desks and emergency (first-responder) service
bureaus.
Use Case 4: 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 info must be protected. One solution is to not record a caller
speaking their credit card information.
Real-time controls may include Pause/Resume, or Mute/Unmute.
Use Case 5: IVR / Voice Portal Recording
Self-service Interactive Voice Response (DTMF or ASR) applications
may need to be recorded for application performance tuning or to meet
compliance requirements.
Use Case 6: Enterprise Mobility Recording
Many agents and agents and enterprise workers are not located on
company premises.
Examples:
o Home-based agents or enterprise workers.
o Mobile phones of knowledge workers when they conduct work related
(and legally required recording) calls. i.e. insurance agents,
brokers, physicians.
Use Case 7: Geographically distributed or centralized recording
Rehor, et al. Expires April 29, 2010 [Page 7]
Internet-Draft Requirements for SRP October 2009
Global banks with multiple branches &mdash up to thousands of small
sites
o Only phones and network infrastructure in branches, no recording
services.
o Internal calls inside or between branches must be recorded.
o Centralized recording system in data centers together with
telephony infrastructure (e.g. PBX).
Obtain media by forking:
o In data centers (inbound/outbound): fork media in gateway.
o At branch locations (internal): fork from end points or from site
level gateways.
o Conference based solution is not applicable because it will require
to reroute all communications via data centers.
Use Case 8: Record complex calls
Record a call that is associated with another call.
Example:
o Customer in conversation with Agent
o Agent puts customer on hold in order to consult with a supervisor.
o Agent in conversation with Supervisor.
o Agent disconnects from Supervisor, reconnects with Customer.
o Each conversation is stored as a separate recording. The
Supervisor call must be associated with the original customer call.
Use case 9: High-Availability, High Reliability Recording
If recorder is not available at call setup time:
o Reject request to establish recorded session.
o Redirect to alternate recorder
If recorder has failed during a call, take specific action:
Rehor, et al. Expires April 29, 2010 [Page 8]
Internet-Draft Requirements for SRP October 2009
o Fail/Transfer call / fail over to a different recorder (may involve
loss of recording during transition time).
o Failover recovery situation: continuation of a call recorded on a
different recorder. Protocol must indicate that a Recording Session
is a continuation of a previous Recording Session.
For some use cases, if recording is not available or failed in a
middle of the call, original conversation has to be terminated or
alerted as well.
Use Case 10: Record multi-channel, multi-media session
Some applications require the recording of more than one media
stream, possibly of different types. Media is 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.
Use Case 11: Real-time media processing
Recorder must support real-time media processing, such as speech
analytics.
Recording and real-time analytics of trading floor interactions
(including video and instant messaging). Real time analytics is
required for automatic intervention (stopping interaction or alert)
if for example, trader is not following regulations.
Speaker separation is required in order to reliably detect who is
saying specific phrases.
5. Example Deployment Architectures
Although this document discusses requirements and not solutions,
there are certain assumptions made regarding the solution space. One
goal is to support existing, deployed architectures for Session
Recording. Session Recording is an established practice, albeit with
proprietary protocols; it is the protocols between systems that this
document aims at addressing requirements towards, in order to
eventually produce an IETF defined protocol, or a set of protocols,
for performing Session Recording in a non-proprietary fashion.
Rehor, et al. Expires April 29, 2010 [Page 9]
Internet-Draft Requirements for SRP October 2009
The current Session Recording market typically performs recording in
one of the two ways. In some cases, a middle-box acts as a RC and
sends media to the recorder (RS). A simple diagram of this is shown
below:
The following figure presents recording from Media Server
configuration example
logical or physical
B2BUA (the RC)
+-----------------+
| |
| +---------+ | Recording Control +--------------+
SIP | | | | Call Metadata events | Recorder |
+----------------------->| A/S |<------------------------->| (RS) |
| | | |<-----------------------+ | |
| | +---------+ | | +--------------+
| | ^ | SIP| ^
| | MEDIACTRL | | |
v | v | v |
+-------------+ | +---------+ | +-------------+ |
| | | | Media | | | | |
| UA-B |<--------------->| Server |<--------------->| UA-C | |
| | RTP | +---------+ | RTP | | |
+-------------+ | ^ | +-------------+ |
+--------|--------+ |
| Recorded media |
+---------------------------------------+
Recording from Media Server
Figure 1
Rehor, et al. Expires April 29, 2010 [Page 10]
Internet-Draft Requirements for SRP October 2009
The following figure presents recording from B2BUA configuration
example
+---------+ +--------------+
| | Call Metadata events | Recorder |
| A/S |-------------------------->| (RS) |
| |<-----------------------+ | |
+---------+ | +--------------+
^ SIP| ^
| SIP | |
v v |
+-------------+ +---------+ +-------------+ |
| | | B2BUA | | | |
| UA-B |<--------------->| |<--------------->| UA-C | |
| | SIP+RTP +---------+ RTP | | |
+-------------+ ^ +-------------+ |
| |
| Recording control and media |
+---------------------------------------+
Recording from B2BUA
Figure 2
In some other cases, the recording is performed from an endpoint (RC)
to a recorder (RS). A simple diagram of this is shown below:
Rehor, et al. Expires April 29, 2010 [Page 11]
Internet-Draft Requirements for SRP October 2009
The following figure presents recording from UA
+---------+ +--------------+
SIP | | Call Metadata events | Recorder |
+----------------------->| A/S |-------------------------->| (RS) |
| | |<-----------------------+ | |
| +---------+ | +--------------+
| SIP| ^
| | |
v v |
+-------------+ +-------------+ |
| | | | |
| UA-B |<------------------------------------------->| UA-C | |
| | RTP | | |
+-------------+ +-------------+ |
^ |
Recording control and media | |
+---------+
Recording from UA
Figure 3
In some deployments the RS notifies the RC when to record a session,
which requires the RS to have some means of identifying that a
session is taking place and how to reference the particular session
to record. In other cases, the RC notifies the RS when it wants to
record a session. In both cases, there is often a separate
connection, or even separate protocol, for communicating metadata
about a session, distinct from the protocol connection used for
communicating the recording information.
Rehor, et al. Expires April 29, 2010 [Page 12]
Internet-Draft Requirements for SRP October 2009
The following figure presents recording from UA
+---------+ Recording Control +--------------+
SIP | | Call Metadata events | Recorder |
+----------------------->| A/S |<------------------------->| (RS) |
| | |<-----------------------+ | |
| +---------+ | +--------------+
| SIP| ^
| | |
v v |
+-------------+ +-------------+ |
| | | | |
| UA-B |<------------------------------------------->| UA-C | |
| | RTP | | |
+-------------+ +-------------+ |
^ |
Recorded media | |
+---------+
Recording from UA
Figure 4
6. Requirements
The following are requirements for the Session Recording Protocol:
o REQ-001 The mechanism MUST support full-time Recording Sessions.
o REQ-002 The mechanism MUST support dynamic (on-demand) Recording
Sessions.
o REQ-003 The mechanism MUST support persistent Recording Sessions,
such that the connection and attributes of media in the Recording
Session are not dynamically signaled for each Recorded Session before
it can be recorded. Call details and metadata will still be
signaled, but can be post- correlated to the recorded media. There
will still need to be a means of correlating the recorded media
connection/packets to the Recorded Session, however this may be on a
permanent filter-type basis, such as based on a SIP AoR of an agent
that is always recorded, or based on identifiers in the recorded
media itself.
o REQ-004 The mechanism MUST support establishing Recording Sessions
Rehor, et al. Expires April 29, 2010 [Page 13]
Internet-Draft Requirements for SRP October 2009
from the RC to the RS. This requirement typically applies when the
decision on whether a session should be recorded or not resides in
the RC.
o REQ-005 The mechanism MUST support establishing Recording Sessions
from the RS to the RC. This requirement typically applies when the
decision on whether a session should be recorded or not resides in
the RS.
o REQ-006 The mechanism MUST support the recording of IVR sessions.
o REQ-007 The mechanism SHOULD support RS failover and migration of
Recording Sessions to a working RS without disconnecting the Recorded
Sessions.
o REQ-008 The mechanism MUST support a means of providing security
(confidentiality, integrity and authentication) for the SRP.
o REQ-009 The mechanism MUST support the ability to deliver mixed
media streams to the RS. The RS MAY be informed about the
composition of the mixed streams through session metadata.
Note: A mixed media stream is where several recorded sessions are
carried in a single recording session. A mixed media stream is
typically produced by a mixer function.
o REQ-010 The mechanism MUST support the ability to deliver multiple
media streams for a given Recorded Session over separate Recording
Sessions to the RS.
o REQ-011 The mechanism MUST support the ability to deliver multiple
media streams for a given Recorded Session over a single Recording
Session to the RS.
o REQ-012 The mechanism MUST support the ability to pause and resume
the Recording Session either from RC or from the RS.
o REQ-013 The mechanism MUST support the ability to inject tones into
the Recorded Session either from the RS or from the RC.
o REQ-014 If SIP [RFC3261] is chosen as the Session Recording
Protocol, there MUST be a way for the Recording Session to identify
itself as a SIP session that is established for the purpose of
recording. This will provide a way to disambiguate the Recording
Session from the Recorded Session.
o REQ-015 The mechanism MUST support the ability to provide
authentication, eavesdropping protections, and non-repudiation for
Rehor, et al. Expires April 29, 2010 [Page 14]
Internet-Draft Requirements for SRP October 2009
the media sent in the Recording Session, between the RC and RS.
o REQ-016 The mechanism MUST support the ability to provide
authorization and authentication of the RS to the RC, and the RC to
the RS.
o REQ-017 The mechanism MUST support the ability to provide
eavesdropping protection and non-repudiation for the SRP.
o REQ-018 The mechanism MUST support the ability to correlate the SRP
request to record a call, with the session being recorded.
o REQ-019 The mechanism MUST support the ability to correlate the SRP
request to record specific media sessions, with the SIP session and
media to be recorded.
o REQ-020 The mechanism MUST support the ability to have a separate
session/connection for the Session Recording Protocol, from that for
the Session Metadata transport.
o REQ-021 The mechanism MUST support the ability for the RC to only
perform media replication to the RS, without needing to decode or mix
audio/video/etc., and without needing to be an RTP agent. This will
allow the RC to replicate media at layers below RTP. Clearly, such
an RC mode would not be able to provide transcoding, or media
injection from the RS back into the Recorded Session.
o REQ-021 The mechanism MUST support a means for a SIP UA to request
that a session is not recorded.
o REQ-022 The mechanism MUST provide an indication to a SIP UA that a
session in which it is providing media is being recorded.
o REQ-023 A Recording Session may start at call setup.
o REQ-024 A Recording Session may start during a call.
o REQ-025 The mechanism SHOULD support loss less delivery of media
content from RC to the RS. Note that the specific use of recording
will dictate the integrity of the media. Trading floors or financial
offices may prefer complete loss less delivery of media whereas call
centers, for instance, may tolerate some media loss.
o REQ-026 The mechanism SHOULD support means to avoid clipping media
(leading or trailing samples) when the media is transported from the
RC to the RS.
Note: Media clipping can occur due to delays in recording session
Rehor, et al. Expires April 29, 2010 [Page 15]
Internet-Draft Requirements for SRP October 2009
establishment. RC implementations typically buffer some portion of
the media to overcome this problem.
o REQ-027 Recording Server must reject recording request if service
is unavailable (e.g. system overload, disk full, etc.)
o REQ-028 A request for a new Recording Session must be redirected to
an available recorder server.
o REQ-029 If no recording resources are available, appropriate error
message must be returned.
o REQ-030 Recorder must provide alarm notifications when a failure
occurs
7. Security Considerations
Session recording has substantial security implications, both for the
SIP UA's being recorded, and for the Session Recording Protocol
itself in terms of the RC and RS.
For the SIP UA's involved in the Recorded Session, the requirements
in this draft enable the UA to identify that a session is being
recorded and for the UA to request that a given session is not
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 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, or a visual indicator on
the endpoint.
With regards to security implications of the protocol(s), clearly
there is a need for authentication, authorization, eavesdropping
protection, and non-repudiation for the solution. The RC needs to
know the RS it is communicating with is legitimate, and vice-versa,
even if they are in different domains. Both the signaling and media
for the SRP needs the ability to be authenticated and protected from
eavesdropping and non-repudiation. Requirements for this are
detailed in the requirements section.
8. IANA Considerations
This document has no IANA actions.
Rehor, et al. Expires April 29, 2010 [Page 16]
Internet-Draft Requirements for SRP October 2009
9. Acknowledgements
Thanks to Dan Wing and Alan Johnson for their help with this
document, and to all the members of the DISPATCH WG mailing list for
providing valuable input to this work. Due to time constraints, not
all of their input was included in this version of the document.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804,
May 2000.
[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.
10.2. Informative References
[I-D.wing-sipping-srtp-key]
Wing, D., Audet, F., Fries, S., Tschofenig, H., and A.
Johnston, "Secure Media Recording and Transcoding with the
Session Initiation Protocol",
draft-wing-sipping-srtp-key-04 (work in progress),
October 2008.
Authors' Addresses
Ken Rehor (editor)
Cisco Systems
707 Tasman Dr.
Mail Stop SJC30/2/
Milpitas, CA 95035
USA
Email: krehor@cisco.com
Rehor, et al. Expires April 29, 2010 [Page 17]
Internet-Draft Requirements for SRP October 2009
Rajnish Jain
IPC Systems
777 Commerce Drive
Fairfield, CT 06825
USA
Email: rajnish.jain@ipc.com
Leon Portman
NICE Systems
8 Hapnina
Ra'anana 43017
Israel
Email: leon.portman@nice.com
Vijay Gurbani
Bell Laboratories, Alcatel-Lucent
2000 Lucent Lane
Rm 6G-440
Naperville, IL 60566
USA
Email: vkg@lucent.com
Hadriel Kaplan
Acme Packet
71 Third Ave.
Burlington, MA 01803
USA
Email: hkaplan@acmepacket.com
Andrew Hutton
Siemens Enterprise Communications
KG Hofmannstrasse 51
Munich D-81379
Germany
Email: andrew.hutton@siemens-enterprise.com
Rehor, et al. Expires April 29, 2010 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-24 01:26:28 |