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

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

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
>
>-----Original Message-----
>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
>�������� >
>�������� >
>�������� >-----Original Message-----
>�������� >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: "James Seng" <[email-masked]>
Date: Fri, 02 Apr 2004 10:59:00 -0500

RE: [Iptel] FW: [Enum] Summary on NoPSTN dicussionIn our IP Telephony/ENUM
proof-of-concept, one of the things we demostrate is the ability to make a
IP->PSTN call in US and JP but only incuring only US-PSTN or JP-PSTN charges.

We did this by having a PSTN GW in US and also in JP. However, we do need to
do prior configuration on the dialing plan so that the SIP servers knows how
to route the call to US PSTGN-GW or JP PSTN-GW.

Obviously, it is kind of silly...because we arent really using ENUM strictly
speaking. And of cos, the "prior configuration" is not a scalable solution in
the long run.

I envision it is possible to have multiple services providers in various
countries who can route the call to PSTN, but there must be a more scalable,
seamless voice routing system, ie. I pick up a phone (IP or normal PSTN), dial
a number, and it just ring the other party. In other words, I agree with
Richard here.

How do this in a scalable, standard mechanism is going to be challenge...

But having said this, I am not sure [email-masked] is the appropriate forum to
discuss this.

-James Seng

----- Original Message ----- 
From: James McEachern
To: 'Michael Hammer'
Cc: 'Stastny Richard' ; [email-masked]
Sent: Friday, April 02, 2004 6:43 AM
Subject: 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
>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
>         -----UrsprÃ¼ngliche Nachricht----- 
>         Von: Michael Hammer
>         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
>         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.
>
>         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
>         >
>         >
>         >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
>         >
>         >
>         >
>         >
><https://www1.ietf.org/mailman/listinfo/enum>https://www1.ietf.org/mailman/li
stinfo/enum
>         >Iptel mailing list
>         >[email-masked]
><https://www.ietf.org/mailman/listinfo/iptel>https://www.ietf.org/mailman/lis
tinfo/iptel