1. PSTN – User ENUM – „Infrastructure ENUM“ An ETSI View Richard Stastny IETF60 San Diego

2. August 2004Richard Stastny2 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. August 2004Richard Stastny3 (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. August 2004Richard Stastny4 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. August 2004Richard Stastny5 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)

6. August 2004Richard Stastny6 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. August 2004Richard Stastny7 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 salmon@sipgate.de

8. August 2004Richard Stastny8 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. August 2004Richard Stastny9 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. August 2004Richard Stastny10 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. August 2004Richard Stastny11 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. August 2004Richard Stastny12 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. August 2004Richard Stastny13 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.infowww.e164.info Feedback and questions: Thilo Salmon

14. Questions to be answered in this mini-BoF Richard Stastny IETF60 San Diego

15. August 2004Richard Stastny15 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 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. August 2004Richard Stastny16 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. August 2004Richard Stastny17 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. August 2004Richard Stastny18 Privacy problems with ENUM? There has never been privacy in a village so there will be no privacy in the global village Tomorrow‘s mobile devices will broadcast clouds of personal data to invisible monitors as we move from place to place. (Smart Mobs – Howard Rheingold)

19. August 2004Richard Stastny19 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.