Subject: RE: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion

From: "James McEachern" <[email-masked]>
Date: Thu, 01 Apr 2004 21:07:09 -0500

If the E.164 number has been assigned to a SP providing a PATS, then the PSTN will (must - because of opt-in) always know how to route to the appropriate SP, and the SP in turn knows how to route to the device. If the number is an ENUM only number, then the PSTN will need to know this (both the fact that it is a valid number so it does not reject it, and the fact that it is an ENUM-only number so that it can route it to an ENUM enabled GW). The PSTN will be able to determine this using existing routing & translation techniques - nothing more is required.

So the entire problem comes down to how the VoIP network can recognize that a number is an "ENUM-only" number, and not route this to the PSTN if there is no ENUM entry. For all other cases routing to the PSTN works fine. This means that whatever solution we come up with, it is only necessary to apply it to ENUM-only numbers. (We *may* decide it is valuable to also apply it to other numbers, but if it complicates things this is not necessary.)

Am I missing something?

Jim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]] 
Sent: Thursday, April 01, 2004 3:58 PM
To: Pfautz, Penn L, ALABS
Cc: Stastny Richard; McEachern, James [CAR:5N00:EXCH]; [email-masked]
Subject: RE: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion

This sounds reasonable to me, but I would rather hear from the DNS experts.

My assumption, as you note below, was that if the number was not in ENUM, 
then the only element that knows whether the number is assigned and 
reachable is the operator PSTN-IP GW that has a configured translation or 
knows that the number is unassigned.

Mike

At 12:11 PM 4/1/2004 -0500, Pfautz, Penn L, ALABS wrote:
>If I understand it the root issue is this:
>All E.164 numbers will have a PSTN point-of-interface, but for some 
>numbers that POI is a gateway to IP. Further some subset of these numbers 
>are ones that won't be assigned if they're not reachable through IP. So, 
>in order to avoid routing to the default gateway after an ENUM query that 
>returns no result because the number is unassigned, people are seeking 
>some mechanism to provide a response to the initial ENUM query to indicate 
>that attempts to route through the PSTN will be fuitless. And the need is 
>to do this without treading on the opt-in principle.
>
>Here's a thought which the more DNS/DDDS literate may be able to confirm 
>or shoot down:
>At Tier 1, instead of populating an NS record with the tier 2 delegation 
>for each number instead populate a pair of non-terminal NAPTR records with 
>different service fields (e.g.,� E2U� and E2C) which would point to the 
>domains for the end user Tier 2 and carrier Tier 2 respectively. In this 
>way, a single query would provide pointers into both trees and a client 
>could decide whether to pursue one or the other, or potentially both. For 
>non-assigned "ENUM-only" numbers, the carrier could populate the E2C 
>record only without treading on the perogatives of the end user or having 
>to instantiate a separate Tier 1.
>Such E2C records could not only address the NoPSTN issue but also be the 
>basis for a carrier or infrastructure ENUM capability that may become more 
>important as VoIP moves beyond arbitrage to where IP interconnection 
>becomes norm.
>
>Penn Pfautz
>
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>Stastny Richard
>Sent: Thursday, April 01, 2004 2:36 AM
>To: Michael Hammer
>Cc: James McEachern; [email-masked]
>Subject: AW: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion
>
>
>Mike wrote:
>
>�������� >>First, no number is owner by anybody, it is assigned by ITU-T 
> to the NRA,
>�������� >>and assigned in turn to the SP, and the SP assignes it to the 
> end-user (for
>�������� >>geographic numbers. Service numbers are already assigned one-by-one
>�������� >>to the end-user by the NRA, no blocks, no anchor SP.
>
>�������� >How does this work for numbers that were assigned to an SP, that 
> used to be
>�������� >TDM-only, but then (over time) converts to an IP-only 
> network?� The SPs are
>�������� >very guarded about the E.164 numbers assigned to them.� That is 
> what I
>�������� >meant by "owned."� You are suggesting that when a person with a 
> phone
>�������� >number assigned by an SP moves to an IP-based "phone" that the 
> SP will
>�������� >relinquish that phone number back to the NRA?� Or are you saying 
> that
>�������� >number portability doesn't work between TDM and IP worlds?
>
>�������� We are talking here about four different things here:
>�������� Case 1:� a VoIP provider is also an ILEC (eg a cable operator) 
> and gets a
>�������� number (geographic) range (block) assigned and assignes them to 
> his users.
>�������� Since number assignement is technology independent, there is no 
> problem here,
>�������� as long as the SP is providing a telephony service as usual (we 
> call this PATS -
>�������� Publicly Available Telephony Service in Europe).
>�������� Note: some VoIP SP hide between small ILECs and get such number 
> ranges
>�������� via them (e.g Vonage, sipgate.de, ...)
>
>�������� Case 2: Since all normal rules apply, also LNP applies, so users 
> may port
>�������� their numbers back and forth between PSTN and VoIP SP
>
>�������� Case 3: The regulator reserves a special number range for VoIP 
> (050 in
>�������� Japan, 05x in UK, 032 in Germany). If these services are declared 
> non-PATS
>�������� NP does not apply (this is under discussion). In Japan there is 
> also a lighter
>�������� regime regarding QoS. Regulations differ here in all countries.
>�������� In this case the VoIP SP also get blocks of numbers and route 
> them to their GW.
>�������� I know, in the US there is no such number range. The problem I 
> have with
>�������� such an approach is that there are differnt rules in every 
> country and end-users
>�������� get restricted services. (e.g no NP, no access to emergence 
> services, etc.
>�������� IMHO this will cause problems in the future
>
>�������� Case 4. the regulator reserves a special number range for 
> ENUM-only routed
>�������� numbers. This should be done directly to the end-user. The 
> advantage is
>�������� that you have NP built-in, without having to deal with normal LNP 
> issues and
>�������� technology, saving the SP much effort.
>
>�������� The difference between case 3 and 4 is that in case 3 no rules 
> exist for NP and
>�������� interconnect on IP, so you create VoIP Island that are 
> interconnected only via
>�������� the PSTN per default. If you interconnect on IP, you can do this 
> only currently
>�������� with bilateral agreements. In case 4 you have automatically NP 
> and also interconnect
>�������� because you can use ENUM also on IP to interconnect. This is BTW 
> also drafted
>�������� in the SIP Forum Service Provider WG Interconnect Consensus.
>
>�������� >>With ENUM-only numbers there is no need to assign blocks of 
> numbers.
>�������� >>An ENUM-only number is the equivalent of a domain name. It is 
> assigned
>�������� >>to the end-user directly, who chooses the SP, like with a 
> service number.
>�������� >>You also do not assign domain names in blocks.
>
>�������� >I think there is an issue here.� If the SPs hold most of the 
> current NPA
>�������� >blocks, and there is a migration of many users from TDM to IP, 
> then do you
>�������� >lengthen the number to 11 digits to get more, or do the SPs have to
>�������� >relinquish numbers?
>
>�������� This a typical NANP problem. In the NANP there is only geographic 
> area
>�������� codes (with the exception of 800 numbers). In most other country 
> there are
>�������� more number types: you have geographic and non-geographic numbers.
>
>�������� Non-geo numbers are eg mobile numbers, personal numbers, etc. The 
> advantage
>�������� here is that you relieve the pressure on the number exhaust here. 
> Since geo
>�������� numbers are given away in blocks, you have a lot of unused numbers.
>�������� Eg in Austria the geo numbers are using up a great chunk of the 
> numbers:
>�������� we have 1100 4-digit area codes used be appox 4 Mio subscribers,
>�������� on the other hand, we have 5 (five) 3-digit mobile number ranges
>�������� used by 4,5 Mio subscribers (80% of them are behind 2 mobile 
> "area" codes).
>
>�������� The reason is simple: the mobile number ranges are flat. So if we 
> give eg
>�������� one 3-digit number range to ENUM, we can instantly use them with
>�������� additional 7-digits for 9.999.999 subscribers.
>
>�������� regards
>
>�������� Richard
>
>z{x%^zm?0'~ffX)ߣ

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 02 Apr 2004 00:04:02 -0500

I tried to work on you matrix:
Geo:          Y        N/A     N/A
PSTN:       Y        N/A     N/A
VoIP:         Y         Y         Y
ENUM:     opt-in  opt-in    only
 Case       1-2        3          4
 
but it does not help very much.
We are talking about requirements in Public User ENUM:
Must: if a number is in ENUM only, the client needs to know that is 
does not make sense to forward the call to the PSTN
 
We need to find a solution for this. IF this solutions allows also
to do additional things (depending on the solution found),
it would be nice to have:
-Indication that the number is not existing an the PSTN either (e.g unused number block)
-If the number is on VoIP (or PSTN), but not in ENUM, but can be reached via a "GW" on IP,
the domain name of the gateway where the number can be delivered via sip:[email-masked]
-If the number is on the PSTN, but ported, and the LNP is also accessible via IP (carrier 
ENUM) what is the root of the carrier ENUM (if publicly available). This may be tricky, if not.
 
But remember, these are nice to haves and need not to be solved, as long as the PSTN is there.
On the other hand, if we finally want VoIP to be selfcontaining and not rely on the PSTN, we have 
to find solutions for this 
 
Richard

	-----Ursprüngliche Nachricht----- 
	Von: Michael Hammer [mailto:[email-masked]] 
	Gesendet: Do 01.04.2004 17:58 
	An: Stastny Richard 
	Cc: James McEachern; [email-masked] 
	Betreff: Re: AW: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion

	Richard,
	
	So, if I might summarize what you have said, there are four attributes that
	result in different combinations:
	
	Geographic or not?    Y         N       N
	Public (NP) or not?   Y        Y/N      ?  (row: NP/regulatory requirements)
	VoIP or not?         Y/N        Y       Y
	ENUM or not?       opt-in?   opt-in?    Y
	                    Case 1-2  Case 3   Case 4
	                                       (NP inherent)
	
	There are probably 16 combinations, of which many don't make sense or
	aren't used.  I was unclear about whether being an ENUM number allowed you
	to opt in or out, i.e. what does an unlisted ENUM number mean.  It would
	greatly simplify things, if there were few combinations.
	
	But, this all comes down to routing based on configuration, database, or
	both.  And for calls to reach someone, one or the other must exist, even if
	only on the calling party's  terminal.
	
	Mike
	
	At 09:35 AM 4/1/2004 +0200, Stastny Richard wrote:
	>Mike wrote:
	>
	>         >>First, no number is owner by anybody, it is assigned by ITU-T
	> to the NRA,
	>         >>and assigned in turn to the SP, and the SP assignes it to the
	> end-user (for
	>         >>geographic numbers. Service numbers are already assigned one-by-one
	>         >>to the end-user by the NRA, no blocks, no anchor SP.
	>
	>         >How does this work for numbers that were assigned to an SP, that
	> used to be
	>         >TDM-only, but then (over time) converts to an IP-only
	> network?  The SPs are
	>         >very guarded about the E.164 numbers assigned to them.  That is
	> what I
	>         >meant by "owned."  You are suggesting that when a person with a
	> phone
	>         >number assigned by an SP moves to an IP-based "phone" that the
	> SP will
	>         >relinquish that phone number back to the NRA?  Or are you saying
	> that
	>         >number portability doesn't work between TDM and IP worlds?
	>
	>         We are talking here about four different things here:
	>         Case 1:  a VoIP provider is also an ILEC (eg a cable operator)
	> and gets a
	>         number (geographic) range (block) assigned and assignes them to
	> his users.
	>         Since number assignement is technology independent, there is no
	> problem here,
	>         as long as the SP is providing a telephony service as usual (we
	> call this PATS -
	>         Publicly Available Telephony Service in Europe).
	>         Note: some VoIP SP hide between small ILECs and get such number
	> ranges
	>         via them (e.g Vonage, sipgate.de, ...)
	>
	>         Case 2: Since all normal rules apply, also LNP applies, so users
	> may port
	>         their numbers back and forth between PSTN and VoIP SP
	>
	>         Case 3: The regulator reserves a special number range for VoIP
	> (050 in
	>         Japan, 05x in UK, 032 in Germany). If these services are declared
	> non-PATS
	>         NP does not apply (this is under discussion). In Japan there is
	> also a lighter
	>         regime regarding QoS. Regulations differ here in all countries.
	>         In this case the VoIP SP also get blocks of numbers and route
	> them to their GW.
	>         I know, in the US there is no such number range. The problem I
	> have with
	>         such an approach is that there are differnt rules in every
	> country and end-users
	>         get restricted services. (e.g no NP, no access to emergence
	> services, etc.
	>         IMHO this will cause problems in the future
	>
	>         Case 4. the regulator reserves a special number range for
	> ENUM-only routed
	>         numbers. This should be done directly to the end-user. The
	> advantage is
	>         that you have NP built-in, without having to deal with normal LNP
	> issues and
	>         technology, saving the SP much effort.
	>
	>         The difference between case 3 and 4 is that in case 3 no rules
	> exist for NP and
	>         interconnect on IP, so you create VoIP Island that are
	> interconnected only via
	>         the PSTN per default. If you interconnect on IP, you can do this
	> only currently
	>         with bilateral agreements. In case 4 you have automatically NP
	> and also interconnect
	>         because you can use ENUM also on IP to interconnect. This is BTW
	> also drafted
	>         in the SIP Forum Service Provider WG Interconnect Consensus.
	>
	>         >>With ENUM-only numbers there is no need to assign blocks of
	> numbers.
	>         >>An ENUM-only number is the equivalent of a domain name. It is
	> assigned
	>         >>to the end-user directly, who chooses the SP, like with a
	> service number.
	>         >>You also do not assign domain names in blocks.
	>
	>         >I think there is an issue here.  If the SPs hold most of the
	> current NPA
	>         >blocks, and there is a migration of many users from TDM to IP,
	> then do you
	>         >lengthen the number to 11 digits to get more, or do the SPs have to
	>         >relinquish numbers?
	>
	>         This a typical NANP problem. In the NANP there is only geographic
	> area
	>         codes (with the exception of 800 numbers). In most other country
	> there are
	>         more number types: you have geographic and non-geographic numbers.
	>
	>         Non-geo numbers are eg mobile numbers, personal numbers, etc. The
	> advantage
	>         here is that you relieve the pressure on the number exhaust here.
	> Since geo
	>         numbers are given away in blocks, you have a lot of unused numbers.
	>         Eg in Austria the geo numbers are using up a great chunk of the
	> numbers:
	>         we have 1100 4-digit area codes used be appox 4 Mio subscribers,
	>         on the other hand, we have 5 (five) 3-digit mobile number ranges
	>         used by 4,5 Mio subscribers (80% of them are behind 2 mobile
	> "area" codes).
	>
	>         The reason is simple: the mobile number ranges are flat. So if we
	> give eg
	>         one 3-digit number range to ENUM, we can instantly use them with
	>         additional 7-digits for 9.999.999 subscribers.
	>
	>         regards
	>
	>         Richard

��i��X��X����'�~����i����
bz���j)fj��b��?z{�

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 02 Apr 2004 03:38:14 -0500

Penn wrote:
 
>All E.164 numbers will have a PSTN point-of-interface, but for some numbers that POI is a gateway to IP. Further some >subset of these numbers are ones that won't be assigned if they're not reachable through IP. So, in order to avoid routing >to the default gateway after an ENUM query that returns no result because the number is unassigned, people are >seeking some mechanism to provide a response to the initial ENUM query to indicate that attempts to route through the >PSTN will be fuitless. And the need is to do this without treading on the opt-in principle.

Perfectly correct.

>Here's a thought which the more DNS/DDDS literate may be able to confirm or shoot down:
>At Tier 1, instead of populating an NS record with the tier 2 delegation for each number instead populate a pair of non->terminal NAPTR records with different service fields (e.g.,  E2U  and E2C) which would point to the domains for the end >user Tier 2 and carrier Tier 2 respectively. In this way, a single query would provide pointers into both trees and a client >could decide whether to pursue one or the other, or potentially both. For non-assigned "ENUM-only" numbers, the >carrier could populate the E2C record only without treading on the perogatives of the end user or having to instantiate a >separate Tier 1.

This proposal is IMHO very similar to the proposal of the shadow tree, because you would need separate
trees for user ENUM too (you cannot point with the E2U non-terminals NAPTRs in e164 .arpa, at least
not with the same number). If you leave e164.arpa as is (and we should do this for heavens sake ;-),
it could be implemented in the following way. You first query e164.arpa as usual, only if you do not find
an entry there, you go to the other tree. This tree is adminstrate by the same rules than e164.arpa.
You either find a normal NAPTR (e.g for unassigned blocks or ENUM-only blocks) , or a non-terminal NAPTR 
pointing to a separate tree. 
These trees could either be set up by counties as a whole or by carriers, this is a national matter.

>Such E2C records could not only address the NoPSTN issue but also be the basis for a carrier or infrastructure ENUM >capability that may become more important as VoIP moves beyond arbitrage to where IP interconnection becomes norm.

In the form above, yes.

Richard

-----Original Message-----

Mike wrote:

        >>First, no number is owner by anybody, it is assigned by ITU-T to the NRA,
        >>and assigned in turn to the SP, and the SP assignes it to the end-user (for
       
        >How does this work for numbers that were assigned to an SP, that used to be
        >TDM-only, but then (over time) converts to an IP-only network?  The SPs are
        >very guarded about the E.164 numbers assigned to them.  That is what I
        >meant by "owned."  You are suggesting that when a person with a phone
        >number assigned by an SP moves to an IP-based "phone" that the SP will
        >relinquish that phone number back to the NRA?  Or are you saying that
        
        We are talking here about four different things here:
        Case 1:  a VoIP provider is also an ILEC (eg a cable operator) and gets a
        number (geographic) range (block) assigned and assignes them to his users.
        Since number assignement is technology independent, there is no problem here,
        as long as the SP is providing a telephony service as usual (we call this PATS -
        Publicly Available Telephony Service in Europe).
        Note: some VoIP SP hide between small ILECs and get such number ranges
        via them (e.g Vonage, sipgate.de, ...)
        
        Case 2: Since all normal rules apply, also LNP applies, so users may port
        their numbers back and forth between PSTN and VoIP SP
        
        Case 3: The regulator reserves a special number range for VoIP (050 in
        Japan, 05x in UK, 032 in Germany). If these services are declared non-PATS
        NP does not apply (this is under discussion). In Japan there is also a lighter
        regime regarding QoS. Regulations differ here in all countries.
        In this case the VoIP SP also get blocks of numbers and route them to their GW.
        I know, in the US there is no such number range. The problem I have with
        such an approach is that there are differnt rules in every country and end-users
        get restricted services. (e.g no NP, no access to emergence services, etc.
        IMHO this will cause problems in the future
        
        Case 4. the regulator reserves a special number range for ENUM-only routed
        numbers. This should be done directly to the end-user. The advantage is
        that you have NP built-in, without having to deal with normal LNP issues and
        technology, saving the SP much effort.
        
        The difference between case 3 and 4 is that in case 3 no rules exist for NP and
        interconnect on IP, so you create VoIP Island that are interconnected only via
        the PSTN per default. If you interconnect on IP, you can do this only currently
        with bilateral agreements. In case 4 you have automatically NP and also interconnect
        because you can use ENUM also on IP to interconnect. This is BTW also drafted
        in the SIP Forum Service Provider WG Interconnect Consensus.

        >>With ENUM-only numbers there is no need to assign blocks of numbers.
        >>An ENUM-only number is the equivalent of a domain name. It is assigned
        >>to the end-user directly, who chooses the SP, like with a service number.
       
        >I think there is an issue here.  If the SPs hold most of the current NPA
        >blocks, and there is a migration of many users from TDM to IP, then do you

        This a typical NANP problem. In the NANP there is only geographic area
        codes (with the exception of 800 numbers). In most other country there are
        more number types: you have geographic and non-geographic numbers.

        Non-geo numbers are eg mobile numbers, personal numbers, etc. The advantage
        here is that you relieve the pressure on the number exhaust here. Since geo
        numbers are given away in blocks, you have a lot of unused numbers.
        Eg in Austria the geo numbers are using up a great chunk of the numbers:
        we have 1100 4-digit area codes used be appox 4 Mio subscribers,
        on the other hand, we have 5 (five) 3-digit mobile number ranges
        used by 4,5 Mio subscribers (80% of them are behind 2 mobile "area" codes).

        The reason is simple: the mobile number ranges are flat. So if we give eg
        one 3-digit number range to ENUM, we can instantly use them with
        additional 7-digits for 9.999.999 subscribers.
       
        regards

        Richard

z{x%^zm? 0'~ffX)ߣ

��j)b�	b�ק�h���+�m����5��_��?�������+-�w����

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 02 Apr 2004 03:38:21 -0500

Jim,
Public ENUM is currently being deployed and progressing nicely. Carrier ENUM
is still in a nascent state and only within islands. I do not see any progress to make
IP-IP calls routable on a global scale with carrier ENUM. If we find a workable
solution here, public ENUM could serve as a means to glue the carreir ENUM together.
 
Richard

	-----Ursprüngliche Nachricht----- 
	Von: James McEachern [mailto:[email-masked]] 
	Gesendet: Fr 02.04.2004 00:43 
	An: 'Michael Hammer' 
	Cc: Stastny Richard; [email-masked] 
	Betreff: RE: [Iptel] FW: [Enum] Summary on NoPSTN dicussion

	Mike, 
	I certainly don't want to curb your desire to get calls onto the IP network as soon as possible... 

	I don't think the PSTN-to-IP GW needs to know the mapping to every telephone number in the world to route it using IP. If the number is assigned to a Service Provider using techniques like those used today, then the GW should be able to know which SP the number maps to - and route on that basis. This could be done with Carrier ENUM, or with traditional routing and translations - either one could work. There is no reason whatsoever why "PSTN routing" cannot select IP "trunks" to another VoIP network. (Of course this would not be true for ENUM-only numbers.)

	Public ENUM (in those cases where the subscriber has opted-in) can accelerate and refine this, but there is no reason to wait for it to get started moving to end-to-end IP.

	Jim 

	-----Original Message----- 
	From: Michael Hammer [mailto:[email-masked]] 
	Sent: Tuesday, March 30, 2004 5:47 PM 
	To: McEachern, James [CAR:5N00:EXCH] 
	Cc: 'Stastny Richard'; [email-masked] 
	Subject: RE: [Iptel] FW: [Enum] Summary on NoPSTN dicussion 

	James, 

	I guess I have to curb my desire to get the call onto the IP network as 
	soon as possible rather than as late as possible. 

	In today's environment, I think we have pockets of IP networks 
	interconnected by the global PSTN.  One of the characteristics of the PSTN 
	is that I can dial a number from anywhere in the world and it will get 
	routed to the destination where that number resides.  When going from PSTN 
	to IP, it might be expected that the PSTN-IP GW has all the telephone 
	number to SIP/IP address mappings associated with that IP pocket 
	provisioned into it. 

	Now reverse the situation.  We have pockets of TDM interconnected to the 
	"Network".  A user in that TDM pocket dials a number it goes to a nearby 
	gateway and then routed to anywhere in the Network.  I don't expect that 
	gateway to have a mapping from all of the telephone numbers in the world to 
	a SIP or IP address in the IP domain.  So, given only a telephone number, 
	how do I get routing information for the IP domain?  I assumed the ENUM 
	database would get them started on doing that translation, or at least 
	going in the right direction. 

	I don't see that this changes opt-in.  What it probably does mean is that, 
	lacking any ENUM entry, the call must be routed mostly through the PSTN to 
	the (one?) GW that has a mapping to the called party in the last IP 
	domain.  That is likely to delay crossing into the IP domain, be a more 
	expensive call, and one which perpetuates the TDM backbone. 

	I was also conjecturing what it means to "own" a telephone number.  In the 
	PSTN, the number is owned by the SP and assigned to an end-user.  The LNP 
	rulings stretch that a bit by allowing a number to be carried to another 
	SP, but technically it is still owned by the original carrier.  If it is 
	ever given up, it reverts back to that carrier.  How is this going to work 
	in IP?  Are E.164 number blocks going to be assigned to an ITSP?  Does a 
	TDM carrier that becomes an ITSP get to move them over without 
	restriction?  Could an ITSP own a block of numbers, yet have no GW to the 
	PSTN?  Are there going to be restrictions on how the network evolves? 

	I would hope that even if an individual number was unlisted, if a block of 
	numbers belonged to an ITSP, there would be a higher-level node entry in 
	the ENUM tree, and the call could be routed to an IP-GW, which might have 
	additional information to route the call, or at least determine that the 
	number is unassigned. 

	I confess I have not been watching the ENUM list, but perhaps should 
	join.  My apologies if this has all been figured out. 

	Mike 

	At 03:59 PM 3/30/2004 -0500, James McEachern wrote: 

	>Mike, 
	>In your email you state: 
	> 
	>---snip--- 
	>The difference is in the interpretation of a lack of a record.  In LNP, it 
	>would mean that the E.164 number is still owned by the original switch, 
	>whereas in ENUM it would mean that the E.164 number is not route-able to 
	>an IP endpoint.  From a TDM perspective, the entire IP domain could be 
	>viewed as a single switch and the LNP routing scheme should work.  The 
	>converse (when records exist) could be true for ENUM. 
	> 
	> 
	>A gateway between IP-domain and TDM domain, upon seeing that both an LNP 
	>and an ENUM dip have not resolved the route, can safely conclude that the 
	>number is unassigned and release the call." 
	> 
	>---end snip--- 
	> 
	>This seems to suggest that routing to an IP endpoint would require an ENUM 
	>entry - otherwise the gateway could safely assume the number is 
	>unassigned. Do you really mean this? What would this do to opt-in? 
	> 
	>Thanks 
	>Jim 
	> 
	>From: Stastny Richard 
	>[<mailto:[email-masked]>mailto:[email-masked]] 
	>Sent: Monday, March 29, 2004 10:30 AM 
	>To: Michael Hammer 
	>Cc: [email-masked]; [email-masked]; [email-masked] 
	>Subject: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion 
	> 
	>Hi Michael, 
	> 
	>We are trying to find a solution for the following scenarios: 
	>A. An E.164 number range is only available and routable in ENUM 
	>B. An E.164 number range is available via PSTN and via IP 
	>C. An E.164 number range is not assigned at the PSTN 
	> 
	>If in cases A and B an entry is existing in ENUM, no problem. 
	>If the query returns NXDOMAIN, the problem arises for the 
	>querying server how to proceed. 
	> 
	>In case A the server must not forward the call to the PSTN, because 
	>a loop may be created. In cases B and C it may forward the call (no harm) 
	>but it is not necessary. In case B the server could terminate the call on IP, 
	>in case C the server could say number not available and not bother the 
	>PSTN at all. 
	> 
	>If we find a solution that covers A, B and C may be covered as well. 
	> 
	>I agree that in future call routing may be improved further in access 
	>to LNP servers on the PSTN is available and also if access to ENUM 
	>is available on the PSTN (some carriers are already working on this), 
	>but this will take some time. 
	> 
	>We should also come up with a sself-containing solution on IP and 
	>not always rely on the PSTN. 
	> 
	>regards 
	>Richard 
	> 
	>         -----UrsprÃ¼ngliche Nachricht----- 
	>         Von: Michael Hammer 
	> [<mailto:[email-masked]>mailto:[email-masked]] 
	>         Gesendet: Fr 26.03.2004 17:40 
	>         An: Stastny Richard 
	>         Cc: [email-masked]; [email-masked] 
	>         Betreff: Re: [Iptel] FW: [Enum] Summary on NoPSTN dicussion 
	> 
	> 
	> 
	>         Richard, 
	> 
	>         Going out on a limb here, since I have not seen all the referenced 
	>         discussions.  My first impression is that the description below 
	> is overlay 
	>         complex. 
	> 
	>         I have a concern that you appear to be proposing that the ENUM 
	> dip would 
	>         have definitive answers to: 
	>         a) whether a number has been assigned and therefore rout-able, 
	>         b) whether a number that is assigned was done, and if so whether 
	> to a PSTN 
	>         endpoint or an IP endpoint. 
	> 
	>         Another concern is that, if you do get looped routing between the 
	> IP domain 
	>         and the TDM domain, this is likely an indication of a lack of 
	>         synchronization between the ENUM database and the LNP 
	> database.  One or the 
	>         other has incorrect data.  I suspect that there may be time lags 
	> from when 
	>         an SP assigns a number and when it gets reflected in one or another 
	>         databases.  If you want the ENUM and LNP databases to be somewhat 
	>         independent, you might want a loose coupling of the use of the 
	> two systems: 
	> 
	>           -If endpoint is TDM, then the ENUM database should point to the 
	> PSTN, 
	>         with default behavior being, if unknown to ENUM, send to PSTN to 
	>         resolve.  (Note this is orthogonal to ENUMs use to select 
	> alternative 
	>         endpoints.) 
	> 
	>           - If endpoint is IP, then the LNP databases should point to the IP 
	>         domain, with default behavior being, if unknown to LNP, route in 
	> the PSTN 
	>         to resolve. 
	> 
	>         The difference is in the interpretation of a lack of a 
	> record.  In LNP, it 
	>         would mean that the E.164 number is still owned by the original 
	> switch, 
	>         whereas in ENUM it would mean that the E.164 number is not 
	> route-able to an 
	>         IP endpoint.  From a TDM perspective, the entire IP domain could 
	> be viewed 
	>         as a single switch and the LNP routing scheme should work.  The 
	> converse 
	>         (when records exist) could be true for ENUM. 
	> 
	>         A gateway between IP-domain and TDM domain, upon seeing that both 
	> an LNP 
	>         and an ENUM dip have not resolved the route, can safely conclude 
	> that the 
	>         number is unassigned and release the call. 
	> 
	>         Actually, it may not be necessary to send a setup message to a 
	> GW, nor is 
	>         it necessary to have the ENUM and LNP databases duplicate each 
	> other.  It 
	>         should be sufficient for an ENUM DB to query the LNP DB and 
	> respond with an 
	>         appropriate answer, or the converse. 
	> 
	>         Mike 
	> 
	> 
	>         At 04:22 PM 3/25/2004 +0100, Stastny Richard wrote: 
	>         >Cross posting from [email-masked] 
	>         >The discussion is going on the enum-list 
	>         > 
	>         >Richard Stastny 
	>         >OeFEG 
	>         >+43 664 420 4100 
	>         > 
	>         > 
	>         >From: Stastny Richard 
	>         >Sent: Thursday, March 25, 2004 1:08 PM 
	>         >To: Marian Durkovic; [email-masked] 
	>         >Cc: [email-masked] 
	>         >Subject: [Enum] Summary on NoPSTN dicussion 
	>         > 
	>         >Dear colleagues, 
	>         > 
	>         >There was a lot of discussions on-list and off-list on this issue, 
	>         >so I will try to summarize at least my view of the problem. 
	>         >I will also include my current view on the ;enumdi 
	>         >and the ;pstn indicator for the tel: URI 
	>         > 
	>         >ENUM-enabled UAs and Servers are currently processing 
	>         >received E.164 numbers (either in a tel:+xxx URI or in a sip: URI 
	>         >in the format sip:[email-masked];user=phone) in the following way: 
	>         >(for simplicity I am only dealing with voice calls) 
	>         >Please holler if I got something wrong or you disagree 
	>         > 
	>         >1. Query ENUM (in e164.arpa) 
	>         > 
	>         >2. if a NAPTR is found with an "enumservice" sip or voice:sip, 
	>         >handle the call as if you have received a sip: URI in the format 
	>         >sip:[email-masked] in the first place. 
	>         > 
	>         >3. If a NAPTR is found with an "enumservice" voice:tel 
	>         >3a. and the tel: URI is pointing to a different number, 
	>         >query ENUM again for this number 
	>         >3b. if the tel: URI is the same as the AUS, forward the 
	>         >call to the PSTN, if you are able to do so. 
	>         > 
	>         >Note: here the proposed ;pstn indicator may come in handy: 
	>         >In 3a you may use it in the NAPTR to prevent a second ENUM-query 
	>         >and force the call to the PSTN. 
	>         >In 3b the server may add ;pstn to inform the next proxy about 
	>         >The decision to force the call to the PSTN. On the other hand, 
	>         >In this case also the ;enumdi indicator may be used just to prevent 
	>         >an ENUM query. Result: ;pstn is used in ENUM - ;enumdi is used in 
	>         >signalling. 
	>         > 
	>         >4. Now the real problem starts: If the ENUM-query returns NXDOMAIN, 
	>         >the current assumption of all clients is: the call is routed to the 
	>         >PSTN if the server is able to do so (eventually with the ;enumdi 
	> set. 
	>         > 
	>         >This means, we refer the problem to the PSTN. This is not nice for 
	>         >various reasons: 
	>         >1. we are bothering the PSTN in some cases unnecessarily 
	>         >2. the PSTN may not know what to do either and bounce the 
	>         >call back, which is creating loops 
	>         >3. and finally: what are we doing if there is no PSTN anymore ;-) 
	>         >Ok, this seems far reached, but Internet Telephony should be 
	> finally 
	>         >self-containing. 
	>         > 
	>         >So what are the additional policies we may want to tell an ENUM- 
	>         >client? 
	>         > 
	>         >1. No such number (unassigned number) 
	>         >1a. The whole number range (number block)is unassigned 
	>         >1b. There are numbers assigned in this number range, but if you 
	>         >do not find one in ENUM, you also will not find one on the PSTN, so 
	>         >it makes no sense to route it to the PSTN (ENUM-only) 
	>         >2. Default routing for the whole number range (number block) to 
	> a VoIP 
	>         >gateway. 
	>         >2a. The whole block is routed, there are no individual entries 
	> in ENUM 
	>         >(e.g. 1-800 numbers) 
	>         >2b. There are numbers in ENUM, but if you do not find an entry, 
	> route 
	>         >the call to the default gateway given. One example for this case 
	> may be 
	>         >a VoIP provider operating an island only connected to the PSTN. 
	> Some 
	>         >of the users are also in ENUM (opt-in). If he provider now opens 
	> up access 
	>         >to the Internet via a gateway (border element, ...), he may want 
	> to route 
	>         >all calls for his users not in ENUM to the gateway provided by 
	> default 
	>         > 
	>         >Case 1a and 2a can be dealt with in e164.arpa with wildcards, 
	> because no 
	>         >Additional entries below exist. 
	>         >Case 1b and 2b cannot be dealt within e164.arpa, because 
	> wildcards do 
	>         >not support this. 
	>         > 
	>         >The solutions proposed for this sofar are. 
	>         > 
	>         >A. use tables in each server. This is not a good idea and does 
	> not help 
	>         >ENUM-enable UA. The information should be stored in a global 
	> accessible 
	>         >and public database (DNS). 
	>         > 
	>         >B. use a (one, common) second common tree (e164shadow.arpa, 
	> where you put 
	>         >in only the wildcards for the number ranges in question. The 
	> processing 
	>         >assumption now should be: 
	>         > 
	>         >If the ENUM-query returns NXDOMAIN, the call is not routed to 
	> the PSTN 
	>         >In any case, the server queries e164shadow.arpa, and only if no 
	> entry 
	>         >is found there, the call is routed to the PSTN. The management and 
	>         >delegation procedures of the tree are the same as for e164.arpa. 
	>         >The second tree would contain only wildcard NAPTR RR for number 
	> ranges 
	>         > 
	>         >This would be the optimal solution proposed sofar. The problem 
	> is that 
	>         >a common agreement and a definition on the second tree is 
	> necessary. 
	>         > 
	>         >C. Use individual second shadow trees, eg on a national level, 
	> eg in 
	>         >Austria e164shadow.at would be used. The problem here is how one 
	> can 
	>         >find out the domain names of the individual trees. 
	>         >One solution is to do it with a table in each server (which is 
	> not good). 
	>         > 
	>         >The other solution is to put pointers in e164.arpa, eg SRV RR or 
	> even MX RR. 
	>         >The MX record would give eg the root of the other tree, and each 
	> tree 
	>         >would be structured in the sane way like e164.arpa, so the same 
	> algorithms 
	>         >can be used. 
	>         > 
	>         >Since the structure of the delegations in e164.arpa varies (Tier 
	> 1 levels), 
	>         >there is no easy way to find out the level of the pointers, even 
	> if they are 
	>         >only on the Tier 1 layer. 
	>         > 
	>         >It was proposed to search either top down (faster) or bottom up 
	> (more 
	>         >flexible), because this would allow sub-policies in number ranges. 
	>         > 
	>         >D. Are there additional possibilities or proposals? 
	>         > 
	>         >Finally I come to the last issue: 
	>         > 
	>         >For case 1a and 1b above (no such number) an "enumservice" is 
	> necessary 
	>         >to indicate that there exists no such number, neither in ENUM 
	> nor on the 
	>         >PSTN. 
	>         > 
	>         >Proposals sofar are: 
	>         > 
	>         >Use a special flag e.g. "n" or "v" 
	>         >Use a "enumservice" e.g. "E2U+NONE" or "E2U+VOID" or only "VOID" 
	>         > 
	>         >Also here additional proposals are invited. 
	>         > 
	>         >Best regards 
	>         > 
	>         >Richard 
	>         > 
	>         > 
	>         > 
	>         > 
	>         >_______________________________________________ 
	>         >enum mailing list 
	>         >[email-masked] 
	> 
	 > ><https://www1.ietf.org/mailman/listinfo/enum>https://www1.ietf.org/mailman/listinfo/enum 
	> 
	>         > 
	>         >_______________________________________________ 
	>         >Iptel mailing list 
	>         >[email-masked] 
	> 
	 > ><https://www.ietf.org/mailman/listinfo/iptel>https://www.ietf.org/mailman/listinfo/iptel 
	> 
	> 
	> 
	> 
	>z{x%^á¦žzrmá¨¶? 
	>0u'~ffX)n 

	_______________________________________________ 
	enum mailing list 
	[email-masked] 
	https://www1.ietf.org/mailman/listinfo/enum

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 07 Apr 2004 05:14:00 -0400

Jeff wrote
>This is not a good thing.  It is not because the security and privacy
>issues with "Registered Only" ENUM numbers is significant.

Please do not make such cryptic statements.
Could you please elaborate more in detail what the significant security/privacy
issue(s) is /are with ENUM-only numbers in your opinion?

Richard

§ºišŠX§‚X¬µéîš'~Šà†Ûi³ÿðÃ
bz×è®æj)fjåŠËb�ú?z{¦