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

From: "Stastny Richard" <[email-masked]>
Date: Thu, 25 Mar 2004 16:22:29 +0100

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

_______________________________________________
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: Juha Heinanen <[email-masked]>
Date: Thu, 25 Mar 2004 18:05:27 +0200

> a common agreement and a definition on the second tree is necessary.

this makes sense to me.  once management of the normal e164.arpa tree
has been agreed for a particular country, e164shadow.arpa should be a
trivial extension.

-- juha