repost: Proposal for non-geographic ENUM E.164 UPTS for the general public
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
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. 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 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
hi!
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.
this is true for geographical i.e. cc-number space, but not for numbers from non-geographic prefixes. +878 is non-geographical space, a 'country code' not assigned to a region or state. the idea is to have a prefix allocated to the RIRs, and of course there have to be policies for this number space at the RIRs - i guess the RIR/NRO context is a perfect place to create such policies.
Other examples of issues include portability to other providers.
right. the idea behind non-geographic space is its good reference of voip-requirements. if number porability to pstn users is desired, the whois-solution should work for these cases too, if a pstn provider wants to offer portability to pstn i guess this implies a solution for the pstn-side by the requesting provider (probably more easy e.g. in mobile networks). but in case this space will never be used in pstn networks, it still is a helpful and good solution for voip-users.
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.
this is regulation of the +46 cc-number space, i guess. otherwise if you say 'numbers' certainly PA space would be a problem, probably domain names, etc. but even if regulations in one country prohibit users and providers to use global numbers for voip, in other countries this would still be a preferable solution.
My point is not that your idea is wrong, but that you have to take into account a number of different issues...
certainly. i hope this is the right place for a discussion for these issues, and for finding good solutions for identified problems. :)
Can you be more specific on what the rules are for E.164 numbers in your neck of the woods?
that's germany. +49 numbers are in their regions fully portable between pstn providers. currently large regional blocks are reallocated by voip gateway providers to voip-users. so a voip-user from e.g. dresden can have a number from e.g. duesseldorf, hamburg, berlin, munich - or all of them. that's really ugly but voip providers actually have no big choice. there is a 'region' reserved for non-regional (in the end of course still national) numbers (+4932), but this is currently discussed and it's unlikely that this prefix will be useably anytime soon. also, there are strong doubts that this prefix will be freely available to voip-providers, the current discussion shows that there will probably be dependencies and drawbacks especially for voip. kind regards, Chris Heinze
Hi Chris, Chris Heinze wrote:
that's germany. +49 numbers are in their regions fully portable between pstn providers. currently large regional blocks are reallocated by voip gateway providers to voip-users. so a voip-user from e.g. dresden can have a number from e.g. duesseldorf, hamburg, berlin, munich - or all of them.
... and which AFAIK is of some major concern to the regulator. Apart from the fact that they don't have any real means at hand right now, they do not get tired of repeating their unhappiness.
that's really ugly but voip providers actually have no big choice. there is a 'region' reserved for non-regional (in the end of course still national) numbers (+4932), but this is currently discussed and it's unlikely that this prefix will be useably anytime soon. also, there are strong doubts that this prefix will be freely available to voip-providers, the current discussion shows that there will probably be dependencies and drawbacks especially for voip.
That is one of my concerns - that according to the current draft only "real" telcos can get numbers or blocks out of that range. So any VoIP only provider just has to rely on others instead of being able to deal with the regulator directly. Another one is (and I find that in your proposal, too) the idea of allocating/assigning blocks: at the end of the day we are also talking domains here. In the domain world such a concept is totally unknown (for good reasons!) and would not really be feaseble: get domain names starting with a to k from registrar A and from l to z from registrar B...?! As you have to ensure portability in the long run anyways: why not assigning a number out of such blocks (whether it's +878xx, +4932 or something else) directly to the user? S/he can port the number to a provider of an own choice without creating "holes" in blocks allocated or assigned to providers/LIRs/... IMHO the difference really is that people (apart from very few ;-) do not really care about the IP addresses they get because you hardly announce them to third parties as points of contact anyways. But you certainly do with your UPT/... numbers. That, of course, would be a different registry type - more a domain registry that an RIR. But I am certainly not saying that an RIR cannot or even must not take up that business, too - given that all parties involved agree to it. Cheers, -C.
hi!
that's germany. +49 numbers are in their regions fully portable between pstn providers. currently large regional blocks are reallocated by voip gateway providers to voip-users. so a voip-user from e.g. dresden can have a number from e.g. duesseldorf, hamburg, berlin, munich - or all of them.
... and which AFAIK is of some major concern to the regulator. Apart from the fact that they don't have any real means at hand right now, they do not get tired of repeating their unhappiness.
yes - actually (except for some endusers that consider it fun to have numbers from different cities) i know of nobody who is really happy with this solution, last of all the gateway providers. there's really a need for a real solution, and in voip-context a global non-regional number space is imho most straightforward. it's hardly optimal to dial +4932.... or any other cc-number to reach a user who is currently in helsinki and might be in hongkong tomorrow... as an international prefix could be seen as a public resource that has to be available in a non-discriminating way, i beleive personal numbers assigned to the endusers are again the most straightforward solution. if blocks were allocated to providers and were only portable as the whole block, i think that would spoil portability as well as the idea of non-regional numbers. actually e.164 provides for other number space to be allocated/assigned to companies on a big block level, so when there is need for something like that, an existing global upts wouldn't spoil anything.
that's really ugly but voip providers actually have no big choice. there is a 'region' reserved for non-regional (in the end of course still national) numbers (+4932), but this is currently discussed and it's unlikely that this prefix will be useably anytime soon. also, there are strong doubts that this prefix will be freely available to voip-providers, the current discussion shows that there will probably be dependencies and drawbacks especially for voip.
That is one of my concerns - that according to the current draft only "real" telcos can get numbers or blocks out of that range. So any VoIP only provider just has to rely on others instead of being able to deal with the regulator directly.
right. although this is a point that shows up quite clearly, the impression i get from the current state of discussion is more the one of a swamp... it's really hard to get an idea of where it's really going in the end. that's really frustrating, while the need for a real solution grows every day, and as i said before, i don't think that non-regional national numbers are actually a real solution...
Another one is (and I find that in your proposal, too) the idea of allocating/assigning blocks: at the end of the day we are also talking domains here. In the domain world such a concept is totally unknown (for good reasons!) and would not really be feaseble: get domain names starting with a to k from registrar A and from l to z from registrar B...?!
hm, right, 100% ack. but maybe that's just my bad explanation in the proposal, the idea was to allocate blocks to providers to keep administrative work at the rir level low, while every single number stays portable by using the hierarchical means provided by whois: if a single number out of the provider-allocated block is ported, the maintainer is changed to the new provider as well as the enum-delegation (see collection of 'most specific' nameserver info in the proposal). this way every number would stay portable. hmm - of course, this would spoil 'wish-numbers' (sorry for the brutal translation, corrections welcome ;), or even could lead to very very strange procedures (i'm too scared to describe what i'm thinking about ;>) by sbdy trying to get such a specific number... maybe there is a reasonable solution without allocation of blocks. in this case the rirs would probably have to deal with each single number request... i'm not sure if that can be automated or handled in a way that doesn't produce lots of work at the rir-level... maybe with some sort of assignment window? ideas more than welcome! :)
As you have to ensure portability in the long run anyways: why not assigning a number out of such blocks (whether it's +878xx, +4932 or something else) directly to the user? S/he can port the number to a provider of an own choice without creating "holes" in blocks allocated or assigned to providers/LIRs/...
from my view this would be the most charming solution - but creating a lot of work on the rir level is not an option, and currently i don't know of a practical solution to that... hmm...
IMHO the difference really is that people (apart from very few ;-) do not really care about the IP addresses they get because you hardly announce them to third parties as points of contact anyways. But you certainly do with your UPT/... numbers.
right... hmm... maybe without allocation of blocks to providers, but allocation of a 'number of (not specific phone-)numbers' could work. actually that would already be a kind of AW-solution. hm. sounds realistic to me, while work at the rir-level were still rather low.
That, of course, would be a different registry type - more a domain registry that an RIR. But I am certainly not saying that an RIR cannot or even must not take up that business, too - given that all parties involved agree to it.
i think regarding the whois, it would work. the most important point is of course the last one, there of course has to be substantial consent to a general need for this. from what i see in every day business, i'd say it certainly really is there. let's find out... kind regards, Chris Heinze
Hi Chris, Chris Heinze wrote:
[currently large regional blocks are reallocated by voip gateway providers to voip-users. so a voip-user from e.g. dresden can have a number from e.g. duesseldorf, hamburg, berlin, munich - or all of them.]
[of some major concern to the regulator]
yes - actually (except for some endusers that consider it fun to have numbers from different cities) i know of nobody who is really happy with this solution,
you just have found the first person then. :-) My crowd back in Berlin happily rings me up with my Berlin VoIP number whereever I am.
[...] it's hardly optimal to dial +4932.... or any other cc-number to reach a user who is currently in helsinki and might be in hongkong tomorrow...
I guess, for Germans callers it would :-) - in particular if any +4932 call from the PSTN is deemed to be local and dumped onto the Internet ASAP. And if I am able to get a grip on other CCs with similar ranges and rules, I am able to satisfy the needs of my counterparts there, too.
as an international prefix could be seen as a public resource that has to be available in a non-discriminating way, i beleive personal numbers assigned to the endusers are again the most straightforward solution.
Indeed, you are right - at the end of the day, what I outlined above might be only a mid-term solution. Then again, you also want to be reachable from the PSTN - and as Richard Stastny said, deploying a new CC in the global PSTN seems to be really a drag...
hm, right, 100% ack. but maybe that's just my bad explanation in the proposal, the idea was to allocate blocks to providers to keep administrative work at the rir level low, while every single number stays portable by using the hierarchical means provided by whois: if a single number out of the provider-allocated block is ported, the maintainer is changed to the new provider as well as the enum-delegation (see collection of 'most specific' nameserver info in the proposal). this way every number would stay portable.
So who then would be in charge of the database of ported numbers: the RIR? Many DBs, one maintained by each ITSP that got the block allocated originally?
[ensure portability/assigning a number directly to the user]
from my view this would be the most charming solution - but creating a lot of work on the rir level is not an option, and currently i don't know of a practical solution to that... hmm...
On the "handling the workload" issue it might be helpful to get an opinion from an/the RIR[s] itself/themselves, I guess.
right... hmm... maybe without allocation of blocks to providers, but allocation of a 'number of (not specific phone-)numbers' could work. actually that would already be a kind of AW-solution. hm. sounds realistic to me, while work at the rir-level were still rather low.
I am afarid I lost you here - what do you mean with a 'number of (not specific phone-)numbers'? Even the comparision with an AW didn't help... Cheers, -C.
hi!
[currently large regional blocks are reallocated by voip gateway providers to voip-users. so a voip-user from e.g. dresden can have a number from e.g. duesseldorf, hamburg, berlin, munich - or all of them.]
[of some major concern to the regulator]
yes - actually (except for some endusers that consider it fun to have numbers from different cities) i know of nobody who is really happy with this solution,
you just have found the first person then. :-) My crowd back in Berlin happily rings me up with my Berlin VoIP number whereever I am.
[...] it's hardly optimal to dial +4932.... or any other cc-number to reach a user who is currently in helsinki and might be in hongkong tomorrow...
I guess, for Germans callers it would :-) - in particular if any +4932 call from the PSTN is deemed to be local and dumped onto the Internet ASAP.
And if I am able to get a grip on other CCs with similar ranges and rules, I am able to satisfy the needs of my counterparts there, too.
well ok, that's the enduser-you ;) of course i'm using this too, as it's an easy way to save money. but i don't regard this as a reasonable (long-term) solution, and i strongly doubt that this practice is helpful for a reasonable development and smooth convergence... and probably this will be prohibited over here (more or less) soon, i guess this will happen in the moment +4932 becomes 'available'. btw: the enduser-you is probably less happy having to call a +1* voip-number from pstn from germany or having to call a +4932* voip-number from india compared to calling a +878* voip-number... :) telcos again might probably often be more happy with the first solution... maybe we could also set up some kind of demoscopic tool on the wg-webpage, to find out e.g. what percentage of the enum-wg resp. interested community thinks it's best or ok to stick with the cc-numbers for voip, and if so whether the regional numbers are regarded ok or only the non-regional national numbers (where available) should be used for voip?
as an international prefix could be seen as a public resource that has to be available in a non-discriminating way, i beleive personal numbers assigned to the endusers are again the most straightforward solution.
Indeed, you are right - at the end of the day, what I outlined above might be only a mid-term solution. Then again, you also want to be reachable from the PSTN - and as Richard Stastny said, deploying a new CC in the global PSTN seems to be really a drag...
to illustrate better what i tried to explain before (i.e. the situation is different from a 'real' cc-prefix): imagine a telco with a PSTN network. as soon as this telco has an ip gateway (as i said before, this is already very common at least over here), the telco can route this prefix to that gateway, there an enum lookup is done and the call is connected. at the same time the telco is able but in no way forced to offer gateway services for calls from ip to pstn to voip-providers or voip-users. even if the telco doesn't have an own ip gateway, buying such a service from a different telco would be another simple option. offering connectivity to voip-numbers would be an interesting point when it comes to competition between telcos. i beleive there's a strong incentive for telcos to set up an ip gateway as soon as such a prefix is available. technically i know for example for our primary telco that it were easily possible to set up +878* routing for their PSTN network today. and no coordination with other telcos would be necessary, no dependencies.
hm, right, 100% ack. but maybe that's just my bad explanation in the proposal, the idea was to allocate blocks to providers to keep administrative work at the rir level low, while every single number stays portable by using the hierarchical means provided by whois: if a single number out of the provider-allocated block is ported, the maintainer is changed to the new provider as well as the enum-delegation (see collection of 'most specific' nameserver info in the proposal). this way every number would stay portable.
So who then would be in charge of the database of ported numbers: the RIR? Many DBs, one maintained by each ITSP that got the block allocated originally?
no, the idea is to use the whois-db. with allocated blocks these blocks would be distributed over the different RIRs' whois-dbs. porting a number would mean a change of the whois-db entry (by the current admin i.e. holder of the maintainer-object of the respective number), replacing the maintainer-object and delegation data of that entry. with assignments of single numbers without prior allocation, this is different, either some reasonable way of distributing these single assignments over the RIRs' whois-dbs must be found or a single whois-db had to be used. this also might affect the mechanism to generate delegations. only the whois-db(s) would be necessary to hold the authoritative data regarding number assignments.
[ensure portability/assigning a number directly to the user]
from my view this would be the most charming solution - but creating a lot of work on the rir level is not an option, and currently i don't know of a practical solution to that... hmm...
On the "handling the workload" issue it might be helpful to get an opinion from an/the RIR[s] itself/themselves, I guess.
sure, that's also mentioned in the proposal. i guess you know who could be the right person with insight and ideas for procedures at the RIRs, or at least at RIPE? :)
right... hmm... maybe without allocation of blocks to providers, but allocation of a 'number of (not specific phone-)numbers' could work. actually that would already be a kind of AW-solution. hm. sounds realistic to me, while work at the rir-level were still rather low.
I am afarid I lost you here - what do you mean with a 'number of (not specific phone-)numbers'? Even the comparision with an AW didn't help...
i mean an amount of numbers. say, a provider has the possibility to enter 1000 numbers (no matter which ones) before an application for the next e.g. 1000 numbers is necessary. i.e. still keeping an 'AW' approach while not allocating specific blocks. kind regards, Chris Heinze
Hi, Chris. Chris Heinze wrote:
[...] even if the telco doesn't have an own ip gateway, buying such a service from a different telco would be another simple option.
That's pretty much an European view. What about countries where there is only the incumbent around? Why (no competition!) should they dump it onto the net ASAP (and loose revenue) instead of making it a long distance/intercont call? If they route the call at all... I believe even after a full introduction of +878 we will have those two types of VoIP numbers around for quite a while.
no, the idea is to use the whois-db. with allocated blocks these blocks would be distributed over the different RIRs' whois-dbs. porting a number would mean a change of the whois-db entry (by the current admin i.e. holder of the maintainer-object of the respective number), replacing the maintainer-object and delegation data of that entry.
with assignments of single numbers without prior allocation, this is different, either some reasonable way of distributing these single assignments over the RIRs' whois-dbs must be found or a single whois-db had to be used. this also might affect the mechanism to generate delegations.
only the whois-db(s) would be necessary to hold the authoritative data regarding number assignments.
Maybe you lost me here again: wouldn't that mean that over time, when people continue to port their numbers as they like, you'll end up with an entry per number? Then you should consider having such an implementation already from the very begining. And you have something that is pretty similar to a [domain] name registry...
On the "handling the workload" issue it might be helpful to get an opinion from an/the RIR[s] itself/themselves, I guess.
sure, that's also mentioned in the proposal. i guess you know who could be the right person with insight and ideas for procedures at the RIRs, or at least at RIPE? :)
That indeed could be the case, yes. ;-) However, I will certainly refrain from pointing folks out here.
i mean an amount of numbers. say, a provider has the possibility to enter 1000 numbers (no matter which ones) before an application for the next e.g. 1000 numbers is necessary. i.e. still keeping an 'AW' approach while not allocating specific blocks.
And why would this be useful? The 'AW' approach IMHO originates from the demand to have some greater flexibility on the LIR's side when doing assignments - while still keeping the idea of conservation. Question is: is there a more or less identical need for this type of conservation for UPT numbers, too? Or isn't it more like a one-off? At the end of the day it's "personal" - apart from some exceptions here and there: why would people liek to have more than one? Cheers, -C.
hi!
[...] even if the telco doesn't have an own ip gateway, buying such a service from a different telco would be another simple option.
That's pretty much an European view. What about countries where there is only the incumbent around? Why (no competition!) should they dump it onto the net ASAP (and loose revenue) instead of making it a long distance/intercont call? If they route the call at all...
well that's a question for the regulator then, isn't it. i don't want to nor see a reason why to mess with regulations. if a country decides to ban voip-gateways (although still i don't really know a good reason why), that's the country's decision and that decision has to be followed in that country. but i don't think this is a good reason to prevent everyone else from promoting voip.
I believe even after a full introduction of +878 we will have those two types of VoIP numbers around for quite a while.
probably. certainly this cannot be avoided for a long time (except locally by regulators), but also i'm not the one who demands that this has to be avoided.
no, the idea is to use the whois-db. with allocated blocks these blocks would be distributed over the different RIRs' whois-dbs. porting a number would mean a change of the whois-db entry (by the current admin i.e. holder of the maintainer-object of the respective number), replacing the maintainer-object and delegation data of that entry.
with assignments of single numbers without prior allocation, this is different, either some reasonable way of distributing these single assignments over the RIRs' whois-dbs must be found or a single whois-db had to be used. this also might affect the mechanism to generate delegations.
only the whois-db(s) would be necessary to hold the authoritative data regarding number assignments.
Maybe you lost me here again: wouldn't that mean that over time, when people continue to port their numbers as they like, you'll end up with an entry per number? Then you should consider having such an implementation already from the very begining. And you have something that is pretty similar to a [domain] name registry...
right. actually in the proposal any assigned number (or assigned block) is a single entry right from the beginning. i just checked the text (3.2), and it's in fact not clearly stated. the idea was to enter every assignment as a new object into the whois-db at the time when assignment is done. i also regard it as quite similar to a domain registry (and in other respects similar to an ip registry).
On the "handling the workload" issue it might be helpful to get an opinion from an/the RIR[s] itself/themselves, I guess.
sure, that's also mentioned in the proposal. i guess you know who could be the right person with insight and ideas for procedures at the RIRs, or at least at RIPE? :)
That indeed could be the case, yes. ;-) However, I will certainly refrain from pointing folks out here.
sure, just send them here if they don't run away fast enough ;)
i mean an amount of numbers. say, a provider has the possibility to enter 1000 numbers (no matter which ones) before an application for the next e.g. 1000 numbers is necessary. i.e. still keeping an 'AW' approach while not allocating specific blocks.
And why would this be useful? The 'AW' approach IMHO originates from the demand to have some greater flexibility on the LIR's side when doing assignments - while still keeping the idea of conservation.
Question is: is there a more or less identical need for this type of conservation for UPT numbers, too? Or isn't it more like a one-off? At the end of the day it's "personal" - apart from some exceptions here and there: why would people liek to have more than one?
the concept as such should work also without an 'assignment window'. but i think it's not a too bad idea, otherwise most-popular-vanity-number grabbing probably can not be prevented. also, depending on the policy, conservation might be identified as an issue. kind regards, Chris Heinze
Hi. Chris Heinze wrote:
[If the incumbent routes the call at all...]
well that's a question for the regulator then, isn't it.
...which in various countries IS the incumbent.
i don't want to nor see a reason why to mess with regulations. if a country decides to ban voip-gateways (although still i don't really know a good reason why),
Keep the minute meters of the 100% state owned telco glooming, for example? There has been precedence set in Belorussia AFAIR where two people went to jail for a considerable period of time for using VoIP. Interestingly, there was no law whatsoever prohibiting VoIP. The charge was something along the lines of "causing revenue loss to the incumbent".
that's the country's decision and that decision has to be followed in that country. but i don't think this is a good reason to prevent everyone else from promoting voip.
That indeed is true. :-)
the concept as such should work also without an 'assignment window'. but i think it's not a too bad idea, otherwise most-popular-vanity-number grabbing probably can not be prevented.
So? Why should it? If it's FCFS and I am faster that you, why shouldn't I get the most attractive number and you only the second most? Or vice-versa, of course! ;-) Secondly: is an AW-type of measure really the appropriate means to deal with this very issue?
also, depending on the policy, conservation might be identified as an issue.
Coudl you further detail here? The only reason for depletion I can see is rather natural: a massive interest by individuals. As said already: I have hard times thinking about individuals who would like to have MORE than one number - isn't the whole exercise about subsuming various means of communication under ONE number?! ;-) Cheers, -C.
hi!
[If the incumbent routes the call at all...]
well that's a question for the regulator then, isn't it.
...which in various countries IS the incumbent.
if the legislator wants such a situation and in this course decides or lets the incumbent decide to suppress voip, that's a local regulation issue, i beleive. i myself regard it - even in the case of a state pstn monopoly - as a not especially brilliant idea to prevent voip development, and also maybe they're all just waiting for global number space... ;)
i don't want to nor see a reason why to mess with regulations. if a country decides to ban voip-gateways (although still i don't really know a good reason why),
Keep the minute meters of the 100% state owned telco glooming, for example?
you really regard this as a _good_ reason? ;)
the concept as such should work also without an 'assignment window'. but i think it's not a too bad idea, otherwise most-popular-vanity-number grabbing probably can not be prevented.
So? Why should it? If it's FCFS and I am faster that you, why shouldn't I get the most attractive number and you only the second most? Or vice-versa, of course! ;-)
well this principle (first come first serve) is certainly ok and i generally support it. but imagine, without a means like the AW and with an automated process, i just start a script and assign, let's say, the 10000 most popular numbers like 1111..., 2222..., 3333..., 1234..., 8787... to myself to park them, and then sell them. or i don't need to sell them, i just advertise them on my webpage as a nice add-on for people that become my customers... (i personally wouldn't mind too much, because i have no big interest in special numbers, i certainly wouldn't choose a provider because of the numbers i can get there, but i assumed (keeping in mind that there are people who like to have a special number) that people might find this unfair - but i might be wrong. i don't know.) i think as a policy issue this certainly is an issue that should be discussed with as broad participation from the interested community as possible. should number-grabbing be forbidden by policy? if so, is a means of limitation/supervision/enforcement necessary? or should the policy generally allow for only exactly one one-number assignment per person? if so, per natural person only? if not, only one one-number assignment per organisation? other ideas?
Secondly: is an AW-type of measure really the appropriate means to deal with this very issue?
assuming a general consent that a means of limitation of unsupervised automated assignments is necessary or desirable, i think it is a helping means (otherwise it's probably superfluous). until now no better means came to my mind. suggestions more than welcome! if it turned out to be superfluous that would of course be great, as it would further minimize work that couldn't be done by scripts, and also simplify procedures.
also, depending on the policy, conservation might be identified as an issue.
Coudl you further detail here? The only reason for depletion I can see is rather natural: a massive interest by individuals. As said already: I have hard times thinking about individuals who would like to have MORE than one number - isn't the whole exercise about subsuming various means of communication under ONE number?! ;-)
you're probabl right here. what i wanted to say is that as there's naturally no policy yet, i don't want to say that there might not just pop up some other issues that require a slow-start-mechanism or means of 'dampening' or something like that. kind regards, Chris Heinze
Hi, Chris Heinze wrote:
Keep the minute meters of the 100% state owned telco glooming, for example?
you really regard this as a _good_ reason? ;)
depends on the PoV, I'd say. Being such a telco, keeping VoIP out of my business has not only a good, but even numerous excelllent reasons for. ;-)
i think as a policy issue this certainly is an issue that should be discussed with as broad participation from the interested community as possible.
Sure - that is what we are doing here right now, huh? ;-) Although I still feel a slight lack of "broad participation from the interested community"...
should number-grabbing be forbidden by policy? if so, is a means of limitation/supervision/enforcement necessary?
or should the policy generally allow for only exactly one one-number assignment per person? if so, per natural person only? if not, only one one-number assignment per organisation? other ideas?
What we always would need to bear in mind is: a) Is the aim of the policy really necessary? What is likely to happen if there is no policy in this regard? b) Is the measures of the policy likely to fulfil its aims? c) Is the application of a certain policy feasible for the entity supposed to apply it? What if it fails partly or even in general? Has the application of such policy any side effects, in particular unwanted ones? Best, -C.
hi!
Keep the minute meters of the 100% state owned telco glooming, for example?
you really regard this as a _good_ reason? ;)
depends on the PoV, I'd say. Being such a telco, keeping VoIP out of my business has not only a good, but even numerous excelllent reasons for. ;-)
well in this case i can tell you really great reasons why everybody who wants to get any telephone number has to pay me 1EUR. :> not valid, i'd say. this is a community forum, a collaborative forum, i think the reason 'because this way i can become richer faster without having to deal with competition' doesn't count too much in this context... at least i'm convinced that it shouldn't ;)
i think as a policy issue this certainly is an issue that should be discussed with as broad participation from the interested community as possible.
Sure - that is what we are doing here right now, huh? ;-) Although I still feel a slight lack of "broad participation from the interested community"...
right. patrick, can you tell us how many subscribers are currently on this list? i also received some mail regarding this discussion, i can just again ask everyone to take part in the public discussion here on the mailinglist, that's really much more effective than direct email only.
should number-grabbing be forbidden by policy? if so, is a means of limitation/supervision/enforcement necessary?
or should the policy generally allow for only exactly one one-number assignment per person? if so, per natural person only? if not, only one one-number assignment per organisation? other ideas?
What we always would need to bear in mind is: a) Is the aim of the policy really necessary? What is likely to happen if there is no policy in this regard?
right. i'm convinced if there's no limitation at all, number grabbing on a large scale will occur. usually, what can be done will be done, i.e. i regard it as probable that there will happen things like considerable part of the space (or maybe even half of or the whole space) being parked by a single or a few organisations. therefore i'd propose that this should at least be mentioned in the policies, something like the ip policy, so that assignments are only to be made if there's actually reasonable need by an enduser to actually use the number(s) to be assigned. i don't (yet?) see a necessity for a general limitation of one number per person, and i see a potential problem with companies limited to one number (and i doubt that such demands can be broken down to natural persons), so for these reasons i'd suggest not to create such a fixed limit.
b) Is the measures of the policy likely to fulfil its aims?
i'm not sure whether such a policy needs a means of enforcement, esp. when human interaction by the registry has to be avoided (for cost reasons). i personally would like to discuss this more before coming to a conclusion for myself (any 'ripe-services insider' here who can comment on the workload usually created by a new lir 'without aw' compared to 'with aw'? is there generally reliable discipline of sticking to the policies by the lirs themselves, even without a special means of enforcement?).
c) Is the application of a certain policy feasible for the entity supposed to apply it? What if it fails partly or even in general? Has the application of such policy any side effects, in particular unwanted ones?
well ok i kind of referred to that above. in case there should be a policy denying parking of assignments, i'd currently suggest to start with a slow-start-mechanism (e.g. aw), and evaluate the experiences after some while, whether such a mechanism turned out to be useful or unnecessary. btw: anyone interested in a workshop on this topic? kind regards, Chris Heinze
A
My point is not that your idea is wrong, but that you have to take into account a number of different issues...
certainly. i hope this is the right place for a discussion for these issues, and for finding good solutions for identified problems. :)
Can you be more specific on what the rules are for E.164 numbers in your neck of the woods?
that's germany. +49 numbers are in their regions fully portable between pstn providers. currently large regional blocks are reallocated by voip gateway providers to voip-users. so a voip-user from e.g. dresden can have a number from e.g. duesseldorf, hamburg, berlin, munich - or all of them. that's really ugly but voip providers actually have no big choice. there is a 'region' reserved for non-regional (in the end of course still national) numbers (+4932), but this is currently discussed and it's unlikely that this prefix will be useably anytime soon. also, there are strong doubts that this prefix will be freely available to voip-providers, the current discussion shows that there will probably be dependencies and drawbacks especially for voip.
Ah ..just like the US. We hear lots of barking by the US State Govt ( aka your Lander) on the allocation of "their numbers" by Vonage to out of region customers but the truth is there is nothing they can do about it. We're recovering so many phone numbers now from the system no one cares how they get allocated any more. I'm pretty sure I'll live to see Geographic portability in the US. Its technically its a trivial exercise.
kind regards,
Chris Heinze
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Richard, Richard Shockey wrote:
[...]
I'm pretty sure I'll live to see Geographic portability in the US. Its technically its a trivial exercise.
humm... sure? Not about the technical part, certainly - but about your assumptions in regards of the flexibility and ability to move when it comes to regulators and the like. I recently during a VoIP round-table raised that very questions to a rep from RegTP, the German regulator, whether in the wake of the +49.32 deliberations there are any first thoughts to get rid of area specific codes, i.e. enable geographic portability. The answer was a clear "No, nothing whatsoever". Later on, during a privat chat, I heard something like "It's still partly used for PSTN routing and also important for tariffing" - humm... And a really heretic thought: what about phone numbers becoming a commodity sometime in the future, as in: fully portable on a global scale? Cheers, -C.
At 01:04 PM 8/11/2004, Carsten Schiefner wrote:
Richard,
Richard Shockey wrote:
[...] I'm pretty sure I'll live to see Geographic portability in the US. Its technically its a trivial exercise.
humm... sure? Not about the technical part, certainly - but about your assumptions in regards of the flexibility and ability to move when it comes to regulators and the like.
Exactly .. but Wireless and VoIP are breaking down those barriers in the eyes of consumers so the questions are being asked in addition if you were a marketing director for a Incumbent land line Carrier looking how to keep your customer base ..its a tool you dont have now. Or as a eloquent New Yorker would put it " What the Fxxx do you mean I have to change my Fxxxxxx number. I'm moving from West 46th to West 82 you Fxxxxx moron!!" "I can get a cell phone and they will port the Fxxxxxx number!"
I recently during a VoIP round-table raised that very questions to a rep from RegTP, the German regulator, whether in the wake of the +49.32 deliberations there are any first thoughts to get rid of area specific codes, i.e. enable geographic portability. The answer was a clear "No, nothing whatsoever".
I imagine the silence was deafening. I can just see the little DT reps desperately trying to get the subject changed as fast a possible. " isnt it lunch time yet?"
Later on, during a privat chat, I heard something like "It's still partly used for PSTN routing and also important for tariffing" - humm...
PRECISELY .. the only justification for geographic codes is the artificial barriers of "rate centers" used for Tariffs Something your friendly national incumbent monopoly carrier does not want to talk about especially in front of regulators.
And a really heretic thought: what about phone numbers becoming a commodity sometime in the future, as in: fully portable on a global scale?
I think we'll all just dial via SIP URI before we see that happen <g>
Cheers,
-C.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
hi!
And a really heretic thought: what about phone numbers becoming a commodity sometime in the future, as in: fully portable on a global scale?
I think we'll all just dial via SIP URI before we see that happen <g>
hmmm - well if there were a global non-geographic e.164 space available... ;) kind regards, Chris Heinze
Richard Shockey wrote:
I recently during a VoIP round-table raised that very questions to a rep from RegTP, the German regulator, whether in the wake of the +49.32 deliberations there are any first thoughts to get rid of area specific codes, i.e. enable geographic portability. The answer was a clear "No, nothing whatsoever".
I imagine the silence was deafening. I can just see the little DT reps desperately trying to get the subject changed as fast a possible. " isnt it lunch time yet?"
Actually not. There was no DT rep on the stage at least - and the people there had no real ears for numbering issues in general (apart from bashing the lenghy process for +49.32), but were most concerned about DT's strong (> 90%) position in the DSL market, the lack of technical alternatives to it - such as cable - and insufficient LLU: you still have to get a PSTN (no damn mercy!) line if you want to have DT-based DSL. Even via a third party reseller...
Later on, during a privat chat, I heard something like "It's still partly used for PSTN routing and also important for tariffing" - humm...
PRECISELY .. the only justification for geographic codes is the artificial barriers of "rate centers" used for Tariffs Something your friendly national incumbent monopoly carrier does not want to talk about especially in front of regulators.
It was actually a rep from the regulator pointing that out. When I mentioned that there are carriers around already offering calls to any destination within the borders of the Federal Republic for 1.x cents a minute,so tariffing might not be a viable argument in the long run any longer - then I felt that deafening silence...
And a really heretic thought: what about phone numbers becoming a commodity sometime in the future, as in: fully portable on a global scale?
I think we'll all just dial via SIP URI before we see that happen <g>
Or this way, yes... ;-) Cheers, -C.
On 11 Aug 2004, at 18:04, Carsten Schiefner wrote:
I heard something like "It's still partly used for PSTN routing
I suppose in a large country there has to be a large amount of surviving legacy technology and provisioning procedures.
and also important for tariffing"
That's disappointing. Legacy tariffing suggests the relevant regulator is giving the incumbent too much slack. I wonder how the arrival of small, go-ahead "accession countries" will shake this status quo. Best regards, Niall O'Reilly
Niall O'Reilly wrote:
I wonder how the arrival of small, go-ahead "accession countries" will shake this status quo.
I'll allow myself to be pleasantly surprised... :-) -C.
How is this proposed +8787 different from the current +87810? (Other then the goverance portion?) -James Seng 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 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:
hi!
How is this proposed +8787 different from the current +87810? (Other then the goverance portion?)
visionng is set up as an organization to support its members. this is a different approach than the one of the RIRs which is aimed at the community of all internet users. visionng's aim is to support a set of specific technical solutions, it requires its members to adopt a specific technical framework that has been decided upon in the visionng context. the number space was probably requested by visionng because of the lack of available non geographic upts, managing such a number resource for the general public wasn't the aim. visionng does not actually focus on voip or the ip part alone, but also on PSTN networks and technology. also, i guess compared to the RIRs visionng generally cannot be seen as an open organization, it is not aimed at and probably can not provide for upts for the general public. visionng seems to be somebody who could profit from the proposed setup, as the numbers would be portable to and from pstn of visionng members. but if you wish to know more about visionng, it's certainly a beter idea to ask richard stasny. kind regards, Chris Heinze
participants (6)
-
Carsten Schiefner -
Chris Heinze -
James Seng -
Niall O'Reilly -
Patrik Fältström -
Richard Shockey