Subject: [Sipping] Re: [Iptel] FW: [Enum] Summary on NoPSTN dicussion

From: Michael Hammer <[email-masked]>
Date: Fri, 26 Mar 2004 11:40:49 -0500

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
>
>_______________________________________________
>Iptel mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/iptel

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 29 Mar 2004 17:30:23 +0200

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]] 
	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,

	

	

	
	Mike

	>The discussion is going on the enum-list

��b�	��X��X��m����5��_��?�������+-�w��ȩ�)�N��+-����u�ޖ�fz{h~�^j�e�ƭ���}"RǬ����W�z{h��,r�n���y۟���z�b�{(�˫����*T��"�'�~��~��{^��h�g���r��H�