PSTN

1
PSTN User ENUM Infrastructure ENUM

• An ETSI View
• Richard Stastny
• IETF60 San Diego

2
E.164 Numbering in the PSTN

• The E.164 Numbering Plan guaranties that every
  end-point 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.

3
(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.

4

• 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.)

5
What is Infrastructure (ENUM)? or operator,
carrier, provider,

• It is the usage of ENUM technology
• within a carriers 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)

6
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)

7
One ExampleNEXT - Next E.164 eXchange Tree

• a shared ENUM tree to faciliatemassive-scale,
  policy-driven VoIP-peerings
• On behalf of Thilo Salmomsalmon_at_sipgate.de

8
Problem description

• Large numbers of startup VoIP-providers will be
  entering the market
• The market as a whole will benefit from free
  IP2IP calls
• Numbering information needs to be exchanged
  efficiently and policy-driven

9
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

10
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)

11
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

12
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, ...)

13
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
  ltsalmon_at_sipgate.degt

14
Questions to be answered in this mini-BoF

• Richard Stastny
• IETF60 San Diego

15
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 isare
  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
  self-containing to be able to find a route for
  every existing E.164 Number?
• What are the security and AA requirements
  associated with this?

16
Questions to be answered (cont)

• Should the system allow
• to find E.164 related end-points within a
  carriers network?
• to find E.164 related end-points in other
  carriers networks?
• to find (the border elements of) other networks
  hosting E.164 related end-points?
• to find (the border elements of) other networks
  providing access to E.164 related end-points
  (that is transit networks) ?
• anything else?
• more than one option may be answered with yes

17
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)

18
Privacy problems with ENUM?

• There has never been privacy in a village
• so there will be no privacy in the global
  village
• Tomorrows mobile devices will broadcast clouds
  of personal data to invisible monitors as we move
  from place to place. (Smart Mobs
  Howard Rheingold)

19
Scope of this mini-BoF

1. What is the Problem Statement here
2. What are the Requirements that address the
   Problem
3. Discussion of specific approaches to a solution
   are out of scope.