Transcript PPT Version

PSTN – User ENUM –
„Infrastructure ENUM“
An ETSI View
Richard Stastny
IETF60 San Diego
E.164 Numbering in the PSTN
• The E.164 Numbering Plan guaranties that every endpoint can be reached globally from any other end-point
• Therefore the E.164 Numbering Plan has a hierarchical
structure used for routing (and billing)
• Digit analysis in one network provides the route to the
next network, to the area, to the destination office and
to the subscriber line
(e.g. CC - area code - office code - subscriber number)
• Service numbers and number portability have partially
destroyed this simple routing scheme, but only on a
national basis.
• To achieve this, national (non E.164) routing numbers
are used.
• It is therefore NOT possible to route international
calls directly from an origination network to a
destination network.
August 2004
Richard Stastny
2
(User) ENUM
• ENUM is used for routing calls directly from originating
end-points to destination end-points
• To get an entry in ENUM, the E.164 number must
already exist on the PSTN (with some exceptions)
• ENUM is optional, and it is
– opt-in for the calling party and
– opt-in for the called party
• This has originally been defined by
– the Report of the Department of State ITAC-T Advisory
Committee Study Group A Ad Hoc on ENUM (July 6th,
2001) - Section 4.3 and 4.4
• and this definition was taken over by ITU, ETSI and all
national ENUM implementations.
• If a number is not in ENUM, it MUST be routeable via
the PSTN by default.
August 2004
Richard Stastny
3
4.3 Opt-in service for called user.
The assignee of a number must choose to participate in ENUM before
any NAPTR records for the number can be populated. This is
important since records in ENUM are publicly accessible via DNS
query. The opt-in process should be designed to ensure the following:
– Users can control privacy and security of their information.
– The default condition is to not include NAPTR record information.
– Any request for inclusion must be authenticated as being from the assignee
of the E.164 number.
– Inclusion of NAPTR record information must be reversible, allowing the
party to remove the data from the DNS in a timely fashion.
4.4 Opt-in service for calling user and service provider.
The crucial part of Opt-in for the calling user and service provider is
whether or not to query ENUM and then whether or not to make use
of the results.
The following approach is proposed for telephony services:
– No originating party (e.g., a calling user or a service provider) is obligated
to perform an ENUM query to complete a telephone call to an E.164
number.
– A party making an ENUM query, whether a calling user or service provider,
is not obligated to use any of the services in the NAPTR records returned.
– All E.164 numbers must have a Public Switched Telephone Network (PSTN)
point of interface. (For geographic numbers this would be an end office or
tandem.)
August 2004
Richard Stastny
4
What is Infrastructure (ENUM)?
or operator, carrier, provider, …
• It is the usage of ENUM technology:
– within a carrier’s network to find egress points
– and/or between carrier networks to find ingress points
• In the latter case any group (con-federation) of
carriers may decide on any root within a private
or public DNS implementation.
• Infrastructure ENUM is used (in most cases) for
routing calls directly from origination networks
to destination networks.
• Therefore it is considered (at least for a given
number range) as replacement for PSTN based
routing
• Note: this is the ETSI view (ETSI TS 102 055)
August 2004
Richard Stastny
5
Main difference to ENUM
• Since infrastructure ENUM is considered
(at least for a given number range)
as replacement for PSTN based routing, it is
NOT optional:
– it must contain information about ALL numbers in
service within the given number range
– it can therefore NOT be opt-in
– and is must be able to deal with national
specifics related to number portability, e.g.
routing numbers, access to IN-databases, etc.
(see e.g. draft-ietf-iptel-tel-np-02.txt)
August 2004
Richard Stastny
6
One Example
NEXT - Next E.164 eXchange Tree
a shared ENUM tree to faciliate
massive-scale, policy-driven
VoIP-peerings
On behalf of Thilo Salmom
[email protected]
August 2004
Richard Stastny
7
Problem description
• Large numbers of startup VoIPproviders will be entering the
market
• The market as a whole will benefit
from free IP2IP calls
• Numbering information needs to be
exchanged efficiently and policydriven
August 2004
Richard Stastny
8
Proposed solution
• A central ENUM tree holds all
numbering information
• Each VoIP-Provider imports its
numbering information and its peering
policy
• Numbering information will then be
distributed to all connected providers
honoring all posted policies
August 2004
Richard Stastny
9
Technical solution IMPORT
• Peers may enter numbering information
through a web page (work well for few
numbering blocks)
• Peers may keep private ENUM trees
and add the NEXT nameserver as
secondary (works for large amounts of
ported numbers)
August 2004
Richard Stastny
10
Technical solution EXPORT
• Peers may lookup the shared tree
from a previously posted IP
address
• Peers may operate a secondary
nameserver which receives an
individual copy of the shared tree
according to the posted policies
August 2004
Richard Stastny
11
Optional benefits
• NEXT optionally provides anonymity by
replacing the host part of each URI and
forcing calls through a proxy
• NEXT may provide CallerID verification
among peers through mechanisms such
as those proposed for email sender
verification (SPF, ...)
August 2004
Richard Stastny
12
Current Status and Contact
• NEXT is operational and currently in initial
testing
• NEXT holds 2,105,291 numbers located in
875 distinct numbering blocks
(July 31st, 2004)
– at43.at, e-fon.ch, gossiptel, inode.at, magrathea,
musimi.dk, netzquadrat, sipgate, sipphone, telio
• A mailinglist exists at www.e164.info
• Feedback and questions:
Thilo Salmon <[email protected]>
August 2004
Richard Stastny
13
Questions to be answered
in this mini-BoF
Richard Stastny
IETF60 San Diego
Questions to be answered
• Is there a need to provide a common protocol
(and associated infrastructure) on the Internet
to route Internet Real Time Communications
to end-points related to E.164 numbers?
– Remark: we have RFC3761, the question is:
are there separate needs the carriers have?
• If yes, should this protocol and the associated
infrastructure be optional or mandatory
– Remark: mandatory means: is the system selfcontaining to be able to find a route for every
existing E.164 Number?
• What are the security and AA requirements
associated with this?
August 2004
Richard Stastny
15
Questions to be answered (cont)
What are the available technologies that could
satisfy the above requirements?
–
–
–
–
–
DNS (with or without ENUM)
LDAP
SIP
Push based LNP
something else?
depending on the outcome of these questions
we may decide IF and how to proceed
(in IETF and in ENUM WG)
August 2004
Richard Stastny
17