One document matched: draft-ietf-martini-reqs-04.txt
Differences from draft-ietf-martini-reqs-03.txt
MARTINI WG J. Elwell
Internet-Draft Siemens Enterprise Communications
Intended status: Informational H. Kaplan
Expires: October 28, 2010 Acme Packet
April 26, 2010
Requirements for multiple address of record (AOR) reachability
information in the Session Initiation Protocol (SIP)
draft-ietf-martini-reqs-04.txt
Abstract
This document states requirements for a standardized SIP registration
mechanism for multiple addresses of record, the mechanism being
suitable for deployment by SIP service providers on a large scale in
support of small to medium sized PBXs. The requirements are for a
solution that can, as a minimum, support AORs based on E.164 numbers.
This work is being discussed on the martini@ietf.org mailing list.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on October 28, 2010.
Copyright Notice
Copyright (c) 2010 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
Elwell & Kaplan Expires October 28, 2010 [Page 1]
Internet-Draft Multiple AOR reachability in SIP April 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Issues with the REGISTER transaction . . . . . . . . . . . 5
3.1.1. No explicit indicator . . . . . . . . . . . . . . . . 5
3.1.2. REGISTER response growth . . . . . . . . . . . . . . . 6
3.1.3. Illegal wildcarding syntax . . . . . . . . . . . . . . 6
3.2. Issues with routing inbound requests to the SIP-PBX . . . 6
3.2.1. Loss of target information . . . . . . . . . . . . . . 6
3.2.2. Inconsistent placement of target URI information
in inbound requests . . . . . . . . . . . . . . . . . 6
3.2.3. Request-URI mis-routing . . . . . . . . . . . . . . . 7
3.3. Policy-related issues . . . . . . . . . . . . . . . . . . 7
3.3.1. Authorization policy mismatches . . . . . . . . . . . 7
3.3.2. PAI or PPI URI mismatches . . . . . . . . . . . . . . 7
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Desirables . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Non-requirements . . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Elwell & Kaplan Expires October 28, 2010 [Page 2]
Internet-Draft Multiple AOR reachability in SIP April 2010
1. Introduction
The Session Initiation Protocol (SIP) [RFC3261], together with its
extensions, supports multiple means of obtaining the connection
information necessary to deliver out-of-dialog SIP requests to their
intended targets. When a SIP proxy needs to send a request to a
target address of record (AOR) within its domain, it can use a
location service to obtain the registered contact URI(s), together
with any associated path information [RFC3327], and build a route set
to reach each target user agent (UA). The SIP REGISTER method can be
used to register contact URIs and path information. SIP-outbound
[RFC5626] enhances this mechanism to cater for UAs behind Network
Address Translators (NATs) and firewalls. When a entity needs to
send a request to a target for which it is not authoritative, the
entity can follow [RFC3263] procedures for using the Domain Name
System (DNS) to obtain the next-hop connection information.
In practice, many small and medium-sized businesses use a SIP-PBX
that is authoritative for tens or hundreds of SIP AORs. This SIP-PBX
acts as a registrar/proxy for these AORs for clients hosted by the
SIP-PBX. UAs register with the SIP-PBX on behalf of the AORs
concerned. A SIP Service Provider (SSP) provides SIP peering/
trunking capability to the SIP PBX. The SIP-PBX needs to be
reachable from the SSP so that the SSP can handle inbound out-of-
dialog SIP requests targeted at these AORs, routing these requests to
the SIP-PBX for onward delivery to registered UAs.
Experience has shown that existing mechanisms are not always
sufficient to support SIP-PBXs for small/medium businesses. In
particular, RFC 3263 procedures are generally inappropriate, except
for some larger SIP-PBXs. In current deployments, mechanisms for the
dynamic provision of reachability information based on the SIP
REGISTER method are commonly used. However, implementations of this
mechanism vary in detail, leading to interoperability issues between
SIP-PBXs and SSPs, and the need for equipment to support different
variants. A more detailed statement of the problem is given in
section Section 3.
This document states requirements for a standardized SIP registration
mechanism for multiple AORs, the mechanism being suitable for
deployment by SSPs on a large scale in support of small to medium
sized PBXs. The requirements are for a solution that can, as a
minimum, support AORs based on E.164 numbers. The ability to handle
other forms of AOR is outside the scope of this document, although a
solution that can handle other forms of AOR is not precluded if it
does not lead to significant additional complexity or a delay in
producing the standard. AORs based on E.164 numbers represent an
overwhelming proportion of the current market for small/medium SIP-
Elwell & Kaplan Expires October 28, 2010 [Page 3]
Internet-Draft Multiple AOR reachability in SIP April 2010
PBXs, and it is for this sector that an urgent solution is required.
This does not preclude future work on solutions for AORs that are not
based on numbers or are based on non-E.164 numbers (private numbers).
Telephone numbers are conveyed either as TEL URIs or as SIP URIs.
SIP URIs based on E.164 telephone numbers have the property that
the domain part is irrelevant, since the fully qualified E.164
number in the user part is globally unique. This makes it easier
for both the SIP-PBX and the SSP to share responsibility for
routing requests targeted at such a URI: the SSP can perform
contact routing for a request targeted at a URI with the SSP
domain name, and can change the domain name when forwarding the
request to the SIP-PBX; the latter can then perform contact
routing to reach a UA registered with the SIP-PBX. Name-based
SIP-URIs do not have this property, and an SSP would not be able
to change the domain part when forwarding the request with a
target URI having the SSP's domain name, yet would be unable to
perform contact routing on a request with a target URI having the
SIP-PBX's domain name (without some means of acting as a host for
the SIP-PBX's domain name).
Non-E.164-based telephone numbers (e.g., private numbers) can be
conveyed either as TEL URIs or as SIP URIs, and can be made
globally unique by means of the phone-context parameter. In this
case the domain part of a SIP URI might again be irrelevant. The
use of non-E.164-based telephone numbers as AORs is far less
common, and therefore this document does not require that support
be available. However, it is likely that the solution will not
preclude such AORs.
2. Terminology
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].
The terms address of record (AOR), proxy, REGISTER, registrar,
request and user agent (UA) are to be interpreted as described in
[RFC3261].
3. Problem statement
A number of other standards organizations have addressed the issue of
a SIP-PBX registering with its SSP, notably ETSI [ETSI TS 182 025]
and 3GPP [3GPP TS 24.229]. Also various SSPs have produced
proprietary specifications for use with their own offerings. The
Elwell & Kaplan Expires October 28, 2010 [Page 4]
Internet-Draft Multiple AOR reachability in SIP April 2010
reader is encouraged to review the documents produced by those
organizations.
A short summary of the general concept is as follows.
In virtually all models, the SIP-PBX generates a SIP REGISTER request
using a mutually agreed-upon SIP AOR - typically based on the SIP-
PBX's main attendant/reception-desk number. The AOR is almost always
in the domain of the SSP, and both the To and From URIs used for the
REGISTER request identify that AOR. In all respects, it appears on
the wire as a "normal" first-party SIP REGISTER request, as if from a
typical subscriber UA. However, it generally implicitly registers
other AORs associated with the SIP-PBX.
For both 3GPP and ETSI mechanisms, the 200 OK response to the
REGISTER request, sent after a successful authentication challenge,
contains a P-Associated-URI (PAU) [RFC3455] header field listing the
other SIP or TEL URI Identities (i.e., phone numbers) of the SIP-PBX,
which are implicitly Registered AORs. The registered reachability
information from the REGISTER request will be used to reach not only
the single explicitly-registered AOR but also each of the implicitly-
registered AORs. In order to reduce the number of PAU entries, a
"wildcard" syntax model is defined [3GPP TS 23.003], which uses a
regular expression syntax in the user field of the URI to express
multiple AORs in a compressed manner.
For routing requests for any of the explicitly or implicitly
registered AORs from the SSP to the SIP-PBX, the Request-URI is
typically replaced with the registered Contact-URI. In the case of
3GPP and ETSI, the SSP has the option of using loose-routing instead,
and inserting the registered Contact-URI as a loose-route Route
header field value while leaving the Request-URI alone. This
decision is made based upon manually provisioned information in the
registrar's database (i.e., the Home Subscriber Server, HSS).
3.1. Issues with the REGISTER transaction
3.1.1. No explicit indicator
None of the currently available mechanisms indicate that the REGISTER
request or response is any different from a "normal" REGISTER request
or response. This has caused issues when middleboxes between the
SIP-PBX and the registrar serve both SIP-PBXs and normal subscriber
UAs yet need to apply different policies to the two cases.
Furthermore, some middleboxes expect the registrar to follow normal
[RFC3261] procedures of Request-URI replacement with the registered
Contact-URI for routing subsequent requests to the SIP-PBX. If the
Elwell & Kaplan Expires October 28, 2010 [Page 5]
Internet-Draft Multiple AOR reachability in SIP April 2010
registrar adopts a different practice for requests to SIP-PBXs, this
can cause the middlebox to fail to route such requests correctly,
because there is no indication that the registration was any
different.
Lastly, lack of an indication of implicit registration makes
troubleshooting more difficult because the on-the-wire messages are
indistinguishable from "normal" registrations. Note that even the
existence of a PAU header field in the response does not indicate
that implicit registration for a SIP-PBX has occurred, since the PAU
header field is also used for subscriber UAs with multiple
identities.
3.1.2. REGISTER response growth
If an SIP-PBX represents many AORs, the PAU list in the response can
grow the SIP message size beyond the limits for UDP.
3.1.3. Illegal wildcarding syntax
The current syntax for "wildcarded" PAUs is illegal for TEL URIs,
based on the ABNF rules for TEL URIs.
3.2. Issues with routing inbound requests to the SIP-PBX
3.2.1. Loss of target information
If the proxy-registrar follows [RFC3261] for registration resolution
of requests targeted at one of the SIP-PBX's AORs, and thus replaces
the Request-URI with the registered Contact-URI, it is not clear
which AOR is the intended target of the request. The To-URI, for
example, may not contain the intended target AOR if the request was
forwarded/retargeted prior to reaching the proxy-registrar. Some
middleboxes between the registrar and SIP-PBX will overwrite the
Request-URI specifically to try to fix this issue. In some cases, a
P-Called-Party-ID header field [RFC3455] will contain the intended
target AOR; and in some cases the History-Info header field [RFC4244]
will contain it. The SIP-PBX needs to know where to look to find the
required information, and in the case of History-Info needs to
identify the particular element containing the required information.
3.2.2. Inconsistent placement of target URI information in inbound
requests
Even when all information needed by the SIP-PBX is provided, in some
deployments inbound SIP requests from the SSP have the registered
SIP-PBX Contact URI in the Request-URI, whereas in other deployments
inbound SIP requests have the intended target SIP-PBX user (AOR) in
Elwell & Kaplan Expires October 28, 2010 [Page 6]
Internet-Draft Multiple AOR reachability in SIP April 2010
the Request-URI and the Contact URI in the Route header field. There
are other variants too. Interoperability problems arise when a SIP-
PBX designed for or configured for one variant attempts to interwork
with an SSP designed for or configured for another variant.
3.2.3. Request-URI mis-routing
Although many SIP-PBXs support registration with an SSP, they do not
consider themselves authoritative for the explicitly or implicitly
registered AORs if the domain portion still identifies the SSP's
domain. They expect the domain portion to be their own IP Address,
FQDN, or domain. Currently middleboxes have to fix that issue.
3.3. Policy-related issues
The following are largely policy matters for the SSP, but it should
be noted the policies described below will not work in some
situations. A mechanism for solving the SIP-PBX registration problem
will not solve these policy issues directly, although when specifying
the mechanism the opportunity can be taken to highlight the impact of
such policies.
3.3.1. Authorization policy mismatches
Many SSPs perform a first-order level of authorization for requests
from the SIP-PBX by checking the URI in the From, P-Asserted-
Identity (PAI), or P-Preferred-Identity (PPI) [RFC3325] header field
for one matching either an explicitly or implicitly Registered AOR
for the same Contact-URI and/or Layer-3 IP Address. However, some
SIP-PBXs change the Contact-URI they use for non-REGISTER requests to
be different from the one they explicitly Registered. For example
they change the user portion of the Contact-URI, or even the host
portion. This is particularly true for a PBX operating as a proxy
and forwarding the contact URI from the UA behind the SIP-PBX (the
SIP-PBX typically being identified in a Record-Route header field),
rather than acting as a B2BUA and substituting its own Contact URI.
This can cause an SSP to fail to find an AOR corresponding to the
Contact URI for non-REGISTER requests, resulting in the SSP rejecting
such requests or asserting its own PAI value, rather than asserting a
value based on received header fields.
3.3.2. PAI or PPI URI mismatches
Some SSPs expect the PAI or PPI URI in SIP requests received from the
SIP-PBX to match one of the explicitly or implicitly Registered AORs,
whereas some SIP-PBXs generate the URIs using their local IP Address,
hostname, or domain name. Some SSPs expect the PAI or PPI URI in SIP
requests received from the SIP-PBX to be the explicitly registered
Elwell & Kaplan Expires October 28, 2010 [Page 7]
Internet-Draft Multiple AOR reachability in SIP April 2010
AOR only, as it is the main billing number, instead of the implicitly
registered AOR of the calling party. In either case, this can result
in the SSP rejecting requests with values that do not match or
asserting its own PAI value.
Again, these are policy matters for the SSP, but drawbacks should be
noted. For example, rejection of requests can rule out requests from
sources beyond the SIP-PBX (e.g., calls forwarded by the SIP-PBX),
unless the SIP-PBX changes the PAI or PPI URI to a value acceptable
to the SSP (in which case it will no longer identify the calling
user). If the SSP changes the PAI or PPI URI, again the request will
fail to identify the calling user.
4. Requirements
The following are requirements of the mechanism.
REQ1 - The mechanism MUST allow a SIP-PBX to enter into a trunking
arrangement with an SSP whereby the two parties have agreed on a set
of telephone numbers deemed to have been assigned to the SIP-PBX.
REQ2 - The mechanism MUST allow a set of assigned telephone numbers
to comprise E.164 numbers, which can be in contiguous ranges,
discrete, or in any combination of the two.
REQ3 - The mechanism MUST allow a SIP-PBX to register reachability
information with its SSP, in order to enable the SSP to route to the
SIP-PBX inbound requests targeted at assigned telephone numbers.
REQ4 - The mechanism MUST NOT prevent UAs attached to a SIP-PBX
registering with the SIP-PBX on behalf of AORs based on assigned
telephone numbers in order to receive requests targeted at those
telephone numbers, without needing to involve the SSP in the
registration process.
REQ5 - The mechanism MUST allow a SIP-PBX to handle internally
requests originating at its own UAs and targeted at its assigned
telephone numbers, without routing those requests to the SSP.
REQ6 - The mechanism MUST allow a SIP-PBX to receive requests to its
assigned telephone numbers originating outside the SIP-PBX and
arriving via the SSP, so that the PBX can route those requests
onwards to its UAs, as it would for internal requests to those
telephone numbers.
REQ7 - The mechanism MUST provide a means whereby a SIP-PBX knows
which of its assigned telephone numbers an inbound request from its
Elwell & Kaplan Expires October 28, 2010 [Page 8]
Internet-Draft Multiple AOR reachability in SIP April 2010
SSP is targeted at.
REQ8 - The mechanism MUST provide a means of avoiding problems due to
one side using the mechanism and the other side not.
In other words, the mechanism is required to avoid the situation
where one side believes it is using the mechanism and the other
side believes it is not, e.g., the SIP-PBX believes it is
performing registration of multiple telephone numbers, but the SSP
believes a single AOR is being registered.
REQ9 - The mechanism MUST observe SIP backwards compatibility
principles.
In other words, the mechanism is required to provide a graceful
means of recovery or fall-back if either side does not support the
mechanism. For example, this might involve the use of an option
tag.
REQ10 - The mechanism MUST work in the presence of a sequence of
intermediate SIP entities on the SIP-PBX-to-SSP interface (i.e.,
between the SIP-PBX and the SSP's domain proxy), where those
intermediate SIP entities indicated during registration a need to be
on the path of inbound requests to the SIP-PBX.
These intermediate SIP entities can be edge proxies, session
border controllers, etc..
REQ11 - The mechanism MUST work when a SIP-PBX obtains its IP address
dynamically.
REQ12 - The mechanism MUST work without requiring the SIP-PBX to have
a domain name or the ability to publish its domain name in the DNS.
REQ13 - For a given SIP-PBX and its SSP, there MUST be no impact on
other domains, which are expected to be able to use normal RFC 3263
procedures to route requests, including requests needing to be routed
via the SSP in order to reach the SIP-PBX.
REQ14 - The mechanism MUST be able to operate over a transport that
provides integrity protection and confidentiality.
REQ15 - The mechanism MUST support authentication of the SIP-PBX by
the SSP and vice versa.
REQ16 - The mechanism MUST allow the SIP-PBX to provide its UAs with
public or temporary Globally Routable UA URIs (GRUUs) [RFC5627].
Elwell & Kaplan Expires October 28, 2010 [Page 9]
Internet-Draft Multiple AOR reachability in SIP April 2010
REQ17 - The mechanism MUST work over any existing transport specified
for SIP, including UDP.
REQ19 - Documentation MUST give guidance or warnings about how
authorization policies may be affected by the mechanism, to address
the problems described in Section 3.3.
5. Desirables
The following are desirable properties of the mechanism.
In addition to the desirables below, the general aim is to require
only relatively modest changes to a substantial population of
existing SSP and SIP-PBX implementations, in order to encourage a
fast market adoption of the standardized mechanism. Ease of market
adoption is paramount here. Many SIP-PBXs and SSPs have implemented
mechanisms based on the REGISTER method, and the need for substantial
changes to those implementations will discourage convergence on a
single standard in the foreseeable future.
DES1 - The mechanism SHOULD allow an SSP to exploit its mechanisms
for providing SIP service to ordinary subscribers in order to provide
a SIP trunking service to SIP-PBXs.
DES2 - The mechanism SHOULD scale to SIP-PBXs of several thousand
assigned telephone numbers.
This will probably preclude any mechanism involving a separate
REGISTER transaction per assigned telephone number.
In practice, the mechanism is more likely to be used on PBXs with
up to a few hundred telephone numbers, but it is impossible to
give a precise limit, and hence the desire to be able to support
several thousand.
DES3 - The mechanism SHOULD scale to support several thousand SIP-
PBXs on a single SSP.
6. Non-requirements
The means by which a third domain can route a request to the SSP for
onward delivery to the SIP-PBX is outside the scope of this work.
This is related to REQ13, which requires normal routing based on RFC
3263 to be used.
Provisioning is outside the scope of this work. In particular, a SSP
Elwell & Kaplan Expires October 28, 2010 [Page 10]
Internet-Draft Multiple AOR reachability in SIP April 2010
will need to assign a set of numbers to a SIP-PBX, and a SIP-PBX will
need to be aware of the set of assigned numbers and allocate those
numbers to its users. Automated means for a SIP-PBX to obtain, from
its SSP, the set of assigned telephone numbers is considered to be a
provisioning topic.
7. IANA considerations
This document requires no IANA actions.
8. Security considerations
Security of signaling between the SIP-PBX and the SSP is important.
Some of the requirements above already address this.
In particular, it is important that an entity acting as a SIP-PBX
cannot register with an SSP and receive inbound requests to which it
is not entitled. The SSP is assumed to have procedures for ensuring
that a SIP-PBX is entitled to use a set of E.164 telephone numbers
prior to entering into agreement with that SIP-PBX for using those
telephone numbers with this mechanism. Furthermore, by
authenticating the SIP-PBX when it provides reachability information,
the SSP can be sure that it delivers inbound requests only to the
correct destination.
9. Acknowledgements
The contents of the document have been compiled from extensive
discussions within the MARTINI WG, the individuals concerned being
too numerous to mention.
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.
[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.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Elwell & Kaplan Expires October 28, 2010 [Page 11]
Internet-Draft Multiple AOR reachability in SIP April 2010
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
10.2. Informative References
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
(SIP) Extension Header Field for Registering Non-Adjacent
Contacts", RFC 3327, December 2002.
[RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private
Header (P-Header) Extensions to the Session Initiation
Protocol (SIP) for the 3rd-Generation Partnership Project
(3GPP)", RFC 3455, January 2003.
[RFC4244] Barnes, M., "An Extension to the Session Initiation
Protocol (SIP) for Request History Information", RFC 4244,
November 2005.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009.
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent URIs (GRUUs) in the Session Initiation Protocol
(SIP)", RFC 5627, October 2009.
[3GPP TS 23.003]
"3GPP TS 23.003 "3rd Generation Partnership Project;
Technical Specification Group Core Network and Terminals;
Numbering, addressing and identification"".
[3GPP TS 24.229]
"3GPP TS 24.229 "3rd Generation Partnership Project;
Technical Specification Group Core Network and Terminals;
IP multimedia call control protocol based on Session
Initiation Protocol (SIP) and Session Description Protocol
(SDP); Stage 3"".
[ETSI TS 182 025]
"ETSI TS 182 025 "Telecommunications and Internet
converged Services and Protocols for Advanced Networking
(TISPAN); Business trunking; Architecture and functional
description"".
Elwell & Kaplan Expires October 28, 2010 [Page 12]
Internet-Draft Multiple AOR reachability in SIP April 2010
Authors' Addresses
John Elwell
Siemens Enterprise Communications
Phone: +44 1908 855608
Email: john.elwell@siemens-enterprise.com
Hadriel Kaplan
Acme Packet
71 Third Ave.
Burlington, MA 01803
USA
Email: hkaplan@acmepacket.com
Elwell & Kaplan Expires October 28, 2010 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 05:30:50 |