Drinks Working Group K. Cartwright
Internet-Draft VeriSign
Intended status: Standards Track S. Dimig
Expires: January 15, 2009 Tekelec
M. Teodoro
NeuStar
J-F. Mule
CableLabs
July 14, 2008
A Provisioning Protocol for ENUM-SIP Addressing Servers
draft-mule-peppermint-espp-protocol-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on January 15, 2009.
Cartwright, et al. Expires January 15, 2009 [Page 1]
Internet-Draft ESPP Protocol July 2008
Abstract
This document defines a provisioning protocol for ENUM-SIP addressing
servers.
An ENUM-SIP addressing server is a host that acts as Lookup Function
in session peering to determine the target domain of a given SIP
request and it may also act as a Location Routing Function to develop
the location of the SIP signaling entity in that target domain.
This protocol allows SIP service providers to provision and manage
session establishment data used by SIP network elements to route SIP
sessions to the target destinations which may be served by the SIP
service provider's own internal network or by a session peering
partner. The data provisioned into an ENUM-SIP addressing server is
queried by SIP entities using ENUM or SIP.
This version of the protocol integrates comments received on the IETF
peppermint and drinks mailing lists before July 2008. This document
is an Internet-Draft and the protocol it describes is subject to
technical changes that may make this version incompatible with future
versions defined in Internet-Drafts. It is expected that the authors
will continue to update this protocol based on the drinks working
group requirements on the session establishment data.
Cartwright, et al. Expires January 15, 2009 [Page 2]
Internet-Draft ESPP Protocol July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 11
4.1. Logical Structure - Data Model . . . . . . . . . . . . . 11
4.2. Technical Structure - SOAP/XML Type Hierarchy . . . . . . 15
4.3. Overview of Protocol Operations . . . . . . . . . . . . . 16
4.3.1. Deployment Scenario and ESPP Provisioning . . . . . . 17
4.3.2. Deployment Scenario and Resolution . . . . . . . . . 33
4.3.3. Generic Examples . . . . . . . . . . . . . . . . . . 35
4.4. Protocol Specification . . . . . . . . . . . . . . . . . 35
4.4.1. General Protocol Concepts . . . . . . . . . . . . . . 36
4.4.2. Protocol Operation Descriptions . . . . . . . . . . . 43
5. File-based ESPP provisioning protocol . . . . . . . . . . . . 86
5.1. Overview of the File-based Provisioning Operations . . . 86
5.2. File Structure . . . . . . . . . . . . . . . . . . . . . 86
6. Response Codes and Messages . . . . . . . . . . . . . . . . . 89
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 91
8. Formal API Definition . . . . . . . . . . . . . . . . . . . . 92
8.1. WSDL Specification . . . . . . . . . . . . . . . . . . . 92
8.2. XSD Types Specification . . . . . . . . . . . . . . . . . 103
9. Security Considerations . . . . . . . . . . . . . . . . . . . 116
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 117
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 118
11.1. Normative References . . . . . . . . . . . . . . . . . . 118
11.2. Informative References . . . . . . . . . . . . . . . . . 118
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 120
Intellectual Property and Copyright Statements . . . . . . . . . 121
Cartwright, et al. Expires January 15, 2009 [Page 3]
Internet-Draft ESPP Protocol July 2008
1. Introduction
This document defines a provisioning protocol for ENUM-SIP addressing
servers. It allows SIP service providers to provision data related
their SIP route management. The data is used by ENUM-SIP addressing
servers to return part of the session establishment data to SIP
network elements so that they can route SIP sessions to the proper
target destinations.
An ENUM-SIP addressing server is a session routing server that
implements a Lookup Function and may also implement a Location
Routing Function as defined in [I-D.ietf-speermint-terminology]. An
ENUM-SIP addressing server typically takes a user address that can be
used to establish a SIP session as the input to the lookup query (SIP
address of record, a telephone number or any type of public user
addresses). It resolves the address into one or more Uniform
Resource Identifiers (URIs) based on various rules and routing logic.
Optionally, it may also develop the responses to include information
on how to route the SIP session to the requesting entity.
The data provisioned into an ENUM-SIP addressing server is queried by
SIP entities using protocols such as ENUM [RFC3761] or Session
Establishment Protocol (SIP) [RFC3261]. While the protocols used to
query the provisioned data may impose limitations on the data
modeling, they are considered out of scope of this document.
The use cases and protocol requirements for the ENUM-SIP Server
Provisioning Protocol (ESPP) are described in
[I-D.espp-requirements]. For reference, the original version of this
protocol is published as a CableLabs specification, the PacketCable
ENUM Server Provisioning Specification ([CableLabs-ESPP]). A number
of vendors have client and server implementations of this original
protocol and three interoperability testing events have been
conducted to date.
This document is organized as follows:
o Section 3 describes the protocol's functional entities and
provides a pointer to the use cases and protocol requirements
maintained in a separate document,
o Section 4 and Section 5 define the real-time and filed-based
operations of the ESPP provisioning protocol including the data
model (Section 4.1), the SOAP/XML Type Hierarchy (Section 4.2),
and an overview of the protocol operations by walking through a
real-life deployment scenario showing examples of ESPP
operations and how the provisioned data can be used to resolve
ENUM or SIP queries,(Section 4.3),
Cartwright, et al. Expires January 15, 2009 [Page 4]
Internet-Draft ESPP Protocol July 2008
o Section 8 provides the complete normative WSDL and XSD
definitions of the protocol.
Cartwright, et al. Expires January 15, 2009 [Page 5]
Internet-Draft ESPP Protocol July 2008
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].
This document also reuses the SIP terminology defined in [RFC3261].
The Lookup Function (LUF), Location Routing Functions (LRF) and other
session peering terms are defined [I-D.ietf-speermint-terminology].
Cartwright, et al. Expires January 15, 2009 [Page 6]
Internet-Draft ESPP Protocol July 2008
3. Protocol Requirements
The ENUM Server Provisioning Protocol (ESPP) allows a SIP Service
Provider (SSP) to receive session establishment-related data from
various sources: its internal back-office systems for intra-domain
routes, a session peer or a federation registry. A source of
provisioning data is logically represented by an ESPP provisioning
client (ESPP Client). The SIP Service Provider's addressing server
receives this provisioning data via a functional entity called an
ESPP Server. This data is then used by the server's Lookup and
Location routing Functions to return session establishment data to
querying entities.
The data sent by an ESPP Client to an ESPP Server follows a formal
data structure based on the data model defined in Section 4.1. The
data elements include parameters such as a peer's target addresses
grouped by destination groups and the Signaling path Border Elements
to reach those telephone numbers.
This specification defines the protocol interfaces between a
provisioning client (ESPP Client) and a provisioning server function
of an ENUM-SIP addressing server (ESPP Server), as shown on Figure 1.
Cartwright, et al. Expires January 15, 2009 [Page 7]
Internet-Draft ESPP Protocol July 2008
SIP SSP +-------------+
Intra-Domain | |
Network | Back Office |
| | Server |
+-------|+-----------+|-+
||ESPP Client|| |
|+-----------+| |
+-------------+ |
| +-------------+
Peer +-------------+ | | ENUM-SIP |
Bi-lateral | | | | Addressing |
Agreement | Resolution | | | Server |
| | Server | | | |
+-------|+-----------+| | ESPP |+-----------+|
||ESPP Client|+-+------+|ESPP Server||
|+-----------+| | |+-----------+|
+-------------+ | |+-----------+|
| || Data ||
Peer +-------------+ | ||Repository ||
Federation | Other Data | | |+-----------+|
Network | Sources | | |+-----------+| * +-----------+
| |+-----------+|-+ || LUF - LRF ||+----+ SIP Entity|
+-------||ESPP Client|| |+-----------+| +-----------+
|+-----------+| |+-----------+|
+-------------+ || ENUM - SIP||
|+-----------+|
+-------------+
ENUM Server Provisioning Protocol Reference Architecture
Figure 1
To claim compliance with this specification, an ESPP Client and an
ESPP Server MUST conform to the real-time and file-based provisioning
protocol requirements defined in Section 4, Section 5 and Section 8
of this document. The protocols used by SIP entities and various
network elements to query the addressing server are typically ENUM or
SIP; they are out of scope of this specification and are denoted with
an asterisk (*) in Figure 1.
The guiding design principal behind ESPP is the ability to support a
large session addressing space whose size is of the same order of
magnitude as the Public Switched Telephone Network (PSTN).
Optimizing bandwidth and storage usage is a key characteristic.
The logical data structure implemented by ESPP allows for a more
natural modeling of relationships between the entities that comprise
Cartwright, et al. Expires January 15, 2009 [Page 8]
Internet-Draft ESPP Protocol July 2008
the logical topology. Telephone numbers and other types of public
user identities are grouped in logical or geographical areas and
associated with routes that describe how traffic traverses the nodes
of the topology. The process begins by arranging a plurality of
telephone numbers and nodes connected by a plurality of routes. Each
telephone number, number range or public user identity is assigned to
a destination group. Through a route assignment each node is
associated with one or more destination groups. For example, a SIP
Service Provider could first create destination groups for the New
York metropolitan area, assigning the telephone numbers of New York
subscribers into that destination group. The SIP Service Provider
then defines the call servers that provide digital voice services for
New Yorkers and the border elements that connect the New York
metropolitan area to peering networks. Finally, through the
definition of intra-SSP and inter-SSP routes, that SIP Service
Provider completes the establishment of session peering data by
associating nodes with destination groups.
Cartwright, et al. Expires January 15, 2009 [Page 9]
Internet-Draft ESPP Protocol July 2008
Figure 2 illustrates the link between logical destination groups and
telephone numbers and the associated routes.
Destination Groups:
+----------------------------------------+
|Destination Group Name| TN or TN Ranges |
+----------------------+-----------------+
|Manhattan |212-203-0000 -> |
| |212-203-9999 | ,--.
|Bronx |347-876-1000 -> | / \
| |347-876-1999 | / \
|Queens |347-354-6000 -> | ( Bronx )
| |347-354-6999 | \ /
+----------------------------------------+ ,-----. \ /
Routes: / \ `-'
+------------------------------------+ / \
|Route Name|Nodes |Dest. Groups | (Manhattan) ,.
+----------+---------+---------------+ ,-. / / \
|118th Ave |NYC-SBE-1|Manhattan/Bronx|-->(SBE) / / \
|60 Hudson |NYC-SBE-2|Queens |-+ `-'--------' (Queens)
+----------+--------++---------------+ | ,+. /
+-------------->(SBE) /
Nodes: `-''-
+-------------------------------+
|Node Name| Host/Domain Name |
+---------+---------------------+
|NYC-SBE-1|sbe-1.nyc.example.com|
|NYC-SBE-2|sbe-2.nyc.example.com|
+---------+---------------------+
Example of ESPP Destination Groups and Routes
Figure 2
A number of design considerations and requirements (transport, data
model, security, etc.) can be found in [I-D.espp-requirements].
Cartwright, et al. Expires January 15, 2009 [Page 10]
Internet-Draft ESPP Protocol July 2008
4. Protocol Definition
This section first introduces the structure of the data model and the
overall technical structure that provide the information framework to
which ESPP adheres. An overview of the protocol operations is then
provided with a typical deployment scenario. This section concludes
with the definition of the operations and data elements that comprise
ESPP.
4.1. Logical Structure - Data Model
The data model illustrated and described in Figure 3 defines the
logical objects and the relationships between these objects that the
ESPP protocol supports. ESPP defines the protocol operations through
which an ESPP Client populates an ENUM-SIP addressing server with
these logical objects. Various clients may use the protocol for
populating the server's data. ESPP Clients may include, for example,
a back-office system, a federation registry or another ENUM-SIP
addressing server.
A key requirement of ESPP is the ability to support an addressing
space of the same magnitude as the PSTN. To achieve the above, the
data model needs to be designed such that it optimizes bandwidth and
storage. The data model needs to support distribution of addressing
information in a manner that affords the implementations the
opportunity to maximize storage and minimize transport overhead. One
way to achieve this is not relying exclusively on distribution of
redundant NAPTR records. The use of a direct association between
NAPTRs and telephone numbers should be restricted to service
scenarios where there is a need to communicate subscriber-specific
service attributes. This is because the NAPTRs carry a large amount
of redundant data when many telephone numbers resolve into a URI
where the host part is the same Internet address.
As illustrated in the figure below, the logical structure that
underlies ESPP is designed around a simplified version of the logical
entities that comprise session peering data. This logical structure
provides a consistent terminology and design to the constructs that
make up the protocol.
Cartwright, et al. Expires January 15, 2009 [Page 11]
Internet-Draft ESPP Protocol July 2008
+----------------+
A Route is associated with |NAPTR: |
+----------------+ zero or more SBE NAPTRs. |id,enterpriseId,|
| |--------------------------->|order,pref, |
|Route: | NAPTRs associated with |flags,svcs,regx,|
|id,enterpriseId,| Routes are not User or TN |repl,extension |
|routeName, | specific. The user portion +----------------+
|isLnService, | of the regex will be "\\1".
|sbeNAPTRs, | +----------------+
|extension | |Egress Route: |
| |<---------------------------|id,enterpriseId,|
+----------------+ An EgressRoute is |routeIds,pref, |
^ associated with zero or |svcs, |
A Destination | more Routes. |regxRewriteRule,|
Group is | |extension |
associated | +----------------+
with 1 or more |
Routes |
+----------------+
|Destination |
|Group: |
|id,enterpriseId,|
+--->|DestGroupName, |<---+
| |routeIds, | |
| |extension | |
| +----------------+ |
|An RN is |A TNRange is |A Public
|associated |associated |Identify is
|with only 1 |with only 1 |associated
|Destination |Destination |with zero or
|Group. |Group. |1 Destination Group.
| | |
+--------------++--------------++--------------+ +--------------+
|RN: ||TNRange: ||Public | |NAPTR: |
|id, ||id, ||Identity: | |id, |
|enterpriseId, ||enterpriseId, ||id, | |enterpriseId, |
|rn, ||tnRangeStart, ||enterpriseId, |-->|order,pref, |
|destGroupId, ||tnRangeEnd, ||pubIdentity, | |flags,svcs, |
|extension ||destGroupId, ||priIdentity, | |regx,repl, |
| ||extension ||destGroupId, | |extension |
| || ||extension | | |
+--------------++--------------++--------------+ +--------------+
|
A Public Identity | Multiple Public
is associated with | Identities can
zero or 1 Private | be associated
Identity | with 1 Private
| Identity
Cartwright, et al. Expires January 15, 2009 [Page 12]
Internet-Draft ESPP Protocol July 2008
|
|
|
|
|
V
+----------------+
|Private |
|Identity: |
|id, |
|enterpriseId, |
|privateIdentity,|
|extension |
+----------------+
Logical Structure of ESPP Objects
Figure 3
The objects that comprise the logical domain model can be described
as follows:
Public Identity (PubId):
A string of numbers or characters that serves as a public
identity. A Public Identity may be a telephone number, an email
address, or other identity as deemed appropriate. The Public
Identity object may be associated with a Destination Group which
serves as a logical grouping of public identities and indirectly
defines the signaling path used to Route to that Public Identity.
A Public Identity may optionally be associated with zero or more
individual NAPTRs. This ability for a Public Identity to be
directly associated with a set of NAPTRs, as opposed to being
associated with a Destination Group, supports the use cases where
the NAPTR may contain data specifically tailored to an individual
Public Identity. A Public Identity may, optionally, be associated
with zero or one Private Identity.
Private Identity (PvtId):
A string of numbers or characters that serves to associate, or
group together, a set of related Public Identities. A Private
Identity may, for example, represent a user who has more than one
Public Identity instances. When a resolution request for a public
identity arrives at an addressing server, the addressing server
may locate the Public Identity that matches the queried public
identity, discover the Private Identity associated with that
Public Identity, and then gather and return all the NAPTRs
directly or indirectly (via a Destination Group) associated with
the Public Identities that are associated with that Private
Cartwright, et al. Expires January 15, 2009 [Page 13]
Internet-Draft ESPP Protocol July 2008
Identity.
Route:
A set of related Signaling path Border Elements (SBEs). SBEs are
generally ingress or egress points within, or at the edge of, a
SIP service provider's network. A Route object is associated with
zero or more SBEs. An SBE's properties are housed within the
constructs of a NAPTR object modeled after a DNS NAPTR Record. At
runtime (i.e., during the resolution of a SIP or ENUM query to an
addressing server), the SBEs associated with the route to the
Destination Group of a public identity will be returned as part of
the NAPTR response. In case of multiple SBEs, the ENUM response
will have multiple NAPTR records, each referring to a particular
SBE. This indirection between a Public Identity and its ENUM
NAPTRs allows the modification of signaling path border elements
without having to modify a large number of NAPTRs.
Egress Route:
Optional rules for re-writing (modifying) the regular expressions
housed in the NAPTRs associated with a Route. This is primarily
used by the addressing server to dynamically add a SIP Route
header as part of a SIP resolution, and to dynamically indicate
into a NAPTR's regular expression what SIP Route to use. This
allows a NAPTR to define the local egress SBE or the remote
ingress SBE of a signaling path.
Destination Group:
A collection of zero or more Public Identities, Telephone Number
ranges (TNRanges), and Routing Numbers (RNs) that are related by
virtue of their common signaling path and a set of zero or more
Route relationships. The grouping of Public Identities, TNRanges,
and RNs into related groups and the indirect association of these
groups to their signaling path elements significantly enhances the
manageability of routing data for a large number of Public
Identities. This allows the addressing server to apply routing
changes to a set of Public Identities, TNRanges, and RNs without
having to make changes to each individual Public Identities,
TNRange, or RN.
Routing Number (RN):
A routing number prefixed for a routing purpose (as defined in the
ITU-T Recommendation e.164). The length of a routing number may
vary from country to country. The RN is sometimes called a prefix
as it can symbolize a global telephone number prefix. The RN can
indeed represent the first digits of a number block handled by an
SSP to which the session should be routed. In some countries, the
RN value contains one or more digits not used as first digits in
the national numbering plan to indicate a ported number (e.g. in
Cartwright, et al. Expires January 15, 2009 [Page 14]
Internet-Draft ESPP Protocol July 2008
North American where the RN is used for Local Number Portability).
In the rest of this document, we use the RN as a synonym of
prefix. An RN is associated with a Destination Group.
TNRange:
An object that represents a range of telephone numbers. The
TNRange object must be associated with a Destination Group which
indirectly defines the signaling path to reach the TNs in that
range.
Enterprise ID:
The enterprise ID data element that resides within each object
type and uniquely identifies an operational entity within an ESPP
Server. The operational entity is responsible for, or owns, that
object from a business perspective. This does not identify the
software entity that provisioned the object, which is the purpose
of the client ID. Refer to Section 4.4.1.7 for more details.
ID:
Each object is uniquely identifiable using its object ID. An
object ID is guaranteed to be unique within an ESPP Server and
ESPP Client, regardless of the number of ESPP Clients populating
objects into a given ESPP Server. Refer to Section 4.4.1.7 for
more details.
NAPTR:
The data structure used to house the properties of signaling path
border elements, and any other information appropriately held
within the data structures offered by a NAPTR.
4.2. Technical Structure - SOAP/XML Type Hierarchy
In addition to employing the logical structure described in the
previous section, ESPP also employs a consistent overall technical
structure. This technical structure is typically referred to as the
"Document Literal Wrapped" style of designing SOAP based APIs. This
style is generally regarded as an optimal approach that enhances
maintainability, comprehension, portability, and, to a certain
extent, performance. Figure 4 illustrates this high level technical
structure.
Cartwright, et al. Expires January 15, 2009 [Page 15]
Internet-Draft ESPP Protocol July 2008
+-----------+
+------| SOAP |------+
| | Operation | |
Contains | +-----------+ | Contains
| |
V V
+------------+ +-------------+
|SOAP Request| |SOAP Response|
Example:| Message | | Message |Example:
addRtesRqstMsg| (Operation | | (Operation |cmnRspnsMsg
| Input) | | Output) |
+------------+ +-------------+
| |
Contains | | Contains
| |
V V
+--------------+ +---------------+
Example:| Wrapped | | Wrapped |Example:
addRtesRqst|Request Object| |Response Object|cmnRspns
+--------------+ +---------------+
| |
| |
| |
V V
+--------------+ +---------------+
Example:| ESPP | | ESPP |Example:
RteType| Object Types | | Object Types |BasicRspnsType
+--------------+ +---------------+
Technical Structure of the ESPP Protocol
Figure 4
The SOAP operations supported by ESPP (e.g., addRtes) are normatively
defined in Section 8. Each SOAP operation defines a request/input
message and a response/output message. Each request and response
message then contains a single object that wraps the data elements
that comprise the inputs and the outputs, respectively, of the
operation.
Section 4.4.2 of this document defines how each operation utilizes
this technical structure and the logical structure defined in the
previous section.
4.3. Overview of Protocol Operations
This section provides an overview of ESPP and its protocol operations
by describing a usage scenario and examples. It is divided into two
Cartwright, et al. Expires January 15, 2009 [Page 16]
Internet-Draft ESPP Protocol July 2008
sub-sections. The first sub-section defines a usage scenario and
provides a set of example ESPP request messages that apply to the
scenario. The second sub-section provides examples of a generic set
of ESPP request/response pairs, one for each protocol operation.
4.3.1. Deployment Scenario and ESPP Provisioning
A typical deployment scenario for ESPP involves multiple SIP Service
Providers wanting to exchange multimedia traffic including Voice over
IP (VoIP) calls and Instant Messaging (IM) sessions. Each service
provider first advertises the public user identities (e.g., telephone
numbers and instant messaging addresses) it serves on its network
along with the routes to its peers. Note that the process by which a
SIP service provider exchanges data such as an instant messaging
address may be subject to end-user privacy and a subscriber-triggered
authorization step may be required.
Various models can be chosen by SSPs to determine if a target address
is served by a peer. In one model, for each session initiation, an
out-of-network query could be made to each peer individually, or to a
federation entity representing the peers. In another model, an SSP
who has deployed ENUM-SIP addressing servers for session routing may
prefer in-network queries to its addressing servers to resolve target
addresses. In this second case, the service provider's addressing
server could be provisioned with peer data: this is the purpose of
the ESPP protocol. Both models can also co-exist: in some cases and
depending on the SSP policy, the resolution of certain types of
addresses may require an out-of-network query.
The remaining of this section assumes that SSPs have deployed ENUM-
SIP addressing servers and prefer in-network queries. A deployment
scenario is described in details covering both the provisioning
activities using ESPP and the query resolutions to resolve target
addresses using ENUM or SIP. We first introduce the actors of the
scenario (SIP Service Providers or enterprises participating in
multimedia session exchanges), and then expand on the ESPP operations
for the provisioning of peers, Session Establishment Data (SED), and
the public identities or Address of Records to which session may be
established.
4.3.1.1. Actors
4.3.1.1.1. Enterprises Description
Three SIP service Providers have agreed to exchange Voice over IP
traffic and Instant Messages via their IP networks:
Cartwright, et al. Expires January 15, 2009 [Page 17]
Internet-Draft ESPP Protocol July 2008
o GlobalSSP:
GlobalSSP is a large SIP service provider with service footprints in
Boston and Arizona and several SIP servers capable of processing VoIP
traffic. The SIP servers are logically linked to several Signaling
path Border Elements (SBEs) that hide the topology of the SIP service
provider's network while providing specific access points for other
peers. GlobalSSP does also control its egress routes by choosing the
SBE that egress calls to a particular peer.
Each Call Management Server (CMS) is also associated with one or more
Routing Number(s) (RN) due to local number portability support. The
telephone numbers served by GlobalSSP are distributed among the CMS
servers as well as the PSTN switches.
o MidwestSSP:
MidwestSSP operates a network similar to GlobalSSP with services in
the Chicago area (subscriber base only located in one state). Two
Call Management Servers and only one SBE are deployed.
o NewYorkSSP:
NewYorkSSP offers services in the region of New York City including
voice and IM. Four SBEs have been deployed for voice, one SBE for
IM. IM subscribers are known by a public identity.
SIP service providers take advantage of ESPP to provision session
establishment data. They agreed to use a common Registry function
with a Registrar component that implements the client-side of the
ESPP protocol. Note that ESPP also supports a deployment model where
each SIP service provider has bilateral relationships with a number
of peers and use ESPP directly with each peer.
Each SIP service provider is connected to the Registrar and
implements an instance of the ENUM SIP addressing server (ESPP
Server) for the server-side of the protocol. Note that GlobalSSP is
connected to the Registrar from one of their Destination Group that
distributes data to the Boston Destination Group.
Each SIP service provider is allocated an identifier or Enterprise
ID:
Cartwright, et al. Expires January 15, 2009 [Page 18]
Internet-Draft ESPP Protocol July 2008
+---------------+---------------------------+
| SSP | Enterprise ID |
+---------------+---------------------------+
| GlobalSSP | 76543 |
| | |
| NewYorkSSP | 76544 |
| | |
| MidwestSSP | 76545 |
+---------------+---------------------------+
Table 1: Example SSP and Enterprise ID
After these three SSPs have successfully exchanged session
establishment data (SED) for some time, a new SSP called NewSSP wants
to exchange calls and IM with the other three. To facilitate the
process of getting the data from all three SIP service providers in a
limited amount of time, the NewSSP server will receive a complete
copy of the data the SSPs wish to share with NewSSP using a bulk
file.
+---------------+---------------------------+
| SSP | Enterprise ID |
+---------------+---------------------------+
| NewSSP | 76546 |
+---------------+---------------------------+
Table 2: Example NewSSP and Enterprise ID
In this scenario, each SIP Service Provider operates an ESPP Server
that houses the ESPP Server's SED and end point data from an ESPP
Client (a Registrar or a Registry). The ESPP Client initiates
connections and, using the supported ESPP operations, pushes data
down to the ESPP Servers. SED and end point objects are stored in
the ESPP Server.
Each ESPP Server receives the data its SSP is allowed to access and
each addressing server has a "unique" view of its peer's data. Note
that a SIP Service Provider may also choose to store internal or
private routes using ESPP. For example, the data for routing
sessions out of the SSP's network is different from the data used to
route sessions within the SSP's own Destination Groups.
4.3.1.1.2. Enterprises: ESPP Provisioning Operations
As these partner relationships are established, each SSP sends SED
data to its peers via the ESPP Client(s). In order to identify the
peer the SED data belong to, an Enterprise ID is provided along with
the list of Destination Groups, SBEs, etc.
Cartwright, et al. Expires January 15, 2009 [Page 19]
Internet-Draft ESPP Protocol July 2008
ESPP is an XML SOAP protocol. An ESPP Client uses the ESPP
protocol's addEntr operation to create these enterprises in the ESPP
Server for each participating SSP. To do so, it sends a request to
create three enterprise identifiers (eId) at an ESPP Server. This
operation is sent to the ESPP Server operated by the three SIP
Service Providers, MidwestSSP, GlobalSSP, and NewYorkSSP.
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope [snip] >
<SOAP-ENV:Body>
<addEntrRqst>
<basicRqst>
<clientId>7845601</transId>
<transId>1000000</transId>
<minorVer>1</minorVer>
</basicRqst>
<eId>76543</eId>
<eId>76544</eId>
<eId>76545</eId>
</addEntrRqst>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figure 5
For brevity and to improve the readability of examples, the basicRqst
element of the SOAP message will be omitted from the remaining
examples. With the exception of the transId element incrementing
upward, the content of the basicRqst element is identical for all
examples in this section.
The enterprise ID for NewSSP is added later. At that time, the
central registry via its ESPP Client uses the addEntr operation to
add the NewSSP's enterprise ID to the ESPP Servers of the peers
NewSSP wishes to exchange traffic with.
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope [snip] >
<SOAP-ENV:Body>
<addEntrRqst>
<basicRqst> [snip] </basicRqst>
<eId>76546</eId>
</addEntrRqst>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Cartwright, et al. Expires January 15, 2009 [Page 20]
Internet-Draft ESPP Protocol July 2008
Figure 6
The addEntr operation is an infrequent occurrence; it is used when
new enterprises agree to exchange traffic.
4.3.1.2. Session Establishment Data
4.3.1.2.1. Description of Session Establishment Data
As part of establishing their traffic exchange policies, each SSP
defines its points of session interconnect for their destination
groups, which may or may not vary for each peering partner. This
information is part of the data required to establish a session and
is called session establishment data (SED). As described in the
introductory sections of this document, SED in ESPP includes Routes,
SBEs, and Destination Groups. SED is usually provisioned once for
each SIP Service Provider with occasional subsequent updates as
interconnect points are added or changed. It is provisioned
independently from the provisioning of the elements contained in
Destination Groups (TNs, TN Ranges, RNs, and IM IDs). This allows
the rare process of provisioning SED to be distinctly separate from
the continuous process of adding subscribers. The destination groups
supported by each SIP Service Provider are illustrated in Figure 7
below.
+----------------+ +----------------+
| Chicago |_________________| Boston |
|Dest. Group (1)| |Dest. Group (3) |
+----------------+_ +----------------+
| `-. .-' |
| `. .-' |
| `-..' |
| .-'`-. |
| .-' `. |
+----------------+.-' `-.+----------------+
| Flagstaff |_________________| New York |
|Dest. Group (2) | |Dest. Group (4) |
+----------------+ +----------------+
Sample Scenario and Destination Groups
Figure 7
The three initial SIP Service Providers offer voice and IM services.
GlobalSSP has defined two Destination Groups and MidwestSSP and
NewYorkSSP have each defined one Destination Group. Each Destination
Group is reachable via a Route associated with a set of SBEs.
Cartwright, et al. Expires January 15, 2009 [Page 21]
Internet-Draft ESPP Protocol July 2008
Figure 8 below further illustrates the details of the relationship
between the Flagstaff and New York destination groups operated by the
GlobalSSP and NewYorkSSP respectively. The examples in this section
focus on the relationship between GlobalSSP's Flagstaff destination
group and the NewYorkSSP's New York destination group.
FlagStaff
Destination Group
SBE-10 SBE-40
,-----. ,-. Route 3 --> ,-. ,-----.
,-' (SBE)______________________(SBE)-' `-.
/ `-' `-' \
/ \ <-- Route 300 / \
; : ; :
| | | |
: ; : ;
\ ,-. Route 4 --> ,+. /
\ (SBE)_____________________(SBE) /
`-. ,-'-' `-'`-. ,-'
`-----' SBE-11 <-- Route 304 SBE-41 `-----'
New York
Destination
Group
Sample Scenario - Destination Groups and SBEs
Figure 8
Each Route illustrated above is further defined in the Route table
(Table 3 below) to contain one or more SBEs that serve as the ingress
points for that Route.
Cartwright, et al. Expires January 15, 2009 [Page 22]
Internet-Draft ESPP Protocol July 2008
+-------------+-----------------------------------------------------+
| Routes | SBE NAPTRs |
+-------------+-----------------------------------------------------+
| RTFlag-NYC1 | Order = 10, Pref=10, Svcs=E2U+SIP, Regx = |
| Ingress | "!^.*$!sip:\\1@sbe40-newyork.newyorkssp.example1.co |
| route to | m!" |
| reach the | |
| New York | |
| Destination | |
| Group from | |
| Flagstaff. | |
| | |
| | |
| | |
| RTFlag-NYC2 | Order= 10, Pref=10, Svcs= E2U+IM, Regx = |
| Ingress | "!^.*$!im:\\1@sbe41-newyork.newyorkssp.example1.com |
| route to | !" |
| reach the | |
| New York | |
| Destination | |
| Group from | |
| Flagstaff. | |
| | |
| | |
| | |
| RTNYC-Flag1 | Order= 10, Pref=10, Svcs= E2U+SIP, Regx = |
| Ingress | "!^.*$!sip:\\1@sbe10-globalssp.example2.com!" |
| route to | |
| reach the | |
| Flagstaff | |
| Destination | |
| Group from | |
| New York. | |
| | |
| | |
| | |
| RTNYC-Flag2 | Order = 10, Pref=10, Svcs= E2U+IM, Regx = |
| Ingress | "!^.*$!im:\\1@sbe11-globalssp.example2.com!" |
| route to | |
| reach the | |
| Flagstaff | |
| Destination | |
| Group from | |
| New York. | |
+-------------+-----------------------------------------------------+
Table 3: Examples of Routes to SBEs Associations
Cartwright, et al. Expires January 15, 2009 [Page 23]
Internet-Draft ESPP Protocol July 2008
The Routes defined above can then be associated with the destination
groups that they support. This allocation is laid out in the Table 4
below.
+-------------+-------------+------------+------------+-------------+
| Destination | GlobalSSP | GlobalSSP | MidwestSSP | NewYorkSSP |
| Groups | Flagstaff | Boston | Chicago | New York |
+-------------+-------------+------------+------------+-------------+
| GlobalSSP | | RTFlag-Bos | RTFlag-Chi | RTFlag-NYC1 |
| Flagstaff | | | | RTFlag-NYC2 |
| | | | | |
| | | | | |
| | | | | |
| GlobalSSP | RTBos-Flag | | RTFlag-Chi | RTBos-NYC |
| Boston | | | | |
| | | | | |
| | | | | |
| | | | | |
| MidwestSSP | RTChi-Flag | RTChic-Bos | | RTChi-NYC |
| Chicago | | | | |
| | | | | |
| | | | | |
| | | | | |
| NewYorkSSP | RTNYC-Flag1 | RTNYC-Bos | RTNYC-Chi | |
| NewYork | RTNYC-Flag2 | | | |
| | | | | |
| | | | | |
+-------------+-------------+------------+------------+-------------+
Table 4: Example of Destination Groups to Routes Associations
4.3.1.2.2. ESPP Provisioning of Session Establishment Data
The Route, SBE, and Destination Group data is provisioned in the
appropriate ESPP Server of each participating SIP Service Provider
using the addRtes, addDestGroups, and addNAPTRs operations supported
by the ESPP protocol. An optional approach is to combine some of the
operations into a single ESPP request using the batchUpdate
operation. The following example SOAP/XML messages provision the
Routes, SBE NAPTRs, and Destination Groups for the example above.
Using the batchUpdate operation, the ESPP Client provisions the
Global SSPs Flagstaff SBE NAPTRs, Routes, and Destination Groups in
the NewYorkSSP's ESPP Server.
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope [snip] >
<SOAP-ENV:Body>
Cartwright, et al. Expires January 15, 2009 [Page 24]
Internet-Draft ESPP Protocol July 2008
<batchUpdateRqst>
<basicRqst> [snip] </basicRqst>
<batchUpdate>
<op>
<naptrAdd>
<oid>7845601000012345610</oid>
<eid>76543</eid>
<order>10</order>
<pref>10</pref>
<flags>u</flags>
<svcs>E2U+SIP</svcs>
<regx>!^.*$!sip:\\1@sbe10-globalssp.example2.com!</regx>
</naptrAdd>
<naptrAdd>
<oid>7845601000012345611</oid>
<eid>76543</eid>
<order>10</order>
<pref>10</pref>
<flags>u</flags>
<svcs>E2U+IM</svcs>
<regx>!^.*$!im:\\1@sbe11-globalssp.example2.com!</regx>
</naptrAdd>
<rteAdd>
<oid>7845601000012345620</oid>
<eid>76543</eid>
<rteName>RTNYC-Flag1</rteName>
<sbeNAPTRId>7845601000012345610</sbeNAPTRId>
<isInSvc>true</isInSvc>
</rteAdd>
<rteAdd>
<oid>7845601000012345621</oid>
<eid>76543</eid>
<rteName>RTNYC-Flag2</rteName>
<sbeNAPTRId>7845601000012345611</sbeNAPTRId>
<isInSvc>true</isInSvc>
</rteAdd>
<destGroupAdd>
<oid>7845601000012345630</oid>
<eid>76543</eid>
<destGroupName>FlagstaffDG</destGroupName>
<rteId>7845601000012345620</rteId>
<rteId>7845601000012345621</rteId>
</destGroupAdd>
<op>
</batchUpdateRqst>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Cartwright, et al. Expires January 15, 2009 [Page 25]
Internet-Draft ESPP Protocol July 2008
Figure 9
Using the alternative approach of a single ESPP operation for each
object type (as opposed to the batchUpdate operation), the ESPP
Client provisions the NewYorkSSP's NAPTRs, Routes, and Destination
Groups in the GlobalSSP's ESPP Server.
Provision the New York SSP's New York NAPTRs in the Global SSPs
Flagstaff SBEs ESPP Server.
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope [snip] >
<SOAP-ENV:Body>
<addNAPTRsRqst>
<basicRqst> [snip] </basicRqst>
<naptr>
<oid>7845601000012345612</oid>
<eid>76544</eid>
<order>10</order>
<pref>10</pref>
<flags>u</flags>
<svcs>E2U+SIP</svcs>
<regx>!^.*$!sip:\\1@sbe40-newyork.newyorkssp.example1.com!</regx>
</naptr>
<naptr>
<oid>7845601000012345613</oid>
<eid>76544</eid>
<order>10</order>
<pref>10</pref>
<flags>u</flags>
<svcs>E2U+IM</svcs>
<regx>!^.*$!im:\\1@sbe41-newyork.newyorkssp.example1.com!</regx>
</naptr>
</addNAPTRsRqst>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figure 10
The ESPP Client provisions the New York SSP's New York Routes in the
Global SSP's ESPP Server.
Cartwright, et al. Expires January 15, 2009 [Page 26]
Internet-Draft ESPP Protocol July 2008
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope [snip] >
<SOAP-ENV:Body>
<addRtesRqst>
<basicRqst> [snip] </basicRqst>
<rte>
<oid>7845601000012345622</oid>
<eid>76544</eid>
<rteName>RTFlag-NYC1</rteName>
<sbeNAPTRId>7845601000012345612</sbeNAPTRId>
<isInSvc>true</isInSvc>
</rte>
<rte>
<oid>7845601000012345623</oid>
<eid>76544</eid>
<rteName>RTFlag-NYC2</rteName>
<sbeNAPTRId>7845601000012345613</sbeNAPTRId>
<isInSvc>true</isInSvc>
</rte>
</addRtesRqst>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figure 11
The ESPP Client provisions the New York SSP's New York Destination
Groups in the Global SSP's ESPP Server.
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope [snip] >
<SOAP-ENV:Body>
<addDestGroupsRqst>
<basicRqst> [snip] </basicRqst>
<destGroup>
<oid>7845601000012345631</oid>
<eid>76544</eid>
<destGroupName>NewYorkDG</destGroupName>
<rteId>7845601000012345622</rteId>
<rteId>7845601000012345623</rteId>
</destGroup>
</addDestGroupsRqst>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figure 12
Cartwright, et al. Expires January 15, 2009 [Page 27]
Internet-Draft ESPP Protocol July 2008
4.3.1.3. Public Identities, TN Ranges, and RNs
4.3.1.3.1. Description of Identities, TN Ranges, and RNs
With the enterprises and SED data in place, SSPs have established the
Destination Groups they wish to exchange traffic to. Public
identities such as telephone numbers (TN), ranges of TNs, RNs, IM
identifiers can now be provisioned into Destination Groups. This
scenario illustrates the provisioning of TNs, TN Ranges and RNs for
voice traffic exchanges, as well as the provisioning of TNs and IM
identifiers for IM service.
A group of friends wishes to take advantage of their voice and IM
services by having their calls within the group always use the most
efficient technology. These friends are spread out between Boston,
New York, Chicago and Phoenix and across three SSPs. Their public
identities (TNs and IM IDs) are defined below. To simplify the
scenario, the delivery of Instant Messages uses the same SBEs as the
voice traffic. As messaging grows, there may be a need to separate
the SBEs into voice and data portals which would create new SBE NAPTR
records and, optionally, new Routes. Note that this is a technical
example for the purpose of illustrating a protocol specification;
end-user privacy considerations must apply.
+--------+-------------+-------------+------------+-----------------+
| Subscr | Number | Destination | SSP | IM Identity |
| iber | | Group | | |
+--------+-------------+-------------+------------+-----------------+
| Pat | 928-774-555 | FlagstaffDG | GlobalSSP | imPat@globalssp |
| | 5 | | | .example2.com |
| | | | | |
| Ashley | 312-746-555 | ChicagoDG | MidwestSSP | imAshley@midwes |
| | 5 | | | tssp.example3.c |
| | | | | om |
| | | | | |
| Vince | 718-330-555 | NewYorkDG | NewYorkSSP | imVince@newyork |
| | 5 | | | ssp.example1.co |
| | | | | m |
| | | | | |
| Carl | 617-414-555 | BostonDG | GlobalSSP | imCarl@globalss |
| | 5 | | | p.example2.com |
+--------+-------------+-------------+------------+-----------------+
Table 5
These four subscribers have authorized their friends to see their
public identities. The SSPs have also defined TN Ranges associated
with the new VoIP services as shown below.
Cartwright, et al. Expires January 15, 2009 [Page 28]
Internet-Draft ESPP Protocol July 2008
+-------------------------+--------------------+--------------------+
| Destination Group | TN Range | |
| Name/ID | | |
+-------------------------+--------------------+--------------------+
| FlagstaffDG | 928-774-5000 | 928-774-5999 |
| | | |
| ChicagoDG | 312-746-5500 | 312-746-5600 |
| | | |
| NewYorkDG | 718-330-5250 | 718-330-5590 |
| | | |
| | 718-330-4000 | 718-330-4999 |
| | | |
| BostonDG | 617-414-5555 | 617-414-5560 |
+-------------------------+--------------------+--------------------+
Table 6
To support number portability in some countries, Routing Numbers
(RNs) have identified each of the CMSes within the network. Although
there may be an RN associated with each CMS, we show only the
relevant sub-set applicable to this example:
+---------------------+---------------------+-----------------------+
| Proxy | Destination Group | RN |
+---------------------+---------------------+-----------------------+
| Proxy-center | FlagstaffDG | 928-774-1000 |
| | | |
| Proxy-lakestreet | ChicagoDG | 312-746-1000 |
| | | |
| Proxy-bronx | NewYorkDG | 718-330-1000 |
| | | |
| Proxy-fenway | BostonDG | 617-414-1000 |
+---------------------+---------------------+-----------------------+
Table 7
4.3.1.3.2. ESPP Provisioning of TNs, RNs, and identities
The Public Identity, TN Range and RN data can then be provisioned in
the appropriate ESPP Server of each SSP using the addPvtIds,
addPubIds, addTNRs, and addRNs operations supported by the ESPP
protocol. An optional approach is to combine some of the operations
into a single request using the batchUpdate operation. The following
example SOAP/XML messages provision the data described above.
Using the batchUpdate operation, the ESPP Client provisions four
GlobalSSP elements in the Flagstaff destination group. This command
is sent to the NewYorkSSP's ESPP Server and to any other applicable
Cartwright, et al. Expires January 15, 2009 [Page 29]
Internet-Draft ESPP Protocol July 2008
peer servers.
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope [snip] >
<SOAP-ENV:Body>
<batchUpdateRqst>
<basicRqst> [snip] </basicRqst>
<batchUpdate>
<op>
<pviAdd>
<oid>7845601000012345650</oid>
<eid>76544</eid>
<pvtId>patsPrivateIdentifier</pvtId>
</pviAdd>
<piAdd>
<oid>7845601000012345640</oid>
<eid>76543</eid>
<pubId>9287745555</pubId>
<dgId>7845601000012345630</dgId>
<pvtId>7845601000012345650</pvtId>
</piAdd>
<piAdd>
<oid>7845601000012345641</oid>
<eid>76543</eid>
<pubId>imPat@globalssp.example2.com</pubId>
<svcs>E2U+IM</svcs>
<dgId>7845601000012345630</dgId>
<pvtId>7845601000012345650</pvtId>
</piAdd>
<tnRAdd>
<oid>7845601000012345642</oid>
<eid>76543</eid>
<tnRStrt>9287745000</tnRStrt>
<tnREnd>9287745999</tnREnd>
<dgId>7845601000012345630</dgId>
</tnRAdd>
<rnAdd>
<oid>7845601000012345643</oid>
<eid>76543</eid>
<rn>9287741000</rn>
<dgId>7845601000012345630</dgId>
</rnAdd>
</op>
</batchUpdate>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figure 13
Cartwright, et al. Expires January 15, 2009 [Page 30]
Internet-Draft ESPP Protocol July 2008
Using the batchUpdate operation, the ESPP Client provisions four
NewYorkSSP elements in the New York destination group. This command
is sent to the GlobalSSP's ESPP Server (and to any other applicable
servers).
Cartwright, et al. Expires January 15, 2009 [Page 31]
Internet-Draft ESPP Protocol July 2008
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope [snip] >
<SOAP-ENV:Body>
<batchUpdateRqst>
<basicRqst> [snip] </basicRqst>
<batchUpdate>
<op>
<pviAdd>
<oid>7845601000012345651</oid>
<eid>76544</eid>
<pvtId>vincesPrivateIdentifier</pubId>
</pviAdd>
<piAdd>
<oid>7845601000012345644</oid>
<eid>76544</eid>
<pubId>7183305555</pubId>
<dgId>7845601000012345631</dgId>
<pvtId>7845601000012345651</pvtId>
</piAdd>
<piAdd>
<oid>7845601000012345645</oid>
<eid>76544</eid>
<pubId>imVince@newyorkssp.example1.com</pubId>
<svcs>E2U+IM</svcs>
<dgId>7845601000012345631</dgId>
<pvtId>7845601000012345651</pvtId>
</piAdd>
<tnRAdd>
<oid>7845601000012345646</oid>
<eid>76544</eid>
<tnRStrt>7183305250</tnRStrt>
<tnREnd>7183305590</tnREnd>
<dgId>7845601000012345631</dgId>
</tnRAdd>
<rnAdd>
<oid>7845601000012345647</oid>
<eid>76544</eid>
<rn>7183301000</rn>
<dgId>7845601000012345631</dgId>
</rnAdd>
</op>
</batchUpdate>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figure 14
Cartwright, et al. Expires January 15, 2009 [Page 32]
Internet-Draft ESPP Protocol July 2008
4.3.2. Deployment Scenario and Resolution
4.3.2.1. Initiating an Outgoing Call
Initiating a call from Pat to Vince, the CMS hosting Pat launches an
ENUM query to the GlobalSSP addressing server. The addressing server
takes the E.164 address and examines the Public Identities to see if
the specific number is set in the server.
Vince's number is found in the New York Destination Group. This
Destination Group is associated with the Routes RTFlag-NYC1 and
RTFlag-NYC2 that link Flagstaff with New York City. Each of these
Routes has a single SBE NAPTR record. The addressing server would
respond to the CMS with both NAPTR records. The CMS then attempts to
complete the call to the NewYorkSSP by sending the call setup to the
address(es) found in the NAPTR record. The detailed steps involved
in this process are:
1. The CMS normalizes the TN to an e.164 format and queries the
GlobalSSP ESPP Server, which results in the following response:
$ORIGIN 5.5.5.5.0.3.3.8.1.7.1.ssp-example.
NAPTR 10 100 "u" "E2U+SIP" "!^.*$
!sip:\\1@sbe40-newyorkssp.newyorkssp.example1.com!".
NAPTR 10 101 "u" "E2U+IM" "!^.*$
!im:imvince@sbe41-newyorkssp.newyorkssp.example1.com!".
Figure 15
2. Assuming that the CMS is interested in the SIP service, as it is
initiating a telephone call, the CMS now executes a NAPTR query to
the DNS server for "sbe40-newyorkssp.example1.com" resulting in:
sbe40-newyorkssp.example1.com.
order pref flgs service regx replacement
IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.sbe40-newyorkssp
.newyorkssp.example1.com
Figure 16
3. The CMS now sends a DNS SRV query for _sip._udp.sbe40-newyorkssp.
newyorkssp.example1.com which results in:
Cartwright, et al. Expires January 15, 2009 [Page 33]
Internet-Draft ESPP Protocol July 2008
$ORIGIN _sip._udp.sbe40-newyorkssp.newyorkssp.example1.com.
(Some content not included for clarity purposes.)
IN SRV 0 1 5060 sbe40-newyorkssp.example1.com
;; ANSWER SECTION
sbe40-newyorkssp.newyorkssp.example1.com A 192.0.2.17
sbe40-newyorkssp.newyorkssp.example1.com A 192.0.2.18
Figure 17
4. Now the CMS applies the regular expression rules to the NAPTR
obtained in step 1 and places the result into the SIP Request URI:
INVITE sip:17183305555@sbe40-newyorkssp.newyorkssp.example1.com
SIP/2.0
(Other SIP INVITE content not included for clarity purposes.)
Figure 18
5. CMS sends the SIP INVITE to Vince via the SBE with associated
IPv4 address 192.0.2.17 to port 5060 using UDP as the transport
protocol.
4.3.2.2. Receiving an Incoming Call
Taking the call scenario described above, once the call request
arrives in NewYorkSSP's network the SBE within NewYorkSSP queries its
own ESPP Server and finds a match for Mary's number in the TN Range
records (718-330-5250 to 718-330-5590). The NewYorkSSP ESPP Server
has been provisioned with intra-domain routes so that the SBE can
locate the proper CMS. The NewYorkSSP ESPP Server contains the New
York Destination Group that is associated with a intra-domain Route
that is not shared with the other SSPs. This allows the internal
routing topology of an SSP to remain private to the SSP. There is
only one route for this range of phone numbers with only one NAPTR
record. The data used to resolve the query looks like:
TN Range: 718-330-5250 to 718-330-5590
Destination Group: New York
Route: RTNYC-Private
NAPTR 10 101 "u" "E2U+SIP" "!^.*$
!sip:\\1@cms-bronx.newyorkssp.example1.com!" .
Figure 19
Cartwright, et al. Expires January 15, 2009 [Page 34]
Internet-Draft ESPP Protocol July 2008
4.3.2.2.1. Query using the Routing Number
If the number has been ported, there are a number of cases where the
query may also contain a Routing Number. The Routing Number is a
reference number for one or more telephone switches where previously
the first 6 digits of the phone number clearly identified the switch.
Once the call request arrives in NewYorkSSP's network the SBE within
NewYorkSSP queries its own ESPP Server and finds a match for the RN
or prefix (718-330-1000) in the New York Destination Group. The rest
of the routing lookup is similar to what is described for the
telephone number above.
RN: 718-330-1000
Destination Group: New York
Route: RTNYC-Private
NAPTR 10 101 "u" "E2U+SIP" "!^.*$
!sip:\\1@cms-bronx.newyorkssp.example1.com!" .
Figure 20
4.3.2.2.2. Growth of the SIP Service Provider Group
When NewSSP is ready to exchange traffic, their ESPP Server receives
a batch download the latest data from all its peers via the
Registrar. The Registrar takes an image of the current data that
each peer has allowed NewSSP to view and performs a secure file
transfer to the NewSSP addressing server. Following the download,
the NewSSP ESPP Server connects to the Registrar and begin processing
real-time updates to ensure that any changes made since creating the
batch download files are made in the addressing server.
4.3.3. Generic Examples
Additional examples are available in Appendix I of [CableLabs-ESPP].
4.4. Protocol Specification
This section describes the general concepts that apply to the
protocol's operations. It also describes each individual protocol
operation, its input and output objects, and its functional
characteristics. The complete normative specification of the
protocol (the WSDL and XSD definitions) can be found in Section 8,
Formal API Definition, in this document. Note that if any
specification conflicts exist between this section and Section 8, the
normative definitions contained in Section 8 take precedence.
Cartwright, et al. Expires January 15, 2009 [Page 35]
Internet-Draft ESPP Protocol July 2008
The protocol utilizes SOAP 1.1 [SOAP], WSDL1.1 [WSDL], and XML 1.0
[XML].
4.4.1. General Protocol Concepts
The following sub-sections describe the object structures and
concepts that are applicable to many of the protocol operations
4.4.1.1. Basic Request Object
All ESPP operations that may potentially modify persistent protocol
objects require a BasicRqst object to be passed in, in addition to
other object types that are specific to each operation. The basic
request object contains a client ID, a transaction ID, the minor
version of the protocol, and an optional extension element. Each of
the values is described in the subsequent sub-sections.
<complexType name="BasicRqstType">
<sequence>
<element name="clientId" type="est:ClientIdType"/>
<element name="transId" type="est:TransIdType"/>
<element name="minorVer" type="est:VerType"/>
<element name="ext" type="est:ExtAnyType" minOccurs="0"/>
</sequence>
<complexType>
<simpleType name="ClientIdType">
<restriction base="int"/>
</simpleType>
<simpleType name="VerType">
<restriction base="unsignedLong"/>
</simpleType>
4.4.1.2. Basic Query Object
All ESPP "get" operations require a BasicQueryRqst object to be
passed in, in addition to other object types that are specific to
each get operation. The basic query object contains a client ID, the
minor version of the protocol, and an optional extension element.
Each of the values is described in the subsequent sub-sections.
Notice that no transaction ID is necessary for query operations.
Cartwright, et al. Expires January 15, 2009 [Page 36]
Internet-Draft ESPP Protocol July 2008
<complexType name="BasicQueryType">
<sequence>
<element name="clientId" type="est:ClientIdType"/>
<element name="minorVer" type="est:VerType"/>
<element name="ext" type="est:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
4.4.1.3. Authentication
For each ESPP connection, the ESPP Client and ESPP Server MUST use
HTTP Digest based authentication as defined in [RFC2617]. The HTTP
Digest authentication SHOULD be performed once per connection. To
further support authentication and operational activities, such as
auditing, each ESPP operation requires a client ID as input.
4.4.1.4. Transaction ID
Each ESPP Client maintains a transaction ID counter for each ESPP
Server that it is configured to update. Similarly, each ESPP Server
maintains the transaction ID for each ESPP Client from which it
receives updates. These transaction IDs are maintained in persistent
storage on both client and server. The protocol data element that
contains the transaction ID for each operation is declared as
follows:
<element name="transId" type="est:TransIdType"/>
<simpleType name="TransIdType">
<restriction base="unsignedLong"/>
</simpleType>
A transaction ID is sent with each update request to an ESPP Server.
The transaction ID MUST be present in a protocol request operation
whose purpose is to modify data within an ESPP Server. The ESPP
Client and ESPP Server must implement the transaction ID as a 64-bit
value. The initial value for the transaction ID on the ESPP Client
MUST either be chosen randomly, start at zero, or be configured by
the SIP Service Provider before protocol processing or bootstrap file
generation begins.
When generating an API-based update request or a file based
batchFileUpdateRqst request destined for an ESPP Server, the ESPP
Client MUST use the current transaction ID for the target server,
Cartwright, et al. Expires January 15, 2009 [Page 37]
Internet-Draft ESPP Protocol July 2008
which is one increment greater than the previous successful
transaction ID (or the first transaction ID in the counter if this is
the first request generated for the given ESPP Client/server pair).
After successfully generating a batchFileUpdateRqst structure or
after receiving a successful response from an API base request, the
client increments the transaction ID for that server by one. When
the 'isFullResync' flag is set in the batchFileUpdateRqst, the ESPP
Server MUST set the transaction ID for that client to the value
received in the batchFileUpdateRqst.
When receiving a transaction ID in a request, the ESPP Server
compares it to its current transaction ID value. If the transaction
ID from the client is one greater than the transaction ID from the
server, the request is processed normally. If the request succeeds
on the server, the ESPP Server MUST update its transaction ID to be
the one received from the client. Once all database changes have
been synchronized to persistent storage, the server MUST respond with
a successful result code. When the client receives the response from
the server indicating that the request has succeeded, the client MUST
increment its transaction ID by one.
If the server receives a request from a client with a transaction ID
that is the same as server's current transaction ID for that client,
the server compares the content of the request received from the
client to the content of the request most recently received from that
client. If the content is identical, this indicates that the client
failed to receive the response to the previous transaction. The
client is assumed to be retrying that transaction that the server has
already successfully processed. In this event the server SHOULD NOT
modify its database. The ESPP Server MUST simply return the
identical response that it returned in response to the clients first
attempt to process the request/response.
In the case that the transaction ID is the same but the request
content is different, or the transaction ID from the client is
different but is not one greater than the transaction ID for that
client on the server, the server and client are out of sync. In this
event, the ESPP Server SHOULD return the appropriate error code
(Transaction ID out of sequence). The ESPP Client MUST automatically
suspend protocol updates to that server and raise a critical alarm.
Manual intervention is likely required at this point to analyze and
clear the error, perhaps by initiating a full re-synchronization of
the client's data store, and then re-enabling real-time protocol
communication to that ESPP Server.
In cases where the server determines the transaction ID to be
correct, there are two general categories of errors: system errors
and business errors. In the event a system error occurs (e.g., disk
Cartwright, et al. Expires January 15, 2009 [Page 38]
Internet-Draft ESPP Protocol July 2008
space has been exhausted) the ESPP Server MUST return the appropriate
error message (System Unavailable Error or Authentication Error) and
the ESPP Client SHOULD suspend real-time updates to the server for
some period of time configured by the SIP Service Provider, and then
resume after that time has elapsed. In this case the ESPP Client
MUST not update the transaction ID as transaction IDs are only
consumed/updated by the client on successful responses to a given API
request or when a file based update is successfully generated by the
client. In the event a business error occurs (e.g., a data element
fails the regular expression validation), the ESPP Server MUST return
the appropriate error code for the given error and operation. In
response to this type of error response the client MUST, again, not
consume that transaction ID, because the transaction did not complete
successfully. The client MUST suspend real-time protocol
communication with that ESPP Server and generate an internal alarm.
Manual intervention is required to analyze and rectify the erroneous
data that caused the error and then re-enable real-time protocol
communication with the ESPP Server.
4.4.1.5. Version Identification
The version of the ESPP protocol in use is defined by the combination
of the major version ID embedded in the namespace of the XSD and the
minor version ID that is passed in with each request as an element of
the BasicRqstType object.
A major version ID will change when a change is made to the protocol
that is not backward compatible. The minor version ID may change
when a change is made to the protocol that is backward compatible.
The version ID passed in by the ESPP Client MUST indicate the version
that the client supports; it SHOULD be the version that the client
believes that the ESPP Server supports. When a message arrives at
the server, the server MUST evaluate the version indicator passed in
by the ESPP Client and it MUST return the appropriate error code and
message if the version is not one that is supported by the server.
Refer to the list of response codes for the appropriate code to
return in this circumstance.
4.4.1.6. Basic Response Object
The request/input object type is distinct for each operation.
However, most operations of the ESPP protocol return the same
response/output object type, CmnRspnsMsg. In keeping with the
Document Literal Wrapped design approach described in the
introductory sections, the WSDL declaration of this response message
is declared as follows:
Cartwright, et al. Expires January 15, 2009 [Page 39]
Internet-Draft ESPP Protocol July 2008
<wsdl:message name="cmnRspnsMsg">
<wsdl:part name="rspns" element="est:cmnRspns"/>
</wsdl:message>
<complexType name="BasicRspnsType">
<sequence>
<element name="resCode" type="int"/>
<element name="resMsg" type="string"/>
<element name="ext" type="est:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
The resCode element is a response code and the resMsg is the
corresponding response message. The BasicRspnsType may also be
extended using the ext element. Each of these elements is further
described in subsequent sections.
4.4.1.7. Object ID and Enterprise ID
As described in the Logical Structure section of this document, each
object instance in ESPP has a unique identifier, its oId, and the
identifier os its "owning" operational entity, its eId. These two
data elements are defined as follows:
<simpleType name="OIdType">
<restriction base="unsignedLong"/>
</simpleType>
<simpleType name="EIdType">
<restriction base="string"/>
</simpleType>
These two fields are further defined as follows:
o oId:
Each object is uniquely identifiable using its object ID. An
object ID is guaranteed to be unique within an ESPP Server and
ESPP Client, regardless of the number of ESPP Clients populating
objects into a given ESPP Server. An ESPP Client MUST create
and assign the Object IDs it provisions. This approach has
significant performance advantages. The management of the
unique name space for ESPP object IDs and the approach for
creation and assignment of object IDs is defined as follows:
Cartwright, et al. Expires January 15, 2009 [Page 40]
Internet-Draft ESPP Protocol July 2008
* ESPP Clients and Servers MUST implement the oId attribute as
an unsigned 64-bit value, unsigned long. Unsigned longs
support up to 20 digits, but refer to the data validation
appendix of this document where the maximum allowable value
of an unsigned long is documented.
* The 8 most significant digits of the object ID MUST contain a
client ID that is guaranteed to be globally unique within an
ESPP federation. This client ID MUST be right justified in
this 8 digit field, leaving any unused most significant
digits empty. The client ID MUST be the combination of two
parts, a 1 to 6 digit organization ID and a 2 digit suffix.
The organization ID portion of the client ID MUST be a number
acquired from the IANA Private Enterprise Number (PEN)
registry, http://www.iana.org/assignments/enterprise-numbers.
The 2 digit suffix MUST be used to further uniquely identify
an ESPP Client software within the organization represented
by the organization ID. The 2 digit suffix is necessary in
cases where more than one ESPP Client, within the same ESPP
federation, are from the same organization and therefore
would have the same organization ID. The suffix MUST be
within the range of 00 and 99, inclusive. Prior to
introducing an ESPP Client into an ESPP federation, the
organization that operates that ESPP Client acquires an
organization ID, adds an appropriate 2 digit suffix. The
resulting client ID will then be used to formulate the object
Ids for the ESPP objects created by that client software.
* The remaining, right hand, 12 digits of the object ID MUST
contain an object ID that is guaranteed to be unique within
the client identified by the client ID.
* As an example, a valid object ID would be 123401000012345678.
In this example, 1234 is the organization ID of the
organization that manages the ESPP Client implementation, 01
is the client ID suffix, and 000012345678 is the object ID
that is unique within that ESPP client. Notice that the two
most significant digit fields are not used and are not
necessary in this example. The result is an object ID that
is unique within the ESPP federation.
o eId:
The enterprise ID data element that resides as a data element
within each ESPP object uniquely identifies an operational
entity within an ESPP federation that is responsible for, or
owns, that object from a business perspective. This is distinct
from the client ID, which identifies the piece of software that
performs the mechanics of provisioning an ESPP object within an
Cartwright, et al. Expires January 15, 2009 [Page 41]
Internet-Draft ESPP Protocol July 2008
ESPP client. The globally unique name space for the assignment
of an enterprise ID is the IANA Private Enterprise Number (PEN)
registry, http://www.iana.org/assignments/enterprise-numbers.
Prior to contributing its addresses and routing information to
an ESPP federation an enterprise acquires a PEN, which will then
reside in the eId field of each ESPP object that and ESPP Client
provisions on behalf of that enterprise.
The ESPP Client and ESPP Server MUST implement the oId attribute as
an unsigned 64-bit value.
4.4.1.8. Response Codes and Messages
The response to each protocol operation includes exactly one response
code and response message. The response codes that each operation is
permitted to return are listed in each sub-section that describes
each operation. And the consolidated list of response codes and
messages are listed in the "Response Codes and Messages" section of
this document.
All real-time API operations of the ESPP protocols MUST be atomic,
all aspects of the operation will fail or all will succeed. An
operation should never result in a "partial success". As a result,
the response code returned by any given operation call indicates
whether the operation succeeded or failed. Each failure reason has a
unique failure response code and message, and only one may be
returned in response to any given operation call. The protocol
object that houses the response code and message is called
BasicRspnsType.
4.4.1.9. Extensibility
Extensibility allows a given ESPP Client or ESPP Server to supplement
ESPP messages with additional object or data elements that may be
appropriate for a given ESPP deployment or operational scenario.
ESPP is implicitly and explicitly extensible. Implicit extensibility
is supported by the fact that XSD and WSDL definitions may be
extended without breaking backward compatibility. New WSDL
operations can be added and new XSD data types can be added without
breaking backward compatibility. Explicit extensibility is supported
through the use of the XSD "any" type. Each object type definition
in ESPP contains an additional attribute called "ext", which is of
type ExtAnyType, which contains one or more an XSD "any" elements.
Furthermore, the BasicRqstType and BasicRspnsType also contain an
"ext" element to allow the addition of objects of any type to be
added to the request and response objects that are used for each ESPP
operation. And ESPP Server may dynamically evaluate the version ID
of any given request and choose to accept or return these optional
Cartwright, et al. Expires January 15, 2009 [Page 42]
Internet-Draft ESPP Protocol July 2008
attributes from or to an ESPP Client.
<complexType name="ExtAnyType">
<sequence>
<any namespace="##other" maxOccurs="unbounded"/>
</sequence>
</complexType>
4.4.2. Protocol Operation Descriptions
The following sub-sections describe each individual protocol
operation in detail, its input and output objects, and its functional
characteristics.
4.4.2.1. Operation Name: addRtes
As described in the introductory sections, a Route represents a
collection of session-level peering points named Signaling path
Border Elements (SBEs). Routes are linked to Destination Groups to
establish the link between a set of public identities and their SBEs.
It is this indirect linking of public identities to SBEs that
significantly improves the scalability and manageability of the
peering data. Additions and changes to session-level peering points
are reduced to a single data distribution operation of a Route or
Destination Group in an addressing server, rather than millions of
data distribution updates to public identity records that
individually contain their peering point data.
The addRtes operation creates or overwrites one or more Routes in the
addressing server. If a Route with the given Route ID does not
exist, then the ESPP Server MUST create the route. If a Route with
the given Route ID does exist, then the ESPP Server MUST replace the
current properties of the Route with the properties passed into the
addRtes operation. If a Route with the given ID does exist, but was
created by a client other than the one calling the addRtes operation
then the ESPP Server SHOULD reject the request with the appropriate
error code, 2106.
In keeping with the Document Literal Wrapped design approach
described in the introductory sections, the WSDL declaration of the
operation is as follows:
Cartwright, et al. Expires January 15, 2009 [Page 43]
Internet-Draft ESPP Protocol July 2008
<wsdl:operation name="addRtes">
<wsdl:input message="addRtesRqstMsg"/>
<wsdl:output message="cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:message name="addRtesRqstMsg">
<wsdl:part name="rqst" element="est:addRtesRqst"/>
</wsdl:message>
<wsdl:message name="cmnRspnsMsg">
<wsdl:part name="rspns" element="est:cmnRspns"/>
</wsdl:message>
Inputs to the operation are wrapped in the addRtesRqst object, which
is declared as follows:
<element name="addRtesRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="rte" type="est:RteType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
As with all update operations, the basicRqst data element is a
required input. Refer to Section 4.4.1, General Protocol Concepts,
for a detailed description of this data element. One or more RteType
objects are also required. Any limitation on the maximum number of
routes that may be passed into a call to the addRtes operation is a
policy decision and is not limited by the protocol.
The RteType object structure is declared as follows:
Cartwright, et al. Expires January 15, 2009 [Page 44]
Internet-Draft ESPP Protocol July 2008
<complexType name="RteType">
<sequence>
<element name="oid" type="est:OIdType"/>
<element name="eid" type="est:EIdType"/>
<element name="rteName" type="string"/>
<element name="sbeNaptrId" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="isInSvc" type="boolean"/>
<element name="ext" type="est:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
The RteType object is comprised of the following data elements:
o oid: Exactly one object ID to uniquely identify the object
instance. This identifier is also an input to the delRtes,
getRtes, and addDestGroups operations to identify a given route.
o eid: Exactly one enterprise ID that uniquely identifies the
operational entity within the call routing community that is
responsible for, or "owns" this object.
o RteName: Exactly one human readable name of the Route.
o SBENaptrId: Zero or more NAPTR IDs.
o IsInSvc: Toggle-able boolean value that sets the Route in
service or out of service. The ESPP Server MUST NOT include the
NAPTR record(s) associated with an out-of-service route in the
response to a resolution request for a telephone number that is
associated with the Route that contains that border element.
o Ext: Point of extensibility described in Section 4.4.1.9.
Table 8 defines the result codes and messages that the addRtes
operation SHOULD return.
Cartwright, et al. Expires January 15, 2009 [Page 45]
Internet-Draft ESPP Protocol July 2008
+--------+----------------------------------------------------------+
| Result | Text |
| Code | |
+--------+----------------------------------------------------------+
| 1000 | Request Succeeded. |
| | |
| 2001 | Request syntax invalid. |
| | |
| 2002 | Request too large. |
| | |
| 2003 | Version not supported. |
| | |
| 2301 | System temporarily unavailable. |
| | |
| 2103 | Transaction ID out of sequence: [transaction ID |
| | received]:[ transaction ID expected]. |
| | |
| 2104 | Attribute value invalid: [attribute name]:[attribute |
| | value]:[objectType-objectId]. |
| | |
| 2106 | Object status or ownership does not allow for request: |
| | [request name]:[ attributeName]:[objectType-objectId]. |
+--------+----------------------------------------------------------+
Table 8: addRtes Operation Result Codes and Messages
4.4.2.2. Operation Name: addDestGroups
As described in the introductory sections, a Destination Group
represents a collection of public identities that are linked to a set
of Routes. Routes are linked to Destination Groups to establish the
link between a set of public identities and their session-level
peering points. The addDestGroups operation creates or overwrites
one or more Destination Groups in the addressing server. If a
destination group with the given destination group ID does not exist,
then the ESPP Server MUST create the destination group. If a
destination group with the given identity does exist, then the ESPP
Server MUST replace the current properties of that destination group
with the properties passed into the addDestGroups operation. If a
destination group with the given ID does exist, but was created by a
client other than the one calling the addDestGroups operation then
the ESPP Server SHOULD reject the request with the appropriate error
code, 2106.
In keeping with the Document Literal Wrapped design approach
described in the introductory sections, the WSDL declaration of the
operation is as follows:
Cartwright, et al. Expires January 15, 2009 [Page 46]
Internet-Draft ESPP Protocol July 2008
<wsdl:operation name="addDestGroups">
<wsdl:input message="addDestGroupsRqstMsg"/>
<wsdl:output message="cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:message name="addDestGroupsRqstMsg">
<wsdl:part name="rqst" element="est:addDestGroupsRqst"/>
</wsdl:message>
<wsdl:message name="cmnRspnsMsg">
<wsdl:part name="rspns" element="est:cmnRspns"/>
</wsdl:message>
Inputs to the operation are wrapped in the addDestGroupsRqst object,
which is declared as follows:
<element name="addDestGroupsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="destGroup" type="est:DestGroupType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
As with all update operations, the basicRqst data element is a
required input. Refer to Section 4.4.1, General Protocol Concepts,
for a detailed description of this data element. Also required is
one or more DestGroupType objects. Any limitation on the maximum
number of destination groups that may be passed into a call to the
addDestGroups operation is a policy decision and is not limited by
the protocol.
The DestGroup object structure is declared as follows:
<complexType name="DestGroupType">
<sequence>
<element name="oid" type="est:OIdType"/>
<element name="eid" type="est:EIdType"/>
<element name="destGroupName" type="string"/>
<element name="rteId" type="est:OIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="ext" type="est:ExtAnyType" minOccurs="0"/>
Cartwright, et al. Expires January 15, 2009 [Page 47]
Internet-Draft ESPP Protocol July 2008
</sequence>
</complexType>
The data elements of the DestGroupType are described as follows:
o oId: Exactly one object ID that provides the identity of the
object. This identifier is also an input to other operations
that must refer to a Destination Group, such as delDestGroups,
getDestGroups, and addPubIds operations to identify a given
destination group.
o Eid: Exactly one enterprise ID that uniquely identifies the
operational entity within the call routing community that is
responsible for, or "owns" this object.
o destGroupName: Exactly one human readable name of the
destination group.
o RteID: The identity of zero or more routes that the Public
Identities, RNs, and TN Ranges in this destination group can be
routed through.
o Ext: Point of extensibility described in Section 4.4.1.9.
The ESPP Server MUST reject any addDestGroups operation call that
attempts to create a destination group with a route ID that does not
exist within the context of the addressing server.
Table 9 defines the result codes and messages that the addDestGroups
operation SHOULD return.
Cartwright, et al. Expires January 15, 2009 [Page 48]
Internet-Draft ESPP Protocol July 2008
+--------+----------------------------------------------------------+
| Result | Text |
| Code | |
+--------+----------------------------------------------------------+
| 1000 | Request Succeeded. |
| | |
| 2001 | Request syntax invalid. |
| | |
| 2002 | Request too large. |
| | |
| 2003 | Version not supported. |
| | |
| 2301 | System temporarily unavailable. |
| | |
| 2103 | Transaction ID out of sequence: [transaction ID |
| | received]:[ transaction ID expected]. |
| | |
| 2104 | Attribute value invalid: [attribute name]:[attribute |
| | value]:[objectType-objectId]. |
| | |
| 2105 | Object does not exist: [attribute name]:[ |
| | objectType-objectId]. |
| | |
| 2106 | Object status or ownership does not allow for request: |
| | [request name]:[ attributeName]:[objectType-objectId]. |
+--------+----------------------------------------------------------+
Table 9: addDestGroups Operation Result Codes and Messages
4.4.2.3. Operation Name: addPubIds
As described in the introductory sections, a Public Identity object
represents a public addressable identity (such as a telephone number,
email address, or some other addressable string). It is linked to
SBEs and NAPTRs (indirectly via a Destination Group ID), and,
alternatively, to directly associated NAPTRs. The ESPP protocol
allows a Public Identity to have a relationship to a Destination
Group and/or a set of NAPTRs.
A Public Identity may also be associated with a Private Identity
object. The addPubIds operation creates or overwrites one or more
PubId objects in the addressing server. If a PubId object with the
same object ID does not exist within the context of the addressing
server, then the ESPP Server MUST create the PubId object. If such
an object does exist within the context of the addressing server,
then the ESPP Server MUST replace the current properties of that
object with the values passed into the addPubIds operation. If a
Public Identity with the given ID does exist, but was created by a
Cartwright, et al. Expires January 15, 2009 [Page 49]
Internet-Draft ESPP Protocol July 2008
client other than the one calling the addPubIds operation then the
ESPP Server SHOULD reject the request with the appropriate error
code, 2106.
In keeping with the Document Literal Wrapped design approach
described in the introductory sections, the WSDL declaration of the
operation is as follows:
<wsdl:operation name="addPubIds">
<wsdl:input message="esp:addPubIdsRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:message name="addPubIdsRqstMsg">
<wsdl:part name="rqst" element="est:addPubIdsRqst"/>
</wsdl:message>
<wsdl:message name="cmnRspnsMsg">
<wsdl:part name="rspns" element="est:cmnRspns"/>
</wsdl:message>
Inputs to the operation are wrapped in the addPubIdsRqst object,
which is declared as follows:
<element name="addPubIdsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="pi" type="est:PubIdType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
As with all update operations, the basicRqst data element is a
required input. Refer to the Section 4.4.1, General Protocol
Concepts, for a detailed description of this data element. Also
required is one or more PubIdType objects. Any limitation on the
maximum number of Public Identities that may be passed into a call to
the addPubIds operation is a policy decision and is not limited by
the protocol.
The PubIdType object structure is declared as follows:
Cartwright, et al. Expires January 15, 2009 [Page 50]
Internet-Draft ESPP Protocol July 2008
<complexType name="PubIdType">
<sequence>
<element name="oid" type="est:OIdType"/>
<element name="eid" type="est:EIdType"/>
<element name="pubId" type="string"/>
<element name="svcs" type="string"/>
<element name="dgId" type="est:OIdType" minOccurs="0"/>
<element name="naptrId" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="pvtId" type="est:OIdType" minOccurs="0"/>
<element name="ext" type="est:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
The PubIdType is comprised of the following data elements:
o oId: Exactly one object ID that provides the identity of the
object.
o Eid: Exactly one enterprise ID that uniquely identifies the
operational entity within the call routing community that is
responsible for or "owns" this object.
o PubId: Exactly one public identity that is a resolvable identity
within the context of the addressing server. This identity may,
for example, be a TN, an email address, or some other resolvable
identity.
o Svcs: Exactly one ENUM service type associated with the public
identity. This field's value must be of the form specified in
[RFC 3761] (e.g., E2U+pstn:sip+sip). The allowable values are a
matter of policy and not limited by this protocol.
o dgId: Zero or one object ID that identifies the Destination
Group this public identity object instance resides within. The
Destination Group's relationship to one or more Routes can then
define the peering points of Public Identities. The ESPP Server
MUST reject, with the appropriate error response code, an
attempt to create a public identity object containing a
Destination Group ID that does not exist within the appropriate
context of the addressing server.
o NAPTR: Zero or more NAPTRs. NAPTR objects directly associated
with a public identity can be a lower level, more data
distribution intensive approach to associating a telephone
number with its peering points.
Cartwright, et al. Expires January 15, 2009 [Page 51]
Internet-Draft ESPP Protocol July 2008
o PvtId: Zero or one object ID that optionally identified a
private identity to which this public identity is associated.
This provides the ability to create a "related" set of public
identities. The ESPP Server MUST return an error response if
the Private Identity object identified by this PvtId does not
exist within the context of the addressing server.
o Ext: Point of extensibility described in Section 4.4.1.9.
The ESPP protocol does not specifically disallow the creation of
Public Identities that have no associated NAPTRs and no associated
Destination Group.
Table 10 defines the result codes and messages that the addPubIds
operation SHOULD return.
+--------+----------------------------------------------------------+
| Result | Text |
| Code | |
+--------+----------------------------------------------------------+
| 1000 | Request Succeeded. |
| | |
| 2001 | Request syntax invalid. |
| | |
| 2002 | Request too large. |
| | |
| 2003 | Version not supported. |
| | |
| 2301 | System temporarily unavailable. |
| | |
| 2103 | Transaction ID out of sequence: [transaction ID |
| | received]:[ transaction ID expected]. |
| | |
| 2104 | Attribute value invalid: [attribute name]:[attribute |
| | value]:[objectType-objectId]. |
| | |
| 2105 | Object does not exist: [attribute name]:[ |
| | objectType-objectId]. |
| | |
| 2106 | Object status or ownership does not allow for request: |
| | [request name]:[ attributeName]:[objectType-objectId]. |
+--------+----------------------------------------------------------+
Table 10: addPubIds Operation Result Codes and Messages
Cartwright, et al. Expires January 15, 2009 [Page 52]
Internet-Draft ESPP Protocol July 2008
4.4.2.4. Operation Name: addPvtIds
As described in the introductory sections, a Private Identity object
represents a string of numbers or characters that serves to
associate, or group together, a set of related Public Identities.
The addPvtIds operation creates or overwrites one or more PvtId
objects in the addressing server. If a PvtId object with the same
object ID does not exist within the context of the addressing server,
then the ESPP Server MUST create the PvtId object. If such an object
does exist within the context of the addressing server, then the ESPP
Server MUST replace the current properties of that object with the
values passed into the operation. If a Private Identity with the
given ID does exist, but was created by a client other than the one
calling the addPvtIds operation then the ESPP Server SHOULD reject
the request with the appropriate error code, 2106.
In keeping with the Document Literal Wrapped design approach
described in the introductory sections, the WSDL declaration of the
operation is as follows:
<wsdl:operation name="addPvtIds">
<wsdl:input message="esp:addPvtIdsRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:message name="addPvtIdsRqstMsg">
<wsdl:part name="rqst" element="est:addPvtIdsRqst"/>
</wsdl:message>
<wsdl:message name="cmnRspnsMsg">
<wsdl:part name="rspns" element="est:cmnRspns"/>
</wsdl:message>
Inputs to the operation are wrapped in the addPvtIdsRqst object,
which is declared as follows:
<element name="addPvtIdsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="pvi" type="est:PvtIdType" maxOccurs="unbounded"/>
</sequence>
</complexType>
Cartwright, et al. Expires January 15, 2009 [Page 53]
Internet-Draft ESPP Protocol July 2008
</element>
As with all update operations, the basicRqst data element is a
required input. Refer to the Section 4.4.1, General Protocol
Concepts, for a detailed description of this data element. Also
required is one or more PubIdType objects. Any limitation on the
maximum number of Public Identities that may be passed into a call to
the addPubIds operation is a policy decision and is not limited by
the protocol.
The PvtIdType object structure is declared as follows:
<complexType name="PvtIdType">
<sequence>
<element name="oid" type="est:OIdType"/>
<element name="eid" type="est:EIdType"/>
<element name="pvtId" type="string"/>
<element name="ext" type="est:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
The PvtIdType is comprised of the following data elements:
o oId: Exactly one object ID that provides the identity of the
object.
o Eid: Exactly one enterprise ID that uniquely identifies the
operational entity within the call routing community that is
responsible for or "owns" this object.
o PvtId: Exactly one private identity that serves to associate, or
group together, a set of related Public Identities.
o Ext: Point of extensibility described in Section 4.4.1.9.
Table 11 defines the result codes and messages that the addPvtIds
operation SHOULD return.
Cartwright, et al. Expires January 15, 2009 [Page 54]
Internet-Draft ESPP Protocol July 2008
+--------+----------------------------------------------------------+
| Result | Text |
| Code | |
+--------+----------------------------------------------------------+
| 1000 | Request Succeeded. |
| | |
| 2001 | Request syntax invalid. |
| | |
| 2002 | Request too large. |
| | |
| 2003 | Version not supported. |
| | |
| 2301 | System temporarily unavailable. |
| | |
| 2103 | Transaction ID out of sequence: [transaction ID |
| | received]:[ transaction ID expected]. |
| | |
| 2104 | Attribute value invalid: [attribute name]:[attribute |
| | value]:[objectType-objectId]. |
| | |
| 2105 | Object does not exist: [attribute name]:[ |
| | objectType-objectId]. |
| | |
| 2106 | Object status or ownership does not allow for request: |
| | [request name]:[ attributeName]:[objectType-objectId]. |
+--------+----------------------------------------------------------+
Table 11: addPvtIds Operation Result Codes and Messages
4.4.2.5. Operation Name: addRNs
As described in the introductory sections, an RN object represents a
routing number and its indirect relationship to one or more SBEs (via
a Destination Group ID).
The addRNs operation creates or overwrites one or more RN objects in
the addressing server. If an RN object with the same object ID does
not exist within the context of the addressing server, then the ESPP
Server MUST create the RN object. If an RN object with the same
object ID does exist within the context of the addressing server,
then the ESPP Server MUST replace the current properties of that RN
with the properties passed into the addRNs operation. If an RN with
the given ID does exist, but was created by a client other than the
one calling the addRN operation then the ESPP Server SHOULD reject
the request with the appropriate error code, 2106.
In keeping with the Document Literal Wrapped design approach
described in the introductory sections, the WSDL declaration of the
Cartwright, et al. Expires January 15, 2009 [Page 55]
Internet-Draft ESPP Protocol July 2008
operation is as follows:
<wsdl:operation name="addRNs">
<wsdl:input message="addRNsRqstMsg"/>
<wsdl:output message="cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:message name="addRNsRqstMsg">
<wsdl:part name="rqst" element="est:addRNsRqst"/>
</wsdl:message>
<wsdl:message name="cmnRspnsMsg">
<wsdl:part name="rspns" element="est:cmnRspns"/>
</wsdl:message>
Inputs to the operation are wrapped in the addRNsRqst object, which
is declared as follows:
<element name="addRNsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="rn" type="est:RNType" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
As with all update operations, the basicRqst data element is a
required input. Refer to the Section 4.4.1 General Protocol Concepts
for a detailed description of this data element. Also required is
one or more RNType objects. Any limitation on the maximum number of
RNs that may be passed into a call to the addRNs operation is a
policy decision and is not limited by the protocol.
The RN object structure is declared as follows:
Cartwright, et al. Expires January 15, 2009 [Page 56]
Internet-Draft ESPP Protocol July 2008
<complexType name="RNType">
<sequence>
<element name="oid" type="est:OIdType"/>
<element name="eid" type="est:EIdType"/>
<element name="rn" type="string"/>
<element name="dgId" type="est:OIdType"/>
<element name="ext" type="est:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
RNType is comprised of the following data elements:
o oid: Exactly one object ID that provides the identity of the
object. This identifier is also an input to the delRNs, getRNs
operations to identify a given RN
o eid: Exactly one enterprise ID that uniquely identifies the
operational entity within the call routing community that is
responsible for or "owns" this object
o RN: One local routing number
o dgId: Exactly one object ID that identifies the Destination
Group in which this RN resides. The Destination Group's
relationship to one or more Routes can then define the RNs
peering points. The ESPP Server MUST reject, with the
appropriate error response code, an attempt to create an RN
object containing a Destination Group ID that does not exist
within the appropriate context of the addressing server
o Ext: Point of extensibility described in Section 4.4.1.9 of this
document
Table 12 defines the result codes and messages that the addRNs
operation SHOULD return.
Cartwright, et al. Expires January 15, 2009 [Page 57]
Internet-Draft ESPP Protocol July 2008
+--------+----------------------------------------------------------+
| Result | Text |
| Code | |
+--------+----------------------------------------------------------+
| 1000 | Request Succeeded. |
| | |
| 2001 | Request syntax invalid. |
| | |
| 2002 | Request too large. |
| | |
| 2003 | Version not supported. |
| | |
| 2301 | System temporarily unavailable. |
| | |
| 2103 | Transaction ID out of sequence: [transaction ID |
| | received]:[ transaction ID expected]. |
| | |
| 2104 | Attribute value invalid: [attribute name]:[attribute |
| | value]:[objectType-objectId]. |
| | |
| 2105 | Object does not exist: [attribute name]:[ |
| | objectType-objectId]. |
| | |
| 2106 | Object status or ownership does not allow for request: |
| | [request name]:[ attributeName]:[objectType-objectId]. |
+--------+----------------------------------------------------------+
Table 12: addRNs Operation Result Codes and Messages
4.4.2.6. Operation Name: addTNRs
As described in the introductory sections, a TNRType is a range of
telephone numbers which are provisioned as a group, reducing the
number of objects that must be independently provisioned and managed.
This object contains the indirect relationship to a set of peering
point NAPTRs (via a Destination Group ID). The addTNRs operation
creates or overwrites one or more TNR objects in the addressing
server. If a TNR object with the same object ID does not exist
within the context of the addressing server, then the ESPP Server
MUST create the TNR object. If such an object does exist within the
context of the addressing server, then the ESPP Server MUST replace
the current properties of that object with the values passed into the
addTNRanges operation. If a TNRange with the given ID does exist,
but was created by a client other than the one calling the addTNRs
operation then the ESPP Server SHOULD reject the request with the
appropriate error code, 2106.
In keeping with the Document Literal Wrapped design approach
Cartwright, et al. Expires January 15, 2009 [Page 58]
Internet-Draft ESPP Protocol July 2008
described in the introductory sections, the WSDL declaration of the
operation is as follows:
<wsdl:operation name="addTNRs">
<wsdl:input message="esp:addTNRsRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:message name="addTNRsRqstMsg">
<wsdl:part name="rqst" element="est:addTNRsRqst"/>
</wsdl:message>
<wsdl:message name="cmnRspnsMsg">
<wsdl:part name="rspns" element="est:cmnRspns"/>
</wsdl:message>
Inputs to the operation are wrapped in the addTNRsRqst object, which
is declared as follows:
<element name="addTNRsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="tnR" type="est:TNRType" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
As with all update operations, the basicRqst data element is a
required input. Refer to the Section 4.4.1, General Protocol
Concepts, for a detailed description of this data element. Also
required is one or more TNRType objects. Any limitation on the
maximum number of TNRs that may be passed into a call to the
operation is a policy decision and is not limited by the protocol.
The TNRType object structure is declared as follows:
Cartwright, et al. Expires January 15, 2009 [Page 59]
Internet-Draft ESPP Protocol July 2008
<complexType name="TNRType">
<sequence>
<element name="oid" type="est:OIdType"/>
<element name="eid" type="est:EIdType"/>
<element name="tnRStrt" type="string"/>
<element name="tnREnd" type="string"/>
<element name="dgId" type="est:OIdType"/>
<element name="ext" type="est:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
TNRType is comprised of the following data elements:
o oId: Exactly one object ID that provides the identity of the
object.
o Eid: Exactly one enterprise ID that uniquely identifies the
operational entity within the call routing community that is
responsible for or "owns" this object.
o TNRStrt: A required element that represents either the telephone
number being added or the first telephone number in a continuous
range of telephone numbers being added.
o TNREnd: An optional element that represents the last telephone
number in a continuous range of telephone numbers being added.
The ESPP Server MUST validate that the range is a valid range of
continuous numbers (e.g., that the tnREnd is greater than the
tnRStrt). If not, then the ESPP Server MUST return the
appropriate error code to the ESPP Client.
o dgId: Exactly one object ID that identifies the Destination
Group this TN Range object instance resides within. The
Destination Group's relationship to one or more Routes can then
define the telephone numbers' peering points. The ESPP Server
MUST reject, with the appropriate error response code, an
attempt to create a TNR object containing a Destination Group ID
that does not exist within the appropriate context of the
addressing server.
o Ext: Point of extensibility described in Section 4.4.1.9 of this
document.
Table 13 defines the result codes and messages that the addTNRs
operation SHOULD return
Cartwright, et al. Expires January 15, 2009 [Page 60]
Internet-Draft ESPP Protocol July 2008
+--------+----------------------------------------------------------+
| Result | Text |
| Code | |
+--------+----------------------------------------------------------+
| 1000 | Request Succeeded. |
| | |
| 2001 | Request syntax invalid. |
| | |
| 2002 | Request too large. |
| | |
| 2003 | Version not supported. |
| | |
| 2301 | System temporarily unavailable. |
| | |
| 2103 | Transaction ID out of sequence: [transaction ID |
| | received]:[ transaction ID expected]. |
| | |
| 2104 | Attribute value invalid: [attribute name]:[attribute |
| | value]:[objectType-objectId]. |
| | |
| 2105 | Object does not exist: [attribute name]:[ |
| | objectType-objectId]. |
| | |
| 2106 | Object status or ownership does not allow for request: |
| | [request name]:[ attributeName]:[objectType-objectId]. |
+--------+----------------------------------------------------------+
Table 13: addTNRs Operation Result Codes and Messages
4.4.2.7. Operation Name: addNAPTRs
As described in the introductory sections, a NAPTR object represents
a peering point for routing and/or other data. NAPTRs are associated
to Routes and TNs. The addNAPTRs operation creates or overwrites one
or more NAPTR objects in the addressing server. If a NAPTR object
with the same object ID does not exist within the context of the
addressing server, then the ESPP Server MUST create the NAPTR object.
If a NAPTR object with the same object ID does exist within the
context of the addressing server, then the ESPP Server MUST replace
the current properties of that NAPTR with the properties passed into
the addNAPTRs operation. If a NAPTR with the given ID does exist,
but was created by a client other than the one calling the addNAPTRs
operation then the ESPP Server SHOULD reject the request with the
appropriate error code, 2106.
In keeping with the Document Literal Wrapped design approach
described in the introductory sections, the WSDL declaration of the
operation is as follows:
Cartwright, et al. Expires January 15, 2009 [Page 61]
Internet-Draft ESPP Protocol July 2008
<wsdl:operation name="addNAPTRs">
<wsdl:input message="addNAPTRsRqstMsg"/>
<wsdl:output message="cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:message name="addNAPTRsRqstMsg">
<wsdl:part name="rqst" element="est:addNAPTRsRqst"/>
</wsdl:message>
<wsdl:message name="cmnRspnsMsg">
<wsdl:part name="rspns" element="est:cmnRspns"/>
</wsdl:message>
Inputs to the operation are wrapped in the addNAPTRsRqst object,
which is declared as follows:
<element name="addNAPTRsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="naptr" type="est:NAPTRType" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
As with all update operations, the basicRqst data element is a
required input. Refer to the Section 4.4.1 General Protocol Concepts
for a detailed description of this data element. Also required is
one or more NAPTRType objects. Any limitation on the maximum number
of NAPTRs that may be passed into a call to the addNAPTRs operation
is a policy decision and is not limited by the protocol.
A NAPTR object is declared as follows:
<complexType name="NAPTRType">
<sequence>
<element name="oid" type="est:OIdType"/>
<element name="eid" type="est:EIdType"/>
<element name="order" type="unsignedShort"/>
<element name="pref" type="unsignedShort"/>
<element name="flags" type="string" minOccurs="0"/>
<element name="svcs" type="string"/>
<element name="regx" type="string" minOccurs="0"/>
<element name="repl" type="string" minOccurs="0"/>
<element name="ext" type="est:ExtAnyType" minOccurs="0"/>
</sequence>
Cartwright, et al. Expires January 15, 2009 [Page 62]
Internet-Draft ESPP Protocol July 2008
</complexType>
The NAPTRType object is comprised of the data elements that are
necessary for a NAPTR that represents a peering port within the
Route. Each data element is described as follows:
o oId: Exactly one object ID to uniquely identify the object
instance. This identifier is also an input to the delNAPTRs,
getNAPTRs, and addRtes operations to identify a given NAPTR.
o Eid: Exactly one enterprise ID that uniquely identifies the
operational entity within the call routing community that is
responsible for or "owns" this object.
o Order: Relative order value in an ENUM NAPTR.
o Pref: Relative preference value in an ENUM NAPTR.
o Svcs: ENUM service(s) that are served by the SBE. This field's
value must be of the form specified in RFC 3761 (e.g., E2U+
pstn:sip+sip). The allowable values are a matter of policy and
not limited by this protocol.
o Regex: NAPTR's regular expression field. If this is not
included then the Repl field must be included.
o Repl: NAPTR replacement field, should only be provided if the
Regex field is not provided, otherwise it will be ignored by the
addressing server.
o Ext: Point of extensibility described in Section 4.4.1.9 of this
document.
Table 14 defines the result codes and messages that the addNAPTRs
operation SHOULD return.
Cartwright, et al. Expires January 15, 2009 [Page 63]
Internet-Draft ESPP Protocol July 2008
+--------+----------------------------------------------------------+
| Result | Text |
| Code | |
+--------+----------------------------------------------------------+
| 1000 | Request Succeeded. |
| | |
| 2001 | Request syntax invalid. |
| | |
| 2002 | Request too large. |
| | |
| 2003 | Version not supported. |
| | |
| 2301 | System temporarily unavailable. |
| | |
| 2103 | Transaction ID out of sequence: [transaction ID |
| | received]:[ transaction ID expected]. |
| | |
| 2104 | Attribute value invalid: [attribute name]:[attribute |
| | value]:[objectType-objectId]. |
| | |
| 2106 | Object status or ownership does not allow for request: |
| | [request name]:[ attributeName]:[objectType-objectId]. |
+--------+----------------------------------------------------------+
Table 14: addNAPTRs Operation Result Codes and Messages
4.4.2.8. Operation Name: addEgrRtes
As described in the introductory sections, an Egress Route houses a
rule that can be used for re-writing (modifying) the regular
expressions housed in the NAPTRs associated with a Route object. The
addEgrRtes operation creates or overwrites one or more Egress Route
objects in the addressing server. If an Egress Route object with the
same object ID does not exist within the context of the addressing
server, then the ESPP Server MUST create the Egress route object. If
an Egress Route object with the same object ID does exist within the
context of the addressing server, then the ESPP Server MUST replace
the current properties of that Egress Route with the properties
passed into the addEgrRtes operation. If an Egress Routes with the
given ID does exist, but was created by a client other than the one
calling the addEgrRtes operation then the ESPP Server SHOULD reject
the request with the appropriate error code, 2106.
In keeping with the Document Literal Wrapped design approach
described in the introductory sections, the WSDL declaration of the
operation is as follows:
Cartwright, et al. Expires January 15, 2009 [Page 64]
Internet-Draft ESPP Protocol July 2008
<wsdl:operation name="addEgrRtes">
<wsdl:input message="addEgrRtesRqstMsg"/>
<wsdl:output message="cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:message name="addEgrRtesRqstMsg">
<wsdl:part name="rqst" element="est:addEgrRtesRqst"/>
</wsdl:message>
<wsdl:message name="cmnRspnsMsg">
<wsdl:part name="rspns" element="est:cmnRspns"/>
</wsdl:message>
Inputs to the operation are wrapped in the addEgrRtesRqst object,
which is declared as follows:
<element name="addEgrRtesRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="egrRte" type="est:EgrRteType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
As with all update operations, the basicRqst data element is a
required input. Refer to the Section 4.4.1 General Protocol Concepts
for a detailed description of this data element. Also required is
one or more EgrRteType objects. Any limitation on the maximum number
of Egress Routes that may be passed into a call to the addEgrRtes
operation is a policy decision and is not limited by the protocol.
An Egress Route object is declared as follows:
Cartwright, et al. Expires January 15, 2009 [Page 65]
Internet-Draft ESPP Protocol July 2008
<complexType name="EgrRteType">
<sequence>
<element name="oid" type="est:OIdType"/>
<element name="eid" type="est:EIdType"/>
<element name="rteId" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="pref" type="unsignedShort"/>
<element name="svcs" type="string" minOccurs="0"/>
<element name="regxRewriteRule" type="string"/>
<element name="ext" type="est:ExtAnyType"
minOccurs="0"/>
</sequence>
</complexType>
The EgrRteType object is comprised of the data elements that are
necessary to for a an Egress Route. Each data element is described
as follows:
o oId: Exactly one object ID to uniquely identify the object
instance. This identifier is also an input to the delEgrRtes
and getEgrRtes operations to identify a given Egress Route.
o Eid: Exactly one enterprise ID that uniquely identifies the
operational entity within the call routing community that is
responsible for or "own" this object.
o Order: Relative order value in an ENUM NAPTR.
o RteId: Zero or more Routes to which this Egress Route applies.
The ESPP Server MUST reject, with the appropriate error response
code, an attempt to create an Egress Route object containing a
Route ID that does not exist within the appropriate context of
the addressing server.
o Pref: Relative preference value of the Egress Route with respect
to other Egress Routes associated with the same Route object.
o Svcs: ENUM service(s) to which this Egress Route's
regxRewriteRule should be applied. This field's value must be
of the form specified in RFC 3761 (e.g., E2U+pstn:sip+sip).
o RegexRewriteRule: A regular expression that is applied to the
Regx field of a NAPTR.
o Ext: Point of extensibility described in Section 4.4.1.9 of this
document.
Cartwright, et al. Expires January 15, 2009 [Page 66]
Internet-Draft ESPP Protocol July 2008
Table 15 defines the result codes and messages that the addEgrRtes
operation SHOULD return.
+--------+----------------------------------------------------------+
| Result | Text |
| Code | |
+--------+----------------------------------------------------------+
| 1000 | Request Succeeded. |
| | |
| 2001 | Request syntax invalid. |
| | |
| 2002 | Request too large. |
| | |
| 2003 | Version not supported. |
| | |
| 2301 | System temporarily unavailable. |
| | |
| 2103 | Transaction ID out of sequence: [transaction ID |
| | received]:[ transaction ID expected]. |
| | |
| 2104 | Attribute value invalid: [attribute name]:[attribute |
| | value]:[objectType-objectId]. |
| | |
| 2105 | Object does not exist: [attribute name]:[ |
| | objectType-objectId]. |
| | |
| 2106 | Object status or ownership does not allow for request: |
| | [request name]:[ attributeName]:[objectType-objectId]. |
+--------+----------------------------------------------------------+
Table 15: addEgrRtes Operation Result Codes and Messages
4.4.2.9. Delete Operations
This sub-section defines the delete operations (i.e. delRtes,
delDestGroups, delPubIds, delPvtIds, delTNRs, delRNs, delNAPTRs,
delEgrRtes). All delete operations are of the same design and the
delRtes operation is used here for illustration. The delete
operations delete one or more existing objects from the addressing
server. If an object of the indicated type with the given ID exists,
then the operation must delete that object. If such an object does
not exist, then the ESPP Server MUST return the appropriate error
response code. If an object with the given ID does exist, but was
created by a client other than the one calling the delete operation
then the ESPP Server SHOULD reject the request with the appropriate
error code, 2106. The delete operations delete one or more existing
objects from an addressing server. If all the indicated objects,
with the given ID(s) exist, then the ESPP Server MUST delete those
Cartwright, et al. Expires January 15, 2009 [Page 67]
Internet-Draft ESPP Protocol July 2008
objects and return a response code of 1000. If one or more of the
objects do not exist then the ESPP Server MUST return a response code
of 1001, i.e., the ESPP Server will not regard this as an error
condition. If the ESPP server returns a response code of 1001 the
ESPP server SHOULD log the objectIDs of non-existent objects that
were requested to be deleted and the ESPP Client that requested the
deletion. If one or more of the objects with the given IDs does
exist but was created by a client other than the one calling the
delete operation then the ESPP Server SHOULD reject the request with
an error code of 2106.
In keeping with the Document Literal Wrapped design approach
described in the introductory sections, the WSDL declaration of the
operation is as:
<wsdl:operation name="delRtes">
<wsdl:input message="delRtesRqstMsg"/>
<wsdl:output message="cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:message name="delRtesRqstMsg">
<wsdl:part name="rqst" element="est:delRtesRqst"/>
</wsdl:message>
Inputs to the operation are wrapped in the delRtesRqst object, which
is declared as follows:
<element name="delRtesRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:
BasicRqstType"/>
<element name="oid" type="est:OIdType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
As with all update operations, the basicRqst data element is a
required input. Refer to the Section 4.4.1 General Protocol Concepts
for a detailed description of this data element. Also required is
one or more object IDs that identify the objects that the addressing
Cartwright, et al. Expires January 15, 2009 [Page 68]
Internet-Draft ESPP Protocol July 2008
server is to delete. Any limitation on the maximum number object IDs
that may be passed into this operation is a policy decision and not
limited by the protocol. It is the responsibility of the ESPP Server
to maintain referential integrity when an object is deleted. The
following rules apply to the delete operations:
It is the responsibility of the ESPP Server to maintain referential
integrity when an object is deleted. The following rules apply to
the delete operations:
o With the exception of cascading Destination Group deletions
described below, an ESPP Server SHOULD NOT allow an object created
by a client having a given client ID to be deleted by a client
having a different client ID.
o The ESPP Server MUST delete all RNs and TNRanges within a
Destination Group that is being deleted, even if those RNs or
TNRanges were created by another ESPP client ID. The ESPP Server
MUST delete all Public Identity instances within a Destination
Group, but only if a Public Identity instance is not directly
associated with one or more NAPTR objects. As with RNs and
TNRanges, Destination Groups and Public Identities MUST be deleted
even if they were created by another ESPP client ID.
o When an object is deleted within an ESPP Server, the ESPP Server
must automatically remove any references to that object that may
exist within objects created by any client IDs within that ESPP
Server. For example, if a Route object "ABC" that was created by
Client ID "123" is referred to by Egress Route "GHI" that was
created by client ID "678", then when Route "ABC" is deleted by
client "123" the ESPP Server MUST also automatically remove the
reference to Route "ABC" from Egress Route "GHI", or any other
Egress Routes. This rule applies to the relationships between
Routes and Destination Groups, Egress Routes and Routes, Routes
and NAPTRs, Public Identities and Private Identities, and Public
Identities and NAPTRs.
Table 16 defines the result codes and messages that these delete
operations SHOULD return.
Cartwright, et al. Expires January 15, 2009 [Page 69]
Internet-Draft ESPP Protocol July 2008
+--------+----------------------------------------------------------+
| Result | Text |
| Code | |
+--------+----------------------------------------------------------+
| 1000 | Request Succeeded. |
| | |
| 1001 | Request Succeeded. Deleted object(s) did not exist. |
| | |
| 2001 | Request syntax invalid. |
| | |
| 2002 | Request too large. |
| | |
| 2003 | Version not supported. |
| | |
| 2301 | System temporarily unavailable. |
| | |
| 2103 | Transaction ID out of sequence: [transaction ID |
| | received]:[ transaction ID expected]. |
| | |
| 2104 | Attribute value invalid: [attribute name]:[attribute |
| | value]:[objectType-objectId]. |
| | |
| 2105 | Object does not exist: [attribute name]:[ |
| | objectType-objectId]. |
| | |
| 2106 | Object status or ownership does not allow for request: |
| | [request name]:[ attributeName]:[objectType-objectId]. |
+--------+----------------------------------------------------------+
Table 16: delRtes, delDestGroups, delPubIds, delPvtIds, delTNRs,
delRNs, delNAPTRs, delEgrRtes Operation Result Codes and Messages
4.4.2.10. Get Operations
This sub-section defines the get, or query, operations (i.e. getRtes,
getDestGroups, getPubIds, getPvtIds, getTNRs, getRNs, getNAPTRs,
getEgrRtes). All get operations are of the same design and the
getRtes operation is used here for illustration. If an object of the
indicated type with the given ID exists, then the ESPP Server MUST
return that object. If such an object does not exist, the ESPP
Server MUST NOT return an object. An empty result set MUST NOT
result in an error code response.
In keeping with the Document Literal Wrapped design approach
described in the introductory sections, the WSDL declaration of the
getRtes operation is as follows:
Cartwright, et al. Expires January 15, 2009 [Page 70]
Internet-Draft ESPP Protocol July 2008
<wsdl:operation name="getRtes">
<wsdl:input message="getRtesRqstMsg"/>
<wsdl:output message="getRtesRspnsMsg"/>
</wsdl:operation>
<wsdl:message name="getRtesRqstMsg">
<wsdl:part name="rqst" element="est:getRtesRqst"/>
</wsdl:message>
<wsdl:message name="getRtesRspnsMsg">
<wsdl:part name="rspns" element="est:getRtesRspns"/>
</wsdl:message>
Inputs to the operation are wrapped in the getRtesRqst object, which
is declared as follows:
<element name="getRtesRqst">
<complexType>
<sequence>
<element name="basicRqst"
type="est:BasicQueryType"/>
<element name="oid" type="est:OIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="eid" type="est:EIdType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<complexType name="BasicQueryType">
<sequence>
<element name="clientId" type="est:ClientIdType"/>
<element name="minorVer" type="est:VerType"/>
<element name="ext" type="est:ExtAnyType"
minOccurs="0"/>
</sequence>
</complexType>
The required input is one BasicQueryType object and one or more
object IDs that the addressing server is to return and/or one or more
enterprise IDs for which the addressing server should return all
Cartwright, et al. Expires January 15, 2009 [Page 71]
Internet-Draft ESPP Protocol July 2008
objects of the given type. The list of object IDs and enterprise IDs
MUST be considered "or" criteria, find objects of the given type that
have these object IDs or that belong to the given enterprise IDs.
Stated another way, the addressing server is to return the objects
that have any of the given object IDs and return the objects that
have any of the given enterprise IDs. Any limitation on the maximum
number of objects that may be passed into or returned by this
operation is a policy decision and not limited by the protocol.
Notice that the get operations are the only operations that do not
accept a BasicRqstType object as input. Rather, a BasicQueryType
object is required. This results from the fact that passing a
transaction ID into a get operation is not necessary and would be
inefficient. The BasicQueryType object only contains the mandatory
version identifier and the optional extensibility element.
Results of the operation are wrapped in the getRtesRspns object,
which is declared as follows:
<element name="getRtesRspns">
<complexType>
<sequence>
<element name="rte" type="est:RteType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="basicResult" type="est:
BasicRspnsType"/>
</sequence>
</complexType>
</element>
The response includes the standard BasicRspnsType object and zero or
more RteType objects, one for each object ID that matches a Route in
the addressing server.
Table 17 defines the result codes and messages that these get
operations SHOULD return.
Cartwright, et al. Expires January 15, 2009 [Page 72]
Internet-Draft ESPP Protocol July 2008
+--------+----------------------------------------------------------+
| Result | Text |
| Code | |
+--------+----------------------------------------------------------+
| 1000 | Request Succeeded. |
| | |
| 2001 | Request syntax invalid. |
| | |
| 2002 | Request too large. |
| | |
| 2003 | Version not supported. |
| | |
| 2301 | System temporarily unavailable. |
| | |
| 2104 | Attribute value invalid: [attribute name]:[attribute |
| | value]:[objectType-objectId]. |
+--------+----------------------------------------------------------+
Table 17: getRtes, getDestGroups, getPubIds, getPvtIds, getTNRs,
getRNs, getNAPTRs, getEgrRtes Operation Result Codes and Messages
4.4.2.11. Operation Name: addEntr
Prior to attempting to add an object under a given an enterprise ID
to an ESPP Server, the ESPP Client MUST create that enterprise ID in
that ESPP Server using the addEntr operation.
The addEntr operation creates an enterprise ID in the addressing
server. If an enterprise ID value of an addEntr operation does not
exist, the ESPP Server MUST create the enterprise ID. If an
enterprise ID value of an addEntr operation already exists, the ESPP
Server MUST return a success response.
In keeping with the Document Literal Wrapped design approach
described in the introductory sections, the WSDL declaration of the
operation is as follows:
<wsdl:operation name="addEntr">
<wsdl:input message="esp:addEntrRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:message name="addEntrRqstMsg">
<wsdl:part name="rqst" element="est:addEntrRqst"/>
</wsdl:message>
Cartwright, et al. Expires January 15, 2009 [Page 73]
Internet-Draft ESPP Protocol July 2008
Inputs to the operation are wrapped in the addEntrRqst object, which
is declared as follows:
<element name="addEntrRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:
BasicRqstType"/>
<element name="eId" type="est:EIdType"/>
</sequence>
</complexType>
</element>
As with all update operations, the basicRqst data element is a
required input. Refer to Section 4.4.1, for a detailed description
of this data element. Also required is one enterprise ID.
Table 18 defines the result codes and messages that the addEntr
operation SHOULD return.
+--------+----------------------------------------------------------+
| Result | Text |
| Code | |
+--------+----------------------------------------------------------+
| 1000 | Request Succeeded. |
| | |
| 2001 | Request syntax invalid. |
| | |
| 2002 | Request too large. |
| | |
| 2003 | Version not supported. |
| | |
| 2301 | System temporarily unavailable. |
| | |
| 2103 | Transaction ID out of sequence: [transaction ID |
| | received]:[ transaction ID expected]. |
| | |
| 2104 | Attribute value invalid: [attribute name]:[attribute |
| | value]:[objectType-objectId]. |
+--------+----------------------------------------------------------+
Table 18: addEntr Operation Result Codes and Messages
Cartwright, et al. Expires January 15, 2009 [Page 74]
Internet-Draft ESPP Protocol July 2008
4.4.2.12. Operation Name: modEntr
Modification of an enterprise ID by one ESPP Client must not impact
objects created by another ESPP Client. In other words only objects
created by the client modifying the enterprise ID MUST be moved to
the new enterprise ID as part of processing the modEntr operation.
Any objects created by a different ESPP Client must remain in their
existing enterprise ID.
The modEntr operation modifies an existing enterprise ID in the
addressing server. If the "old" enterprise ID being modified does
exist then the ESPP Server MUST replace the current enterprise ID
with the "new" enterprise ID. If the "old" enterprise ID does not
exist then the ESPP Server MUST return the appropriate error code.
In keeping with the Document Literal Wrapped design approach
described in the introductory sections, the WSDL declaration of the
operation is as follows:
<wsdl:operation name="modEntr">
<wsdl:input message="esp:modEntrRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:message name="modEntrRqstMsg">
<wsdl:part name="rqst" element="est:modEntrRqst"/>
</wsdl:message>
Inputs to the operation are wrapped in the modEntrRqst object, which
is declared as follows:
<element name="modEntrRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:
BasicRqstType"/>
<element name="newEId" type="est:EIdType"/>
<element name="oldEId" type="est:EIdType"/>
</sequence>
</complexType>
</element>
Cartwright, et al. Expires January 15, 2009 [Page 75]
Internet-Draft ESPP Protocol July 2008
As with all update operations, the basicRqst data element is a
required input. Refer to Section 4.4.1, for a detailed description
of this data element. Also required is one "new" enterprise ID and
one "old" enterprise ID.
Table 19 defines the result codes and messages that the modEntr
operation SHOULD return.
+--------+----------------------------------------------------------+
| Result | Text |
| Code | |
+--------+----------------------------------------------------------+
| 1000 | Request Succeeded. |
| | |
| 2001 | Request syntax invalid. |
| | |
| 2002 | Request too large. |
| | |
| 2003 | Version not supported. |
| | |
| 2301 | System temporarily unavailable. |
| | |
| 2103 | Transaction ID out of sequence: [transaction ID |
| | received]:[ transaction ID expected]. |
| | |
| 2104 | Attribute value invalid: [attribute name]:[attribute |
| | value]:[objectType-objectId]. |
+--------+----------------------------------------------------------+
Table 19: modEntr Operation Result Codes and Messages
4.4.2.13. Operation Name: delEntr
The delEntr operation deletes the enterprise ID and all objects from
an addressing server that have the given enterprise ID and that were
created by the client that is deleting the enterprise ID. If the
enterprise ID does not exist in the addressing server, then the ESPP
Server MUST return the response code 1001, i.e., the ESPP Server will
not regard this as an error condition. If the ESPP server returns a
response code of 1001 the ESPP server SHOULD log the non-existent
enterpriseID and the ESPP Client that requested the deletion. If the
enterprise ID did exist and the operation was successful then the
ESPP Server MUST return the response code 1000.
Deletion of an enterprise ID by one ESPP Client MUST NOT impact
objects created by another ESPP Client. In other words only objects
created by the client deleting the enterprise ID MUST be deleted.
Any objects created by a different ESPP Client MUST NOT be deleted
Cartwright, et al. Expires January 15, 2009 [Page 76]
Internet-Draft ESPP Protocol July 2008
and MUST remain in their existing enterprise ID.
In keeping with the Document Literal Wrapped design approach
described in the introductory sections, the WSDL declaration of the
operation is as follows:
<wsdl:operation name="delEntr">
<wsdl:input message="delEntrRqstMsg"/>
<wsdl:output message="cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:message name="delEntrRqstMsg">
<wsdl:part name="rqst" element="est:delEntrRqst"/>
</wsdl:message>
Inputs to the operation are wrapped in the delEntrRqst object, which
is declared as follows:
<element name="delEntrRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:
BasicRqstType"/>
<element name="eId" type="est:EIdType"/>
</sequence>
</complexType>
</element>
As with all update operations, the basicRqst data element is a
required input. Refer to Section 4.4.1, for a detailed description
of this data element. Also required is one enterprise ID.
Table 20 defines the result codes and messages that the delEntr
operation SHOULD return.
Cartwright, et al. Expires January 15, 2009 [Page 77]
Internet-Draft ESPP Protocol July 2008
+--------+----------------------------------------------------------+
| Result | Text |
| Code | |
+--------+----------------------------------------------------------+
| 1000 | Request Succeeded. |
| | |
| 1001 | Request Succeeded. Deleted object(s) did not exist. |
| | |
| 2001 | Request syntax invalid. |
| | |
| 2002 | Request too large. |
| | |
| 2003 | Version not supported. |
| | |
| 2301 | System temporarily unavailable. |
| | |
| 2103 | Transaction ID out of sequence: [transaction ID |
| | received]:[ transaction ID expected]. |
| | |
| 2104 | Attribute value invalid: [attribute name]:[attribute |
| | value]:[objectType-objectId]. |
+--------+----------------------------------------------------------+
Table 20: delEntr Operation Result Codes and Messages
4.4.2.14. Operation Name: batchUpdate
The batchUpdate operation is a single operation, with a single
transaction ID that may contain one or more of update actions. This
approach can significantly speed processing time under some
circumstances by effectively allowing multiple operations to be
transmitted and performed under a single transaction ID, and a single
connection.
In keeping with the Document Literal Wrapped design approach
described in the introductory sections, the WSDL declaration of the
operation is as follows:
Cartwright, et al. Expires January 15, 2009 [Page 78]
Internet-Draft ESPP Protocol July 2008
<wsdl:operation name="batchUpdate">
<wsdl:input message="batchUpdateRqstMsg"/>
<wsdl:output message="cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:message name="batchUpdateRqstMsg">
<wsdl:part name="rqst" element="est:batchUpdateRqst"/>
</wsdl:message>
<wsdl:message name="cmnRspnsMsg">
<wsdl:part name="rspns" element="est:cmnRspns"/>
</wsdl:message>
Inputs to the operation are wrapped in the batchUpdateRqst object,
which is declared as follows:
<element name="batchUpdateRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:
BasicRqstType"/>
<element name="batchUpdate" type="est:
BatchUpdateType"/>
</sequence>
</complexType>
</element>
<complexType name="BatchUpdateType">
<sequence>
<element name="op" type="est:BatchOpType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="BatchOpType">
<sequence>
<element name="naptrDel" type="est:OIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="naptrAdd" type="est:NAPTRType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="egrRteDel" type="est:OIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="egrRteAdd" type="est:EgrRteType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="rteDel" type="est:OIdType"
minOccurs="0" maxOccurs="unbounded"/>
Cartwright, et al. Expires January 15, 2009 [Page 79]
Internet-Draft ESPP Protocol July 2008
<element name="rteAdd" type="est:RteType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="saDel" type="est:OIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="saAdd" type="est:DestGroupType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="pviDel" type="est:OIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="pviAdd" type="est:PvtIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="piDel" type="est:OIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="piAdd" type="est:PubIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="tnRDel" type="est:OIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="tnRAdd" type="est:TNRType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="rnDel" type="est:OIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="rnAdd" type="est:RNType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="entrDel" type="est:EIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="entrAdd" type="est:EIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="entrMod" minOccurs="0"
maxOccurs="unbounded">
<complexType>
<sequence>
<element name="newEId"
type="est:EIdType"/>
<element name="oldEId"
type="est:EIdType"/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
The BatchUpdateType object can contain one or more BatchOpType
objects. The structure is nested here to allow multiple
BatchUpdateType objects to be included in any order that is
appropriate to achieve the desired end goal of the batch operation.
More specifically, this structure works around the strict ordering
rules imposed on the XSD "sequence" data structure, allowing adds and
dels to occur in any order. The ESPP Server MUST process the sub-
Cartwright, et al. Expires January 15, 2009 [Page 80]
Internet-Draft ESPP Protocol July 2008
elements of the batchUpdate and the op elements in the order in which
they appear in the batchUpdateRqst element.
The ESPP Server MUST return the appropriate response code when the
operation is successfully completed, i.e., 1000 or 1001. If one or
more of the objects do not exist then the ESPP Server MUST return a
response code of 1001, i.e., the ESPP Server will not regard this as
an error condition. If the ESPP server returns a response code of
1001 the ESPP server SHOULD log the objectIDs of non-existent objects
that were requested to be deleted and the ESPP Client that requested
the deletion.
Upon encountering the first error condition, the ESPP Server MUST
stop processing and return the appropriate error response code,
rolling back any changes that may have been made for the current
request.
As with all update operations, the basicRqst data element is a
required input. Refer to Section 4.4.1, for a detailed description
of this data element. Each of the remaining elements are simply zero
or more instances of the top level data structures that are wrapped
in each of the other update operations described in previous
sections.
Table 21 defines the result codes and messages that the batchUpdate
operation SHOULD return.
Cartwright, et al. Expires January 15, 2009 [Page 81]
Internet-Draft ESPP Protocol July 2008
+--------+----------------------------------------------------------+
| Result | Text |
| Code | |
+--------+----------------------------------------------------------+
| 1000 | Request Succeeded. |
| | |
| 1001 | Request Succeeded. Deleted object(s) did not exist. |
| | |
| 2001 | Request syntax invalid. |
| | |
| 2002 | Request too large. |
| | |
| 2003 | Version not supported. |
| | |
| 2301 | System temporarily unavailable. |
| | |
| 2103 | Transaction ID out of sequence: [transaction ID |
| | received]:[ transaction ID expected]. |
| | |
| 2104 | Attribute value invalid: [attribute name]:[attribute |
| | value]:[objectType-objectId]. |
| | |
| 2105 | Object does not exist: [attribute name]:[ |
| | objectType-objectId]. |
| | |
| 2106 | Object status or ownership does not allow for request: |
| | [request name]:[ attributeName]:[objectType-objectId]. |
+--------+----------------------------------------------------------+
Table 21: batchUpdate Operation Result Codes and Messages
4.4.2.15. Operation Name: getSvcMenu
The getSvcMenu operation returns a list of operations supported by
the ESPP Server and the protocol versions supported by the ESPP
Server. The list of operations is comprised of a list or URNs, one
for each supported operation. This feature can be used by ESPP
Clients to dynamically discover which operations and versions are
supported by the ESPP Servers.
In keeping with the Document Literal Wrapped design approach
described in the introductory sections, the WSDL declaration of the
operation is as follows:
Cartwright, et al. Expires January 15, 2009 [Page 82]
Internet-Draft ESPP Protocol July 2008
<wsdl:operation name="getSvcMenu">
<wsdl:input message="esp:getSvcMenuRqstMsg"/>
<wsdl:output message="esp:getSvcMenuRspnsMsg"/>
</wsdl:operation>
<wsdl:message name="getSvcMenuRqstMsg">
<wsdl:part name="rqst" element="est:getSvcMenuRqst"/>
</wsdl:message>
<wsdl:message name="getSvcMenuRspnsMsg">
<wsdl:part name="rspns" element="est:getSvcMenuRspns"/>
</wsdl:message>
Inputs to the operation are wrapped in the getSvcMenuRqst object,
which is declared as follows:
<element name="getSvcMenuRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:
BasicQueryType"/>
</sequence>
</complexType>
</element>
The required input is one BasicQueryType and the results of the
operation are wrapped in the getRtesRspns object, which is declared
as follows:
Cartwright, et al. Expires January 15, 2009 [Page 83]
Internet-Draft ESPP Protocol July 2008
<element name="getSvcMenuRspns">
<complexType>
<sequence>
<element name="svcMenu" type="est:
SvcMenuType"/>
<element name="basicResult" type="
est:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<complexType name="SvcMenuType">
<sequence>
<element name="majMinVersion" type="string"
maxOccurs="unbounded"/>
<element name="objURI" type="anyURI"
maxOccurs="unbounded"/>
<element name="extURI" type="anyURI"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
The response includes the standard BasicRspnsType object and one
SvcMenyType objects. The SvcMenuType contains the following
elements:
o MajMinVersion: One or more version identifiers in dotted notation,
where each version identifier represents a fully qualified version
identifier that is supported by the ESPP Server.
o ObjUri: One or more URI(s) where each URI identifies one ESPP
operation that is supported by the ESPP Server. URIs take the
following form: urn:example.com:TBD-api-1.0:est:addRtesRqst
o ExtUri: One or more URI(s) where each URI identifies an operation
that is not part of the formal ESPP specification but is supported
by the ESPP Server. This may arise where an ESPP Server has added
non-standard operations to its ESPP implementation.
Table 22 defines the result codes and messages that the getSvcMenu
operation SHOULD return.
Cartwright, et al. Expires January 15, 2009 [Page 84]
Internet-Draft ESPP Protocol July 2008
+--------+----------------------------------------------------------+
| Result | Text |
| Code | |
+--------+----------------------------------------------------------+
| 1000 | Request Succeeded. |
| | |
| 2001 | Request syntax invalid. |
| | |
| 2301 | System temporarily unavailable. |
| | |
| 2104 | Attribute value invalid: [attribute name]:[attribute |
| | value]:[objectType-objectId]. |
+--------+----------------------------------------------------------+
Table 22: getSvcMenu Operation Result Codes and Messages
Cartwright, et al. Expires January 15, 2009 [Page 85]
Internet-Draft ESPP Protocol July 2008
5. File-based ESPP provisioning protocol
To further support the high data distribution requirements of the
target reference architecture, the ESPP specification defines a file
based operational scheme. Some aspects of this scheme are policy
driven and are, therefore, outside the scope of this document. The
file-based provisioning protocol requirements defined in this section
MUST be supported by an ESPP Client and an ESPP Server to claim
compliance with this specification. They must be used in the
following manner to support file base data distribution.
5.1. Overview of the File-based Provisioning Operations
Under certain circumstances, such as bootstrapping a new ENUM-SIP
addressing server with its initial data set, or establishing a new
session peering relationship between two peers, it may be advisable
to distribute peering data in the form of a file. To accomplish
this, the ESPP Client MUST have the ability to, on command, generate
a set of files containing all the session establishment data residing
within the ESPP Client view for a given session peering partner.
Similarly, the ESPP Server MUST support the ability to read, parse,
and load the content of that file into the appropriate context of the
ENUM-SIP addressing server. The process of retrieving that file from
the ESPP Client (acting as a file server) and then delivering the
file to the proper location on the ENUM-SIP addressing server is a
matter of policy and procedure and it is not specified in this
document. The process of suspending real-time provisioning
operations (non-file-based) during this file-based provisioning
process is also a matter of policy and procedure.
5.2. File Structure
An ESPP compliant distribution file MUST be comprised of exactly one
batchUpdateFileRqst element which contains one
BatchUpdateFilePropsType object and one or more BatchUpdateType
objects, which is described in a previous section of this document.
This approach is taken to simplify the implementation effort for this
feature as the ESPP Client and the ESPP Server have the ability to
process the data structures that comprise the batchUpdateFileRqst.
To ensure data consistency, the ESPP Client must generate batch files
using the same transaction identifier sequence as the real time
protocol. It is therefore necessary to disable real-time propagation
while the file-based provisioning process is active.
Cartwright, et al. Expires January 15, 2009 [Page 86]
Internet-Draft ESPP Protocol July 2008
<element name="batchUpdateFileRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="batchUpdateFileProps"
type="est:BatchUpdateFilePropsType"/>
<element name="batchUpdate" type="est:BatchUpdateType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
The BatchUpdateFilePropsType is the file header that specifies some
basic information about where and when the batch update file(s) were
generated. A given batch update may span multiple files, with the
BatchUpdateFilePropsType object in each file.
<complexType name="BatchUpdateFilePropsType">
<sequence>
<element name="clientId" type="est:ClientIdType"/>
<element name="serverId" type="string"/>
<element name="isFullResync" type="boolean"/>
<element name="creationTimestamp" type="dateTime"/>
<element name="sequenceNumber" type="string"/>
<element name="isEndOfSequence" type="boolean"/>
</sequence>
</complexType>
o clientId - The integer that identifies the ESPP Client that
generated the batch file(s).
o serverId - A string that identifies the ESPP Server for which
the batch file(s) were generated.
o isFullResync - Indicates if this sequence of files is a full
refresh of all the data that should reside within an addressing
server. If not, then the file sequence represents an
incremental update. The addressing server MUST properly apply
the data based on the value of this attribute. This may entail
dropping the current data in the addressing server.
o creationTimestamp - The creation timestamp for the batch load
file sequence MUST follow the format defined by the dateTime
datatype of XML Schema Part 2 and MUST contain the time zone
information. For example, a valid format can be represented as
Cartwright, et al. Expires January 15, 2009 [Page 87]
Internet-Draft ESPP Protocol July 2008
YYYY-MM-DDTHH:MM:SS('+'|'-')hh':'mm).
o sequenceNumber - The sequence number for this batch file within
the batch update. An ESPP Client may generate multiple batch
files that, as a set, represent the entire batch update. The
sequenceNumber is a sequential number, starting with 1 and
incremented by 1 for each subsequent file.
o isEndOfSequence - A boolean value indicating whether or not this
is that last file in the sequence of files that comprise the
batch update.
The ESPP Server SHOULD log error codes that correspond to the codes
used in the real time protocol as defined in Section 4.4.1.8.
Cartwright, et al. Expires January 15, 2009 [Page 88]
Internet-Draft ESPP Protocol July 2008
6. Response Codes and Messages
This section contains the consolidated listing of the response codes
and their corresponding messages.
The response code numbering scheme generally adheres to the theory
formalized in section 4.2.1 of [RFC2821]:
o The first digit of the response code can only be 1 or 2: 1 = a
positive result, 2 = a negative result.
o The second digit of the response code indicates the category: 0
= Protocol Syntax, 1 = Implementation Specific Business Rule, 2
= Security, 3 = Server System.
o The third and fourth digits of the response code indicate the
individual message event within the category defines by the
first two digits.
+--------+----------------------------------------------------------+
| Result | Text |
| Code | |
+--------+----------------------------------------------------------+
| 1000 | Request Succeeded. |
| | |
| 1001 | Request Succeeded. Deleted object(s) did not exist. |
| | |
| 2001 | Request syntax invalid. |
| | |
| 2002 | Request too large. |
| | |
| 2003 | Version not supported. |
| | |
| | |
| | |
| 2301 | System temporarily unavailable. |
| | |
| 2103 | Transaction ID out of sequence: [transaction ID |
| | received]:[ transaction ID expected]. |
| | |
| 2104 | Attribute value invalid: [attribute name]:[attribute |
| | value]:[objectType-objectId]. |
| | |
| 2105 | Object does not exist: [attribute name]:[ |
| | objectType-objectId]. |
| | |
| 2106 | Object status or ownership does not allow for request: |
| | [request name]:[ attributeName]:[objectType-objectId]. |
Cartwright, et al. Expires January 15, 2009 [Page 89]
Internet-Draft ESPP Protocol July 2008
| 2301 | Unexpected internal system or server error. |
+--------+----------------------------------------------------------+
Table 23: Response Codes Numbering Scheme and Messages
Some response messages are "parameterized" with one or more of the
following parameters: "attribute name", "attribute value",
"objectType-objectId", and "operation name".
The use of these parameters MUST adhere to the following rules:
o All parameters within a response message are mandatory and MUST
be present. Parameters within a response message MUST NOT be
left empty.
o Any value provided for the "attribute name" parameter MUST be an
exact element name of the protocol data element that the
response message is referring to. For example, allowable values
for "attribute name" are "tnRStrt", "rteName", etc.
o Any value provided for the "request name" parameter MUST be an
exact request object name that the response message is referring
to. For example, an allowable value for "request object name"
is "delRtesRqst".
o The value for "attribute value" MUST be the value of the data
element to which the preceding "attribute name" refers.
o Result codes 2104 and 2105 MUST NOT be used interchangeably.
Response code 2105 SHOULD be returned when the data element(s)
used to uniquely identify a pre-existing object do not exist.
If the data elements used to uniquely identify an object are
malformed, then response code 2104 SHOULD be returned.
o Result code 2104 SHOULD be used whenever an element value does
not adhere to data validation rules. It MUST be used for
circumstances where an optional data element was expected but
not received.
Cartwright, et al. Expires January 15, 2009 [Page 90]
Internet-Draft ESPP Protocol July 2008
7. IANA Considerations
Should there be interest in working on a protocol like ESPP in IETF,
a formal IANA consideration section should be drafted with proper
registrations for the protocol namespace(s), versions, etc.
Cartwright, et al. Expires January 15, 2009 [Page 91]
Internet-Draft ESPP Protocol July 2008
8. Formal API Definition
Note that the formal API definition is currently provided as defined
in the PacketCable specifications for the XML namespace and protocol
versioning conventions.
8.1. WSDL Specification
<wsdl:definitions xmlns:esp="urn:example.com:TBD-api-1.0"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:est="urn:example.com:TBD-types-1.0"
targetNamespace="urn:example.com:TBD-api-1.0">
<wsdl:types>
<xsd:schema targetNamespace="urn:example.com:TBD-api-1.0"
xmlns:esp="urn:example.com:TBD-api-1.0"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
<xsd:import namespace="urn:example.com:TBD-types-1.0"
schemaLocation="ietfespptypes.xsd"/>
</xsd:schema>
</wsdl:types>
<wsdl:message name="addRtesRqstMsg">
<wsdl:part name="rqst" element="est:addRtesRqst"/>
</wsdl:message>
<wsdl:message name="addDestGroupsRqstMsg">
<wsdl:part name="rqst" element="est:addDestGroupsRqst"/>
</wsdl:message>
<wsdl:message name="addPubIdsRqstMsg">
<wsdl:part name="rqst" element="est:addPubIdsRqst"/>
</wsdl:message>
<wsdl:message name="addTNRsRqstMsg">
<wsdl:part name="rqst" element="est:addTNRsRqst"/>
</wsdl:message>
<wsdl:message name="addPvtIdsRqstMsg">
<wsdl:part name="rqst" element="est:addPvtIdsRqst"/>
</wsdl:message>
<wsdl:message name="addRNsRqstMsg">
<wsdl:part name="rqst" element="est:addRNsRqst"/>
</wsdl:message>
<wsdl:message name="addNAPTRsRqstMsg">
<wsdl:part name="rqst" element="est:addNAPTRsRqst"/>
</wsdl:message>
<wsdl:message name="addEgrRtesRqstMsg">
<wsdl:part name="rqst" element="est:addEgrRtesRqst"/>
Cartwright, et al. Expires January 15, 2009 [Page 92]
Internet-Draft ESPP Protocol July 2008
</wsdl:message>
<wsdl:message name="addEntrRqstMsg">
<wsdl:part name="rqst" element="est:addEntrRqst"/>
</wsdl:message>
<wsdl:message name="batchUpdateRqstMsg">
<wsdl:part name="rqst" element="est:batchUpdateRqst"/>
</wsdl:message>
<wsdl:message name="getRtesRqstMsg">
<wsdl:part name="rqst" element="est:getRtesRqst"/>
</wsdl:message>
<wsdl:message name="getDestGroupsRqstMsg">
<wsdl:part name="rqst" element="est:getDestGroupsRqst"/>
</wsdl:message>
<wsdl:message name="getPubIdsRqstMsg">
<wsdl:part name="rqst" element="est:getPubIdsRqst"/>
</wsdl:message>
<wsdl:message name="getTNRsRqstMsg">
<wsdl:part name="rqst" element="est:getTNRsRqst"/>
</wsdl:message>
<wsdl:message name="getPvtIdsRqstMsg">
<wsdl:part name="rqst" element="est:getPvtIdsRqst"/>
</wsdl:message>
<wsdl:message name="getRNsRqstMsg">
<wsdl:part name="rqst" element="est:getRNsRqst"/>
</wsdl:message>
<wsdl:message name="getNAPTRsRqstMsg">
<wsdl:part name="rqst" element="est:getNAPTRsRqst"/>
</wsdl:message>
<wsdl:message name="getEgrRtesRqstMsg">
<wsdl:part name="rqst" element="est:getEgrRtesRqst"/>
</wsdl:message>
<wsdl:message name="getSvcMenuRqstMsg">
<wsdl:part name="rqst" element="est:getSvcMenuRqst"/>
</wsdl:message>
<wsdl:message name="delRtesRqstMsg">
<wsdl:part name="rqst" element="est:delRtesRqst"/>
</wsdl:message>
<wsdl:message name="delDestGroupsRqstMsg">
<wsdl:part name="rqst" element="est:delDestGroupsRqst"/>
</wsdl:message>
<wsdl:message name="delPubIdsRqstMsg">
<wsdl:part name="rqst" element="est:delPubIdsRqst"/>
</wsdl:message>
<wsdl:message name="delTNRsRqstMsg">
<wsdl:part name="rqst" element="est:delTNRsRqst"/>
</wsdl:message>
<wsdl:message name="delPvtIdsRqstMsg">
<wsdl:part name="rqst" element="est:delPvtIdsRqst"/>
Cartwright, et al. Expires January 15, 2009 [Page 93]
Internet-Draft ESPP Protocol July 2008
</wsdl:message>
<wsdl:message name="delRNsRqstMsg">
<wsdl:part name="rqst" element="est:delRNsRqst"/>
</wsdl:message>
<wsdl:message name="delNAPTRsRqstMsg">
<wsdl:part name="rqst" element="est:delNAPTRsRqst"/>
</wsdl:message>
<wsdl:message name="delEgrRtesRqstMsg">
<wsdl:part name="rqst" element="est:delEgrRtesRqst"/>
</wsdl:message>
<wsdl:message name="delEntrRqstMsg">
<wsdl:part name="rqst" element="est:delEntrRqst"/>
</wsdl:message>
<wsdl:message name="modEntrRqstMsg">
<wsdl:part name="rqst" element="est:modEntrRqst"/>
</wsdl:message>
<wsdl:message name="cmnRspnsMsg">
<wsdl:part name="rspns" element="est:cmnRspns"/>
</wsdl:message>
<wsdl:message name="getRtesRspnsMsg">
<wsdl:part name="rspns" element="est:getRtesRspns"/>
</wsdl:message>
<wsdl:message name="getDestGroupsRspnsMsg">
<wsdl:part name="rspns" element="est:getDestGroupsRspns"/>
</wsdl:message>
<wsdl:message name="getPubIdsRspnsMsg">
<wsdl:part name="rspns" element="est:getPubIdsRspns"/>
</wsdl:message>
<wsdl:message name="getTNRsRspnsMsg">
<wsdl:part name="rspns" element="est:getTNRsRspns"/>
</wsdl:message>
<wsdl:message name="getPvtIdsRspnsMsg">
<wsdl:part name="rspns" element="est:getPvtIdsRspns"/>
</wsdl:message>
<wsdl:message name="getRNsRspnsMsg">
<wsdl:part name="rspns" element="est:getRNsRspns"/>
</wsdl:message>
<wsdl:message name="getNAPTRsRspnsMsg">
<wsdl:part name="rspns" element="est:getNAPTRsRspns"/>
</wsdl:message>
<wsdl:message name="getEgrRtesRspnsMsg">
<wsdl:part name="rspns" element="est:getEgrRtesRspns"/>
</wsdl:message>
<wsdl:message name="getSvcMenuRspnsMsg">
<wsdl:part name="rspns" element="est:getSvcMenuRspns"/>
</wsdl:message>
<wsdl:portType name="ESPPPortType">
<wsdl:operation name="addRtes">
Cartwright, et al. Expires January 15, 2009 [Page 94]
Internet-Draft ESPP Protocol July 2008
<wsdl:input message="esp:addRtesRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="delRtes">
<wsdl:input message="esp:delRtesRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="getRtes">
<wsdl:input message="esp:getRtesRqstMsg"/>
<wsdl:output message="esp:getRtesRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="addDestGroups">
<wsdl:input message="esp:addDestGroupsRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="delDestGroups">
<wsdl:input message="esp:delDestGroupsRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="getDestGroups">
<wsdl:input message="esp:getDestGroupsRqstMsg"/>
<wsdl:output message="esp:getDestGroupsRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="addPubIds">
<wsdl:input message="esp:addPubIdsRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="delPubIds">
<wsdl:input message="esp:delPubIdsRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="getPubIds">
<wsdl:input message="esp:getPubIdsRqstMsg"/>
<wsdl:output message="esp:getPubIdsRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="addTNRs">
<wsdl:input message="esp:addTNRsRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="delTNRs">
<wsdl:input message="esp:delTNRsRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="getTNRs">
<wsdl:input message="esp:getTNRsRqstMsg"/>
<wsdl:output message="esp:getTNRsRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="addPvtIds">
Cartwright, et al. Expires January 15, 2009 [Page 95]
Internet-Draft ESPP Protocol July 2008
<wsdl:input message="esp:addPvtIdsRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="delPvtIds">
<wsdl:input message="esp:delPvtIdsRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="getPvtIds">
<wsdl:input message="esp:getPvtIdsRqstMsg"/>
<wsdl:output message="esp:getPvtIdsRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="addRNs">
<wsdl:input message="esp:addRNsRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="delRNs">
<wsdl:input message="esp:delRNsRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="getRNs">
<wsdl:input message="esp:getRNsRqstMsg"/>
<wsdl:output message="esp:getRNsRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="addNAPTRs">
<wsdl:input message="esp:addNAPTRsRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="delNAPTRs">
<wsdl:input message="esp:delNAPTRsRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="getNAPTRs">
<wsdl:input message="esp:getNAPTRsRqstMsg"/>
<wsdl:output message="esp:getNAPTRsRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="addEgrRtes">
<wsdl:input message="esp:addEgrRtesRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="delEgrRtes">
<wsdl:input message="esp:delEgrRtesRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="getEgrRtes">
<wsdl:input message="esp:getEgrRtesRqstMsg"/>
<wsdl:output message="esp:getEgrRtesRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="batchUpdate">
Cartwright, et al. Expires January 15, 2009 [Page 96]
Internet-Draft ESPP Protocol July 2008
<wsdl:input message="esp:batchUpdateRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="addEntr">
<wsdl:input message="esp:addEntrRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="modEntr">
<wsdl:input message="esp:modEntrRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="delEntr">
<wsdl:input message="esp:delEntrRqstMsg"/>
<wsdl:output message="esp:cmnRspnsMsg"/>
</wsdl:operation>
<wsdl:operation name="getSvcMenu">
<wsdl:input message="esp:getSvcMenuRqstMsg"/>
<wsdl:output message="esp:getSvcMenuRspnsMsg"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="ESPPSoapBinding" type="esp:ESPPPortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="addRtes">
<soap:operation soapAction="addRtes" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="delRtes">
<soap:operation soapAction="delRtes" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="getRtes">
<soap:operation soapAction="getRtes" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
Cartwright, et al. Expires January 15, 2009 [Page 97]
Internet-Draft ESPP Protocol July 2008
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="addDestGroups">
<soap:operation soapAction="addDestGroups" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="delDestGroups">
<soap:operation soapAction="delDestGroups" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="getDestGroups">
<soap:operation soapAction="getDestGroups" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="addPubIds">
<soap:operation soapAction="addPubIds" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="delPubIds">
<soap:operation soapAction="delPubIds" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
Cartwright, et al. Expires January 15, 2009 [Page 98]
Internet-Draft ESPP Protocol July 2008
</wsdl:operation>
<wsdl:operation name="getPubIds">
<soap:operation soapAction="getPubIds" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="addTNRs">
<soap:operation soapAction="addTNRs" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="delTNRs">
<soap:operation soapAction="delTNRs" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="getTNRs">
<soap:operation soapAction="getTNRs" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="addPvtIds">
<soap:operation soapAction="addPvtIds" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="delPvtIds">
<soap:operation soapAction="delPvtIds" style="document"/>
Cartwright, et al. Expires January 15, 2009 [Page 99]
Internet-Draft ESPP Protocol July 2008
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="getPvtIds">
<soap:operation soapAction="getPvtIds" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="addRNs">
<soap:operation soapAction="addRNs" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="delRNs">
<soap:operation soapAction="delRNs" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="getRNs">
<soap:operation soapAction="getRNs" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="addNAPTRs">
<soap:operation soapAction="addNAPTRs" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
Cartwright, et al. Expires January 15, 2009 [Page 100]
Internet-Draft ESPP Protocol July 2008
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="delNAPTRs">
<soap:operation soapAction="delNAPTRs" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="getNAPTRs">
<soap:operation soapAction="getNAPTRs" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="addEgrRtes">
<soap:operation soapAction="addEgrRtes" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="delEgrRtes">
<soap:operation soapAction="delEgrRtes" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="getEgrRtes">
<soap:operation soapAction="getEgrRtes" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
Cartwright, et al. Expires January 15, 2009 [Page 101]
Internet-Draft ESPP Protocol July 2008
</wsdl:operation>
<wsdl:operation name="batchUpdate">
<soap:operation soapAction="batchUpdate" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="addEntr">
<soap:operation soapAction="addEntr" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="modEntr">
<soap:operation soapAction="modEntr" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="delEntr">
<soap:operation soapAction="delEntr" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="getSvcMenu">
<soap:operation soapAction="getSvcMenu" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="ESPPService">
Cartwright, et al. Expires January 15, 2009 [Page 102]
Internet-Draft ESPP Protocol July 2008
<wsdl:port name="ESPPPort" binding="esp:ESPPSoapBinding">
<soap:address location="REPLACE_WITH_ACTUAL_URL"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
8.2. XSD Types Specification
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns:est="urn:example.com:TBD-types-1.0"
xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:example.com:TBD-types-1.0"
elementFormDefault="qualified" xml:lang="EN">
<annotation>
<documentation>
-------- Object Type Definitions ----------------
</documentation>
</annotation>
<complexType name="RteType">
<sequence>
<element name="oid" type="est:OIdType"/>
<element name="eid" type="est:EIdType"/>
<element name="rteName" type="string"/>
<element name="sbeNaptrId" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="isInSvc" type="boolean"/>
<element name="ext" type="est:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="DestGroupType">
<sequence>
<element name="oid" type="est:OIdType"/>
<element name="eid" type="est:EIdType"/>
<element name="destGroupName" type="string"/>
<element name="rteId" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="ext" type="est:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="PubIdType">
<sequence>
<element name="oid" type="est:OIdType"/>
<element name="eid" type="est:EIdType"/>
<element name="pubId" type="string"/>
<element name="svcs" type="string"/>
<element name="dgId" type="est:OIdType" minOccurs="0"/>
Cartwright, et al. Expires January 15, 2009 [Page 103]
Internet-Draft ESPP Protocol July 2008
<element name="naptrId" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="pvtId" type="est:OIdType" minOccurs="0"/>
<element name="ext" type="est:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="PvtIdType">
<sequence>
<element name="oid" type="est:OIdType"/>
<element name="eid" type="est:EIdType"/>
<element name="pvtId" type="string"/>
<element name="ext" type="est:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="TNRType">
<sequence>
<element name="oid" type="est:OIdType"/>
<element name="eid" type="est:EIdType"/>
<element name="tnRStrt" type="string"/>
<element name="tnREnd" type="string"/>
<element name="dgId" type="est:OIdType"/>
<element name="ext" type="est:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="RNType">
<sequence>
<element name="oid" type="est:OIdType"/>
<element name="eid" type="est:EIdType"/>
<element name="rn" type="string"/>
<element name="dgId" type="est:OIdType"/>
<element name="ext" type="est:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="NAPTRType">
<sequence>
<element name="oid" type="est:OIdType"/>
<element name="eid" type="est:EIdType"/>
<element name="order" type="unsignedShort"/>
<element name="pref" type="unsignedShort"/>
<element name="flags" type="string" minOccurs="0"/>
<element name="svcs" type="string"/>
<element name="regx" type="string" minOccurs="0"/>
<element name="repl" type="string" minOccurs="0"/>
<element name="ext" type="est:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="EgrRteType">
<sequence>
Cartwright, et al. Expires January 15, 2009 [Page 104]
Internet-Draft ESPP Protocol July 2008
<element name="oid" type="est:OIdType"/>
<element name="eid" type="est:EIdType"/>
<element name="rteId" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="pref" type="unsignedShort"/>
<element name="svcs" type="string" minOccurs="0"/>
<element name="regxRewriteRule" type="string"/>
<element name="ext" type="est:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
<simpleType name="OIdType">
<restriction base="unsignedLong"/>
</simpleType>
<simpleType name="EIdType">
<restriction base="string"/>
</simpleType>
<simpleType name="ClientIdType">
<restriction base="int"/>
</simpleType>
<simpleType name="TransIdType">
<restriction base="unsignedLong"/>
</simpleType>
<simpleType name="VerType">
<restriction base="unsignedLong"/>
</simpleType>
<complexType name="BasicRspnsType">
<sequence>
<element name="resCode" type="int"/>
<element name="resMsg" type="string"/>
<element name="ext" type="est:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="BasicRqstType">
<sequence>
<element name="clientId" type="est:ClientIdType"/>
<element name="transId" type="est:TransIdType"/>
<element name="minorVer" type="est:VerType"/>
<element name="ext" type="est:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="BasicQueryType">
<sequence>
<element name="clientId" type="est:ClientIdType"/>
<element name="minorVer" type="est:VerType"/>
<element name="ext" type="est:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="BatchUpdateType">
Cartwright, et al. Expires January 15, 2009 [Page 105]
Internet-Draft ESPP Protocol July 2008
<sequence>
<element name="op" type="est:BatchOpType" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="BatchOpType">
<sequence>
<element name="naptrDel" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="naptrAdd" type="est:NAPTRType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="egrRteDel" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="egrRteAdd" type="est:EgrRteType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="rteDel" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="rteAdd" type="est:RteType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="saDel" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="saAdd" type="est:DestGroupType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="pviDel" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="pviAdd" type="est:PvtIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="piDel" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="piAdd" type="est:PubIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="tnRDel" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="tnRAdd" type="est:TNRType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="rnToDel" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="rnAdd" type="est:RNType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="entrDel" type="est:EIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="entrAdd" type="est:EIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="entrMod" minOccurs="0" maxOccurs="unbounded">
<complexType>
<sequence>
<element name="newEId" type="est:EIdType"/>
<element name="oldEId" type="est:EIdType"/>
</sequence>
Cartwright, et al. Expires January 15, 2009 [Page 106]
Internet-Draft ESPP Protocol July 2008
</complexType>
</element>
</sequence>
</complexType>
<complexType name="BatchUpdateFilePropsType">
<sequence>
<element name="clientId" type="est:ClientIdType"/>
<element name="serverId" type="string"/>
<element name="isFullResync" type="boolean"/>
<element name="creationTimestamp" type="dateTime"/>
<element name="sequenceNumber" type="unsignedLong"/>
<element name="isEndOfSequence" type="boolean"/>
</sequence>
</complexType>
<complexType name="SvcMenuType">
<sequence>
<element name="majMinVersion"
type="string"
maxOccurs="unbounded"/>
<element name="objURI"
type="anyURI"
maxOccurs="unbounded"/>
<element name="extURI"
type="anyURI"
minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="ExtAnyType">
<sequence>
<any namespace="##other" maxOccurs="unbounded"/>
</sequence>
</complexType>
<annotation>
<documentation>
----------- Wrapped Rqst Message Definitions -----
</documentation>
</annotation>
<element name="addRtesRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="rte" type="est:RteType" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="delRtesRqst">
<complexType>
Cartwright, et al. Expires January 15, 2009 [Page 107]
Internet-Draft ESPP Protocol July 2008
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="oid" type="est:OIdType" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="getRtesRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicQueryType"/>
<element name="oid" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="eid" type="est:EIdType" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="addDestGroupsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="destGroup" type="est:DestGroupType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="delDestGroupsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="oid" type="est:OIdType" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="getDestGroupsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicQueryType"/>
<element name="oid" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="eid" type="est:EIdType" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="addPubIdsRqst">
<complexType>
<sequence>
Cartwright, et al. Expires January 15, 2009 [Page 108]
Internet-Draft ESPP Protocol July 2008
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="pi" type="est:PubIdType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="delPubIdsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="oid" type="est:OIdType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="getPubIdsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicQueryType"/>
<element name="oid" type="est:OIdType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="addPvtIdsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="pvi" type="est:PvtIdType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="delPvtIdsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="oid" type="est:OIdType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="getPvtIdsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicQueryType"/>
<element name="oid" type="est:OIdType"
maxOccurs="unbounded"/>
Cartwright, et al. Expires January 15, 2009 [Page 109]
Internet-Draft ESPP Protocol July 2008
</sequence>
</complexType>
</element>
<element name="addTNRsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="tnR" type="est:TNRType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="delTNRsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="oid" type="est:OIdType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="getTNRsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicQueryType"/>
<element name="oid" type="est:OIdType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="addRNsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="rn" type="est:RNType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="delRNsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="oid" type="est:OIdType" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="getRNsRqst">
Cartwright, et al. Expires January 15, 2009 [Page 110]
Internet-Draft ESPP Protocol July 2008
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicQueryType"/>
<element name="oid" type="est:OIdType" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="addNAPTRsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="naptr"
type="est:NAPTRType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="delNAPTRsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="oid" type="est:OIdType" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="getNAPTRsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicQueryType"/>
<element name="oid" type="est:OIdType" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="addEgrRtesRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="egrRte" type="est:EgrRteType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="delEgrRtesRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="oid" type="est:OIdType" maxOccurs="unbounded"/>
</sequence>
Cartwright, et al. Expires January 15, 2009 [Page 111]
Internet-Draft ESPP Protocol July 2008
</complexType>
</element>
<element name="getEgrRtesRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicQueryType"/>
<element name="oid" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="eid" type="est:EIdType" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="batchUpdateRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="batchUpdate" type="est:BatchUpdateType"/>
</sequence>
</complexType>
</element>
<element name="batchUpdateFileRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="batchUpdateFileProps"
type="est:BatchUpdateFilePropsType"/>
<element name="batchUpdate" type="est:BatchUpdateType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="addEntrRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="eId" type="est:EIdType"/>
</sequence>
</complexType>
</element>
<element name="modEntrRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="newEId" type="est:EIdType"/>
<element name="oldEId" type="est:EIdType"/>
</sequence>
</complexType>
Cartwright, et al. Expires January 15, 2009 [Page 112]
Internet-Draft ESPP Protocol July 2008
</element>
<element name="delEntrRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicRqstType"/>
<element name="eId" type="est:EIdType"/>
</sequence>
</complexType>
</element>
<element name="getSvcMenuRqst">
<complexType>
<sequence>
<element name="basicRqst" type="est:BasicQueryType"/>
</sequence>
</complexType>
</element>
<annotation>
<documentation>
----- Wrapped Rspns Message Definitions ----------------
</documentation>
</annotation>
<element name="getRtesRspns">
<complexType>
<sequence>
<element name="rte" type="est:RteType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="basicResult" type="est:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="getDestGroupsRspns">
<complexType>
<sequence>
<element name="destGroup" type="est:DestGroupType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="basicResult" type="est:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="getPubIdsRspns">
<complexType>
<sequence>
<element name="pi" type="est:PubIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="basicResult" type="est:BasicRspnsType"/>
</sequence>
</complexType>
</element>
Cartwright, et al. Expires January 15, 2009 [Page 113]
Internet-Draft ESPP Protocol July 2008
<element name="getPvtIdsRspns">
<complexType>
<sequence>
<element name="pvi" type="est:PvtIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="basicResult" type="est:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="getTNRsRspns">
<complexType>
<sequence>
<element name="tnR" type="est:TNRType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="basicResult" type="est:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="getRNsRspns">
<complexType>
<sequence>
<element name="rn" type="est:RNType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="basicResult" type="est:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="getNAPTRsRspns">
<complexType>
<sequence>
<element name="naptr" type="est:NAPTRType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="basicResult" type="est:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="getEgrRtesRspns">
<complexType>
<sequence>
<element name="egrRte" type="est:EgrRteType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="basicResult" type="est:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="getSvcMenuRspns">
<complexType>
<sequence>
Cartwright, et al. Expires January 15, 2009 [Page 114]
Internet-Draft ESPP Protocol July 2008
<element name="svcMenu" type="est:SvcMenuType"/>
<element name="basicResult" type="est:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="cmnRspns">
<complexType>
<sequence>
<element name="rspns"
type="est:BasicRspnsType"
nillable="false"/>
</sequence>
</complexType>
</element>
</schema>
Cartwright, et al. Expires January 15, 2009 [Page 115]
Internet-Draft ESPP Protocol July 2008
9. Security Considerations
This document specifies a new provisioning protocol.
Provisioning data and other configuration information in scope of
ESPP include public identities, telephone number ranges, RNs,
signaling path border elements, NAPTRs and Egress Routes. This
information is sensitive and its transmission in the clear and
without integrity checking leaves servers exposed to eavesdropping
attacks. Compliant implementations must therefore satisfy the
requirements defined in Section 4.4.1.3.
If the object values for the Public Identity, Route, Destination
Group, RN, SBE, MAPTRs are set maliciously, it may result in sessions
being misrouted and service disruption. It may also result in an
over-allocation of signaling resources in an attempt to create denial
of service attacks (all routes of all destination groups directed
towards a particular SBE).
Additional security considerations must also apply given the
provisioning data exchanged within and between Trust Domains as
defined in [RFC3325].
An initial set of security requirements that must be met by compliant
ESPP Clients and ESPP Servers is defined in [I-D.espp-requirements].
Cartwright, et al. Expires January 15, 2009 [Page 116]
Internet-Draft ESPP Protocol July 2008
10. Acknowledgments
This document is based on the work of participants in the CableLabs
PacketCable ENUM Server vendor focus team.
The authors wish to thank the following participants for their
contributions and comments:
Jack Burton, Paul Natale, Costas Gavrilidis, Matt Cannon, Ken
Cartwright, Kevin Johns, James Brister, Ted Lemon, Vivian Neou, Mark
McBride, Tim Cody, Sean Leach, Gene Lew, Rich Shockey, Mark Teodoro,
Robby Benedyk, Steve Dimig, , Ajay Gupta, Sean Kent, Tom Kershaw,
Manjul Maharishi, Yasir Saleem, Sanjeev Chauhan, Gaurav Sharma, Vikas
Sarawat, Daryl Malas, Sumanth Channabasappa, Otmar Lendl and Penn
Pfautz.
Cartwright, et al. Expires January 15, 2009 [Page 117]
Internet-Draft ESPP Protocol July 2008
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[SOAP] W3C, "W3C Recommendation, SOAP Version 1.1", May 2000.
[WSDL] W3C, "W3C Recommendation, Web Services Description
Language (WSDL) Version 1.1", March 2001.
[XML] W3C, "W3C Recommendation, Extensible Markup Language (XML)
1.0", August 2006.
11.2. Informative References
[CableLabs-ESPP]
CableLabs, "PacketCable ENUM Server Provisioning
Specification, PKT-SP-ENUM-PROV-I01-080215", CableLabs Spe
cification http://www.cablelabs.com/specifications/
PKT-SP-ENUM-PROV-I01-080215.pdf, February 2008.
[I-D.espp-requirements]
Creighton, T. and J-F. Mule, "ENUM-SIP Server Provisioning
Protocol (ESPP)",
draft-mule-peppermint-espp-requirements-01.txt (work in
progress), July 2008.
[I-D.ietf-speermint-terminology]
Malas, D. and D. Meyer, "SPEERMINT Terminology",
draft-ietf-speermint-terminology-16 (work in progress),
February 2008.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Cartwright, et al. Expires January 15, 2009 [Page 118]
Internet-Draft ESPP Protocol July 2008
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[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.
Cartwright, et al. Expires January 15, 2009 [Page 119]
Internet-Draft ESPP Protocol July 2008
Authors' Addresses
Kenneth Cartwright
VeriSign
21355 Ridgetop Circle
Dulles, VA 20166
USA
Email: kcartwright@verisign.com
Stephen M. Dimig
Tekelec
5200 Paramount Parkway
Morrisville, NC 27560
USA
Email: stephen.dimig@tekelec.com
Mark Teodoro
NeuStar
46000 Center Oak Plaza
Sterling, VA 20166
USA
Email: mark.teodoro@neustar.com
Jean-Francois Mule
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
USA
Email: jfm@cablelabs.com
Cartwright, et al. Expires January 15, 2009 [Page 120]
Internet-Draft ESPP Protocol July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Cartwright, et al. Expires January 15, 2009 [Page 121]