August 2004 - enum-wg - mailman.ripe.net

ITU's interim ENUM procedures revised
by Carsten Schiefner 27 Aug '04

27 Aug '04

All, to be found at: http://www.itu.int/ITU-T/inr/enum/procedures.html The major addition are two paragraphs dealing with issues arising from countries with an integrated numbering plan, such as +1. Best, Carsten

1 0

Recommended reading on Numbering
by Stastny Richard 27 Aug '04

27 Aug '04

Hi folks, Richard Hill pointed recently to a very interesting paper on Numbering: http://www.satradehub.org/Data/Reports/Global%20numbering%20issues%20review… The Title is "Numbering Trends: A Gobal Overview" by Claire Milne for the Regional Center for Southern Africa. The document analyses many of the current issues on numbering, what the issues and pit-falls are in setting-up or modifying a numbering plan and in doing so, it explains very well the terminology and also the background of existing numbering structures in different countries. Although VoIP and ENUM issues are excluded, it may serve as excellent introductory reading in numbering, especially for net-heads currently trying to set up their own numbering plans on the Internet ;-) regards Richard -----Original Message----- From: richard.hill(a)itu.int [mailto:richard.hill@itu.int] Sent: Thursday, August 26, 2004 5:24 PM To: tsg2q1(a)ties.itu.int Subject: Possible information document The paper: http://www.satradehub.org/Data/Reports/Global%20numbering%20issues%20review. pdf by Claire Milne seems very informative to me. Unless there are objections, I propose to ask Claire if she would agree that I post it on the SG2 Information Documents site, at: http://www.itu.int/itudoc/itu-t/com2/infodocs/index.html Thanks and best, Richard ----------------------------------------- Richard Hill Counsellor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva 20 Switzerland tel: +41 22 730 5887 FAX: +41 22 730 5853 Email: richard.hill(a)itu.int Study Group 2 email: tsbsg2(a)itu.int

1 0

Contract for +43 ENUM Tier 1 Registry between RTR and enum.at
by Stastny Richard 24 Aug '04

24 Aug '04

ENUM goes commercial in Austria RTR <http://www.rtr.at> (the Austrian Regulator) and enum.at <http://www.enum.at> announced today officially in a common press conference the planned launch of a commercial ENUM service in Austria. The corresponding press releases can be found (in German) at enum.at Presseinformation (PDF) <http://www.enum.at/PK_Info_ENUM.pdf> and RTR Presseinformation (PDF) <http://www.enum.at/RTR_Meldung.pdf> During the press conference two presentations where given: Prasentation ENUM_was ist das.pdf (2986,77 kB) <http://www.rtr.at/web.nsf/lookuid/AF61B055A7CE3EB8C1256EFA00294001/$fil e/Prasentation%20ENUM_was%20ist%20das.pdf> and Prasentation ENUM 24082004.pdf (553,99 kB) <http://www.rtr.at/web.nsf/lookuid/AF61B055A7CE3EB8C1256EFA00294001/$fil e/Prasentation%20ENUM%2024082004.pdf> The major reason for the press conference was the presentation of the contract between RTR and enum.at regarding the operation of the ENUM Tier 1 Registry. The contract is also available at the RTR-webpage: ENUM_Vertrag.pdf (206,3 kB) <http://www.rtr.at/web.nsf/lookuid/AB9BE747D5DAAA41C1256EFA0031842C/$fil e/ENUM_Vertrag.pdf> Sorry, the contract is currently only available in German, and English version is under translation. The contract is about the ENUM Tier 1 Registry operation, but also gives obligations for the contracts between the ENUM Tier 1 Registry and the Registrars. It also defines the number ranges that will be available in ENUM and the validation and identification required for the different number ranges. The number ranges in ENUM will be: -geographic numbers -private networks (05) -mobile numbers (06xx) -non-geographic fixed numbers (0720) -ENUM-driven numbers (0780) -freephone numbers (0800) The validation and identification methods differ for the different number ranges, potential examples are given in the annex B of the contract. The contract also defines the data stored at the ENUM Tier 1 registry for each delegated number ("WHOIS capability"). In short: For control and escrow purposes the subscriber identity (name and address) is stored at the ENUM Tier 1 Registry (for numbers requiring identification), but not available for the general public. Publicly available is only the fact that the number is delegated and the registrar. This allows also for ENUM delegations without identification, given proper validation (e.g. for mobile prepaid numbers with SMS validation). > Richard Stastny OFEG Osterreichische Fernmeldetechnische Entwicklungs- und Forderungsgesellschaft mbH Buroadresse: Arsenal Objekt 24, 7. Stock, Bauteil Ost, A-1030 Wien Postadresse: Postfach 147, A-1103 Wien Telefon: +43 664 420 4100 Telefax: +43 1 79780 13 E-Mail: <mailto:richard.stastny@oefeg.at <mailto:richard.stastny@oefeg.at> > Web: <http://www.oefeg.at <http://www.oefeg.at/> > Die in dieser Mitteilung und Anhangen enthaltenen Informationen sind ausschlie?lich fur den Adressaten bestimmt und konnen geheime, vertrauliche oder vor Weitergabe geschutzte Informationen enthalten. Falls es sich beim Leser dieses Absatzes nicht um den beabsichtigten Empfanger oder dessen Vertretung handelt, wird er hiermit in Kenntnis gesetzt, dass jegliche Weitergabe, Verteilung oder Vervielfaltigung dieser Mitteilung verboten ist. Sollte dieses Schreiben irrtumlich zugestellt worden sein, wird gebeten, den Absender zu benachrichtigen und die Mitteilung zu loschen, ohne Kopien einzubehalten. Danke.

1 0

Re: [enum-wg] .de regulator starts proceeding against voip providers using +49 numbers for voip
by Stastny Richard 21 Aug '04

21 Aug '04

Carsten wrote: >However, as I have learned in the meantime, Deutsche Telekom is offering >a PSTN product called "T-Net vor Ort" (roughly: T-Net on-site) where a >customer located in area A can get an area B number rerouted to his area >A number - which appears to be pretty much what sipgate et al. are doing. In Austria we have have this feature (although not very well known to to customers - like many ISDN features) since more then 20 years. It is simple: you get a number in an office without an attached physical line and simply put a Call Forwarding Unconditional (CFU) on it. Companies used this for routing local calls to their call centers located somewhere else before 0800 was introduced, so you see how old this feature is. Note however: you CANNOT originate calls using this number This will be important! Nobody had any problem with this, but again: "Quod licet Jovi, non licet bovi" Back to the original dicussion: What are the problems with geographic numbers for VoIP? Since we have the same dicussion here in Austria too, some of the arguments: pro and contra But first some philosphical ideas about E.164 numbers: - an E.164 number is primarily an address(name) for a destination (end-point), in principle you do not need an E.164 number to originate a call (but see below), in the same way you do not need an address to post a letter. - you need an address for posting a letter only to identify youself and to provide a return address, same is valid for phone calls. -with originating phone calls you need an E.164 number only to provide call back CLI, identification (MCI) and geographic address for emergency calls (we will see later that this is an important argument) 1) A geographic number is giving you the approx location of the recipient This may be interesting for calling Pizza services, but with call forwardings and mobile phones this arguement does not hold. Note: there is of course a difference between NA an EU. In Europe most mobile numbers are different to geographic numbers, in NA all mobile numbers are also geogrphic. 2) a geographic number gives others the possibility to call you with local rates. This is BTW the major reason why geographic numbers are popular for VoIP. On the other hand, this reason will go away soon. 3) Popular cities may run out of numbers, requiring numbering changes. Ok, this may be true in the NANP, (but they seem to have no real problems there, not even in Washington ;-) but definitely not in the short term in Germany and Austria with variable lenght numbering plans and a clever assignment procedure and routing procedure (e.g. not giving away full numbering blocks to VoIP providers, but single numbers). Also one may assume that fixed PSTN numbers are given up for mobile numbers, so they may be ported to VoIP 4) Emergency services will get problems if called by these numbers. This IMHO the real problem, but it needs to be solved in a differnt way: providing location information for VoIP calls in general. The simplest approach is to use the same mechanism (partially implemented already, partially planned) for mobile calls by providing actual location information during the emergency call. The proposed solution is as follows: As long as emergency services have no access to actual location databases and rely on static information for geographic numbers, calls originating with geographic numbers to emergency services SHALL do this ONLY from the location provided to the location database (e.g. phone book). If a call is originated from a VoIP phone, this implies the call is either originated from the given location (in which case the geographic number may be used) or if from somewhere else, a non-geographic number must be used to indicate to the emergency service that the address provided in the location database may be incorrect and the real location need to be found out if necessary. This implies that a non-geographic number range is readily available for this use. It is also advisable that calling this non-geographic number range from within a country should be comparable with local call rates, so the tariffing argument is not valid (this is also feasible from a PSTN point of view, assuming that calls to this number range is routed to local gateways anyway) Now this leaves three options for geographic numbers. A) Strict: you need a fixed access in the geographic area (e.g. a DSL or cable) to get a geographic number and you may receive and originate calls only from this location. B) Less strict: You need a fixed location in the geographic area to get a geographic number, but you may receive calls anywhere. You may originate calls using the geographic number only from this location, if you are not at this location, you may either not originate calls or use a different non-geographic number Note: Since A can be converted with simple Call Forwarding immediately to B, A is useless. C) Liberal: You may get a geographic number anywhere without a having an access there to receive calls, but you are not allowed to originate calls using this number. For originations you must use a non-geographic number. This seems to be what the consumer want. Additional notes to consider: The whole situation is completely out of control anyway and any regulation on this issue will only hinder companies (especially national ones) to pursue their business: What is in principle the difference to the above cases on VoIP if a have a PSTN line with a geographic number connected to a SPA-3000 with an FXO port an now I make a call out the PSTN in Vienna (especially to an emergency service) via t he Internet (e.g. from Boston). No regulator can prevent this an it has the same effect as above. So the only argument that remains is number exhaust and this argument is currently not existing. Just wait and see. regards Richard

1 0

.de regulator starts proceeding against voip providers using +49 numbers for voip
by Chris Heinze 21 Aug '04

21 Aug '04

hi! seems like regtp (.de regulator) starts to proceed against voip providers using +49 numbers for voip. a german article: http://golem.de/0408/33112.html basically the article says that regtp approached two of the more-well-known voip providers in germany and ordered them to stop using +49 numbers for voip users that 'are not located in the region of the number' (i.e. a 'user from duesseldorf' (i have no information on what regtp thinks that means) is not allowed to get a number from hamburg). the german non-regional prefix is currently still not available. so basically that means that german voip providers cannot use +49 numbers anymore. a non-german gateway or gateway-provider might help - sorry carsten, your folks might soon have to dial a foreign-cc-number to reach you from pstn via voip... i beleive the two providers are present here - if so, any further comments/info from that side would of course be more than interesting... :) kind regards, Chris Heinze

3 4

repost: Proposal for non-geographic ENUM E.164 UPTS for the general public
by Chris Heinze 19 Aug '04

19 Aug '04

hi! the company i'm with is providing services in the voip-area, and we had and still have our problems with the situation with telephone-numbers for voip-services in general. we were observing that other companies have the same and similar problems, and that several - mostly quite ugly - workarounds are being started, but that's all not very promising. also recent trials and decisions in our region didn't make us very confident that there's a working solution to this problem anywhere in sight. so we thought it might be a good time to start a discussion about possible solutions to the telephone-number problems, and we consider the just-in-time creation of the ripe enum-wg a good omen. ;) we put together a kind of proposal for a possible solution, just to contribute to the discussion and have something to talk about. we're very curious whether there is general support for a request of non-geographical E.164 UPTS-space for enduser-assignments handled by public registries, and in case there is, what is your idea about the following proposal, what should be done different? we're hoping some proposal for action towards some solution that is capable of finding consensus in the WG and the respective other involved institutions can be produced. so let's become formal and to the point: ----- snip ----- Proposal for a public registry system for non-geographic E.164 UPTS assignments and the respective ENUM space ============================================================================================================= Version ------- This document is version 0.1 of the ENUM E.164 UPTS proposal, dated 16 June 2004. Status ------ This document is still in draft form and is open to discussion from all parties. Scope ----- The intended audience for this document is the RIPE ENUM-WG. Once consensus has been reached the intended audience should be expanded to RIPE Services-WG, RIPE DNS-WG, RIPE DB-WG, RIPE Policy-WG, the respective groups of the other RIRs, and/or any other involved parties. Comments to the authors are encouraged. 1. Introduction --------------- In today's internet there is already a large variety of digits-only VoIP devices on the market, also working VoIP-PSTN-gates are available. In the same time there is no registry able to provide for assignments of appropriate telephone numbers according to ITU-T E.164 (i.e. reachable in the international telephone system) and the respective ENUM delegation to the general public. Currently workarounds are being developed (reassignments of geographic-CC numbers, alternative ENUM-trees, non-regional national CC numbers, etc.) resulting in isolated numberspaces, user confusion, and possible future problems resulting from lack of coordination. Because of this current situation there is an immediate need for non-geographic ENUM enabled E.164 UPTS space available for assignments to the general public, and creation of a structure to handle registry tasks, both administrative and operational. 2. Goals -------- The requirements for the registry: - provide undiscriminatory service to the general public (which implies independence towards commercial markets and nations) - provide global service (which implies independence from nations) - provide stable registry and ENUM service - development of policies (which implies the need for some sort of legitimation from the community) The requirements for the number space: - part of the international telephone number space (implies ITU-T E.164) - non-geographic - enduser-specific (UPTS) - fully portable 3. Registry System ------------------ The NRO as the 'community of RIRs', meeting all requirements and already providing a working structure and experience for such a registry, acts as the formal registry (Tier 1) for the assigned ENUM E.164 UPTS space. 3.1 Registry: allocations/assignments ------------------------------------- The RIPE (or a different RIR acting as central coordination point) allocates parts of the assigned ENUM E.164 UPTS space to the RIRs (including itself). The RIRs allocate parts of their respective allocations to their LIRs. LIRs assign numbers from their blocks to endusers. Assignments are enduser-specific (like IPv4 PI), i.e. the allocation to LIRs is just for new assignments, when an enduser changes serviceproviders the authority for the assignment moves with the enduser. 3.2 Registry: database ---------------------- As database for allocations and assignments, whois is used. The whole block assigned by ITU-T is entered as one domain object, with mnt and mnt-lower set to an appropriate maintainer from RIPE (or a different RIR acting as central coordination point). When a block is allocated to a RIR, RIPE creates the respective domain object, entering an appropriate maintainer from the respective RIR as mnt and mnt-lower. When a block is allocated to a LIR, the respective RIR creates the respective domain object, entering an appropriate maintainer from the respective LIR as mnt and mnt-lower. When a number is assigned to an enduser, a maintainer according to the enduser's wishes might be entered. When the enduser changes service providers, a different maintainer can be entered. 3.3 Registry: ENUM ------------------ ENUM delegations are done upon allocation or assignment, i.e.: ITU-T (resp. RIPE acting as Tier 0 for ITU-T) delegates ENUM for the assigned block to RIPE (or a different RIR acting as central coordination point). When a block is allocated to a RIR, the respective ENUM delegations to the RIR are done. The RIR creates its delegations from its database by querying for all most-specific objects (this is important to achieve full portability). 3.4 Registry: ENUM delegation from database ------------------------------------------- RIPE (or a different RIR acting as central coordination point) has to make sure that upon allocation of a block to a RIR, the necessary ENUM delegations are made. As the kind of mechanism used to achieve this doesn't influence procedures in the RIRs, it's only the central coordination point's matter how this is done. But this could be done by the nserver attributes of the domain objects entered upon allocation, and the nameserver configuration could easily be created automatically in such a way. RIRs have to generate delegations in their nameservers from the most specific domain objects. This way the necessary nameserver configuration can be created automatically, isn't dependent on a fixed allocation/assignment length, and provides for full portability. 3.5 Registry: policies ---------------------- A policy for allocation of blocks to the RIRs should be developed in the NRO context. A policy for allocation of blocks to the LIRs and a policy for assignment to endusers by LIRs should be developed by the respective RIR, but common policies (via NRO) might be desirable. All allocations or assignments should be done on request only, a initial automatic allocation of blocks to RIR-members should be deprecated for number space conservation reasons. The assignment policy for LIRs should demonstrate what is considered good practise. Possible norms could regard to the size of blocks assigned to entities (e.g. a fixed assignment length), the number of assignments to entities, and whether an assignment has to be deleted when the enduser is giving it up (i.e. does it have to be available for reassignment by the LIR who initially received the respective block for new assignments or is it ok for the last maintainer/service provider to reuse it?). LIRs receive allocations of blocks from RIRs as a means of moving the work necessary for assignments to the member-level where the request was delivered, and where service is done directly to the enduser. To install some kind of quality assurance, it's proposed to introduce a slow-start mechanism just like with IPv4 PA assignments: initial assignments have to be approved by a RIR hostmaster, until it is decided by the RIR to give the LIR an assignment window, which will be increased when the LIR demonstrated sufficient experience. 4. E.164 UPTS space ------------------- The RIRs request from the ITU-T TSB assignment of non-geographic E.164 UPTS space (i.e. a block under CC878) to the NRO and the respective ENUM delegation to RIPE. It might be worth considering explicitly requesting a short (i.e. 1 digit) prefix to have a number space as large as possible to attenuate ENUM block-delegation issues. I guess the community might like the idea of a sub-block identifier '7' (i.e. +8787 with an 11 digits space) 5. Actions ---------- 1.) discussion in RIPE ENUM-WG on UPTS-space for enduser-assignments handled by RIRs in case of general support of ENUM-WG: 2.) discussion in RIPE ENUM-WG, Services-WG, DNS-WG, and DB-WG on request for registry service (tier 1) operations run by RIPE in case of general support of ENUM-WG and Services-WG: 3.) discussion in RIPE Address Policy-WG on ENUM878x allocation/assignment policies in case of a consensus on (preliminary) policies: 4.) discussion in NRO context (actions 2, 3, and 4 might be intermixed) in case of a consensus on (preliminary) policies: 5.) request to ITU-T TSB for delegation of a non-geographic UPTS block under E.164 CC878 to the RIRs (formally NRO, or RIPE acting in consensus with RIR-community) ----- snap ----- kind regards, Chris Heinze

6 22

Re: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public
by Richard Shockey 11 Aug '04

11 Aug '04

A > >This is the major reason why +87810 is still not up >and running. If you use a national number, the number >can at least by routed via the country as a default. > > Wether you have issues with non-geographical E.164 or not depends > a lot > of what regulation there is on E.164 numbers in the country code you > want numbers in. Other examples of issues include portability to > other > providers. > > Example: Sweden (+46) require portability between providers of voice > services, but do not have geographical portability (yet). This > imply if > you as an operator in Sweden you have to allow people to move their > number both to and from you. Which is exactly the way the US and Canada works but we have have a flat numbering space which means you can take your wire line and port to wireless as well. Patrik remind me .. does Sweden use a Database model or is it simply call forwarding form the originating carriers Switch . > > My point is not that your idea is wrong, but that you have to > take into > account a number of different issues... > > Can you be more specific on what the rules are for E.164 numbers in > your neck of the woods? > > paf > > On Aug 9, 2004, at 16:53, Chris Heinze wrote: > > > hi! > > > > the company i'm with is providing services in the voip-area, > and we had > > and still have our problems with the situation with > telephone-numbers > > for voip-services in general. we were observing that other > companies > > have the same and similar problems, and that several - mostly > quite > > ugly > > - workarounds are being started, but that's all not very > promising. > > also > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 <mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz> <http://www.neustar.biz> ; <http://www.enum.org> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

2 1

Re: [enum-wg] New Subject: What ENUM wg should do...
by Jim Reid 11 Aug '04

11 Aug '04

>>>>> "paf" == =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= <ISO-8859-1> writes: paf> One of the things Kim and I have planned for this wg is to paf> keep a webpage updated with, for each CC/country, answers to paf> questions on what rules exists for various things -- one of paf> them being how integration of E.164 numbers is... paf> Does this sound like a "good thing for this wg to do"? YES!

4 4

Re: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public
by Jim Reid 11 Aug '04

11 Aug '04

I think Chris's idea is good in principle, though I'm not sure about its practicality. As Patrik says, use of non-geographic E.164 numbers touches on awkward corners of national telephony regulations. I think the ITU would take a dim view of this too. And that's aside from them being uneasy (unable?) about issuing a chunk of E.164 number space to an organisation that isn't an ITU member. IIUC ITU directly controls E.164 numbers used for Universal Personal Telephony, so they could well be touchy about another entrant into that space. There would also be a conflict of interest given that RIPE NCC is already operating the registry for e164.arpa. So if the NCC was to apply for a non-geographic E.164 code and get it, this would probably need to be administered by a separate organisation from that running the e164.arpa registry.

5 4

Re: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public
by Jim Reid 10 Aug '04

10 Aug '04

>>>>> "Chris" == Chris Heinze <x(a)ccn.net> writes: Chris> can you think of a practical solution to satisfy the ITU's needs? I'm not yet sure what the requirements are: ie why you want RIPE NCC to operate some E.164 number range for UPT and why this can't be done by someone else who already has existing E.164 numbers. From an ITU perspective, I think this has to be clear before any allocation of E.164 space will be considered. In other words, you need to explain to ITU that you have a need for space -- how much?? -- that isn't or can't be addressed elsewhere. You may also need to show how this number range will interwork with the rest of the telephony world. An explanation of how other telcos and carriers can route calls to/from this number range could be helful. Bear in mind too that talk of VoIP implies telephony by-pass, which is something that makes telcos and some regulators *very* uncomfortable. Going to ITU and saying "give me a pile of E.164 numbers for VoIP so I can eliminate revenue for the telcos who pay your membership fees" isn't likely to get a warm reception. And the regulators will want to know about what will be done about access to emergency services, universal service obligations, QoS, lawful intercept, blah, blah, blah. Chris> but i also think it wasn't Chris> a bad choice for ITU to delegate tier 0 operation to RIPE. You're playing with fire here. It was IAB who delegated e164.arpa to RIPE NCC. [Not RIPE.] I believe ITU were not consulted about this and they're still a bit annoyed about that. ITU would like to be listed as the administrative contact for e164.arpa, which is another sore point. >> There would also be a conflict of interest given that RIPE NCC >> is already operating the registry for e164.arpa. So if the NCC >> was to apply for a non-geographic E.164 code and get it, this >> would probably need to be administered by a separate >> organisation from that running the e164.arpa registry. Chris> i guess it's a sub-optimal idea to allocate the block to Chris> RIPE and RIPE only, the community of RIRs probably in the Chris> form of the NRO would be a better idea, as the space is Chris> meant to be used globally. I think it would be very helpful if you could sketch out a model for how this proposed organisation would be structured and funded, what the roles & responsibilities would be, etc, etc. Bear in mind there could be legal issues too. Like the RIRs extending their monopolies or going beyond their charter obligations, impact on EU competition regulations, etc, etc. Chris> actually the work RIPE did up Chris> to now as tier 0 operator demonstrates the high Chris> qualifications of RIPE as an enum-operator at the tier 0 Chris> and tier 1 levels quite convincingly. Sure, the NCC does an excellent job at operating the Tier-0 registry. This is to be expected. However that pretty much rules them out of operating any Tier-1 (or Tier-N) infrastructure.

3 2