Subject: [Enum] Additional Information in ENUM and the tel: PSTN-Indicator

From: "Stastny Richard" <[email-masked]>
Date: Wed, 14 Apr 2004 10:53:02 -0400

Dear Colleagues,

I apologize in advance for posting this to both lists, but I think
both ENUM and IPTEL are involved. I would suggest posting any
replies only on the ENUM list.

Abstract:

This e-mail describes a solution to issues discussed
on this list regarding putting additional information in ENUM
(e164.arpa).
The solution is required for ENUM-driven numbers, but may also be
used for additional purposes. The solution may also be used in other
ENUM-like applications.

The solution may either be submitted as a separate ID or may be included
in the currently work-in-progress BCP on ENUM. This proposal will
also be submitted to ETSI to be included in V2 of TS 102 172.

The solution contains also a proposed change to the NAPTR
syntax (the "v" or *void* flag) and an additional parameter for the 
tel: URI (;pstn)

Problem statement:

In RFC2916bis, RFC3403 and ETSI TS 102 172 it is well
defined how an ENUM client should react if an E.164 number
is queried in ENUM DNS (e164.arpa) for NAPTR and how this
NAPTR should be processed. 

On the other hand, it is currently not clearly defined what
should happen if the result of the query is NXDOMAIN.

The current assumption is that if the UAC wants to establish a 
voice call, the call is routed by default to the PSTN, if the UAC
or server is capable of doing so. 

The underlying assumption here is the following:
since ENUM is opt-in, the number dialed may either exist on the
PSTN or the PSTN will know that the number does not exist.
This may not be very efficient in all cases, but it works.

This is no longer true with *ENUM-driven* E.164 numbers.
 
ENUM-driven E.164 numbers are defined in number ranges 
existing only in ENUM. Numbers within of these number-ranges are
not terminated on the PSTN, but routed forward to an ENUM-enabled 
gateway. The ENUM-enabled gateways are querying ENUM to route
the call further to its termination on the Internet. Within these
number-ranges numbers may not be assigned (yet), but the gateway
has in this case not the option to route the call further (back) to
the PSTN. 

It is therefore required in this case to provide the ENUM clients
(at least the ENUM-clients in the gateways) with an additional
information, to prevent them from routing these calls to the PSTN.

Note: Since ENUM-enabled clients may route the call
immediately to the PSTN (e.g. via an FXO-port), the solution
must be simple, related or near to ENUM (e164.arpa) and using 
similar algorithms (e.g. using NAPTR records).

In addition, it would be nice to be able to signal 
the found-out facts to other servers during the signalling path, 
to prevent them from making unnecessary queries to ENUM.

It would also be nice to be able to re-use possible 
solutions for other purposes.

So what are the requirements?

The basic requirement is the following:
If an ENUM client queries ENUM for a given fully
qualified E.164 number and this number is not contained
within e164.arpa, the DNS query returns NXDOMAIN.

For ENUM-driven number ranges it SHALL be possible to
provide the ENUM client with an additional information
how to handle the call (that is: the number is not assigned)

For ENUM opt-in number ranges it would be nice in some
cases to be able provide additional information.

These cases could be (not taxative):
- the number is a DDI number out of a number range assigned
to a PBX (the additional information may point to the switchboard).
- the number range is also not existing on the PSTN 
(number not assigned).
- the number range is operated by telephony service provider
providing a gateway (border element) to the public Internet.
(the additional information may point to this gateway)
- the number range is operated via a LNP or 800 database (ffs).

Note: It was also proposed to use these solutions to point
to carrier or infrastructure ENUM trees. IMHO this should
not be done, considering that we are talking only
about User ENUM. User clients will not be able to access
carrier ENUM. In addition, it is not clear yet if and how
carrier ENUM will be implemented. This issue it therefore 
currently out-of-scope or ffs.

The following questions need to be answered:
1.How and where to place the information in ENUM?
2.In which format the information is placed in ENUM?
3.How the signal this information to other servers?

Possible solutions:

1. How and where to place the information in ENUM?

During the discussion on the list several proposals
have been brought forward:

- use wild cards
- populate the ENUM database with all possible numbers
- create one or more additional trees (shadow tree)
- use the SOA response given back with NXDOAMIN

I do not want to repeat the full discussion here,
but the essence of the discussion was:

-wildcards do not work as intended and necessary

-populating ENUM with all possible numbers is not a good idea 
and also would not work in cases with variable number length.

-creating more then one shadow tree and placing pointers
to these trees in e164.arpa would also not solve the primary
problem: where to put these pointers and how to find them.

-creating one second shadow tree is a valid option,
allowing to wildcard NAPTRs in the second tree for a given number
range, but it would not allow to nest this information.
In addition, a second tree was considered *nasty* by some
participants and it would also require a global agreement,
stirring up all bodies again concerned with e164.arpa.

-this leaves the usage of the SOA response in NXDOMAIN. 
This solution also would require only minor changes
in ENUM administration and also in the clients.

Where and how is the additional information derived from ENUM?

This proposal (from Jim Reed) uses the additional information that's in 
the NXDOMAIN response. This response will include the SOA record 
for the zone enclosing the name that was looked up. The name 
of that zone can be looked up to get a NAPTR for a default SIP gateway
or whatever. 

An example might clarify this.

Consider the non-existent phone number 1234567890.

An ENUM lookup of 0.9.8.7.6.5.4.3.2.1.e164.arpa returns NXDOMAIN. 
The response includes a SOA record for 5.4.3.2.1.e164.arpa -- the 
enclosing zone for this name. This will be in the Authority Section 
of the reply. In other words, the name servers for 5.4.3.2.1.e164.arpa 
are saying 0.9.8.7.6.5.4.3.2.1.e164.arpa doesn't exist. If I then lookup

5.4.3.2.1.e164.arpa, this could have a NAPTR that gives me the name of a

SIP gateway that will do the Right Thing for 1234567890.

It can also be used for number-ranges like 800 and 900 numbers or DDI
blocks. 
Calls to these numbers will get shunted to the right "gateway". 
This does of course make things a little bit trickier for a Tier-1
registry that delegates every individual E.164 number.

Below is a complete example how such a query may be 
implemented in an ENUM client.

2. In which format the information is placed in ENUM?

Basic requirement: all information shall use NAPTR records

What kind of information could be provided:

A. This E.164 number does not exist.
Proposal: use the "v" flag (for void)
Example: IN NAPTR 10 10 "v" "E2U"
In this case the call is not routed further and
"No-such number" is returned by the client

B. Use a normal NAPTR pointing to a sip: or h323: URI

This could be used either to point to the switchboard of
a PBX or to a gateway provided for a numbering block
by an service provider.

Note: if e.g. only a NAPTR is provided for h323 and the 
client is only capable of doing SIP, the call may also
be forwarded to the "PSTN".

3. How does the UAC or server signal this information to other servers?

Discussion:
If a client or server has queried ENUM for an E.164 number, 
the following outcomes are possible:

a.the client has found a sip: or h323: URI, so the
next proxy sees an address-of-record anyway.

b.the query has returned a tel: URI and the client
has done a second ENUM query for this E.164 number,
also retrieving an address-of-Record (or has
got an indication in the tel: URI to route the call to the "PSTN",
see below).

c. the client has queried ENUM, found no result and has
DECIDED to route the call to the PSTN.

d. the client has NOT done an ENUM query, because
the end-user has explicitly prohibited this, e.g. by
entering a special service (access) code.

So the client (or server) is sending either a 
sip: or h323: URI to the next proxy or an E.164
number only with the intention to forward it
to the PSTN. Only if the client is not capable
of doing an ENUM query, it may send an E.164 number
otherwise.

So sending an enum-dip-indicator seems not very useful.
What is required instead is sending a "force-to-pstn"
indicator.

It is therefore proposed to add a ;pstn indicator to
the tel: URI. 

The ;pstn indicator is attached to a tel: URI (or an
equivalent sip: URI in the following cases:

1.The user has explicitly entered an agreed upon access
code to force the call to the PSTN

2. The ENUM query has retrieved a tel: URI with a ;pstn
indicator

3. The ENUM query has retrieved no result (NXDOMAIN) in
all above cases.

A server receiving such a tel: URI MUST forward the call
to a server capable of PSTN routing or MUST be able to 
to PSTN routing by itself (either via carrier ENUM or by routing
the call to the PSTN via a gateway). If the server or the UA
is not capable of doing so, it must return *no such service*

So what is finally the new procedure for an ENUM client?

Complete walkthrough:
 
For sake of simplicity, let's assume a pure
voice call, e.g. from a phone on a terminal adapter:
 
Assumptions: the system (server or TA) is able to:
A. set up a voice call
B. respond with "no such service" (e.g trunk busy)
C: respond with "no such number" (e.g. SIT)
 
Start: The user is dialing a number, the UAC is normalizing this
number into an E.164 number and the ENUM client is querying the 
E.164 number in e164.arpa:

1. It gets back one or more NAPTRs, one of them is usable to
set up a voice call -> done.
 
2. It gets back some NAPTRs, none of the is usable to
set up a voice call -> response: "no such service"
 
3. It gets back NODATA -> response: "no such service"

Note1: 2. and 3. is currently handled in a different way: the system
tries to set up a call to the PSTN!
(I myself used this to force a call to my mobile phone)

Note2: The only way in future to force a call to the PSTN
in this case would be to explicitly provide a NAPTR
with voice:tel and a tel: URI pointing to the same (or
a different number), preferable with tel:+xxx;pstn,
(which makes sense anyway)
 
4. It gets back NXDOMAIN
4a. It now queries the domain given back in the SOA response
for NAPTR.
4b. It does not get the enclosing domain back in the SOA response
because of a broken or out-date DNS implementation -> the call
is routed to the PSTN.
 
5. It gets back a NAPTR:
5a. the flag field is "v" -> response: "no such number"

Note3: this implies that ENUM-driven number ranges
SHALL contain always a NAPTR with flag "v" on top!!

5b. the NAPTR is not usable for voice calls
-> response: "no such service"?

5c: the NAPTR is usable for voice and is a simple URI 
(no regexp) -> set up call, done

5d. the NAPTR is usable for voice and contains
a regexp (no comes the tricky part)
the regexp has to be evaluated with the original
AUS from the first query!
-> set up call, done
 
6. It gets back NODATA
-> set up call with tel:+xxx;pstn,
where xxx is the AUS from the original ENUM query

Note4: this would be equivalent if a
NAPTR containg enumservice E2U+voice:tel
and tel:/1;pstn was retrieved.
 
7. It gets back NXDOMAIN -> something is 
seriously wrong ;-)

Final remark:

There is a minor problem with this approach indofar,
that some (very out-dated) DNS applications still do
not support this feature.

Quote from Jim Reed:

[Any sane DNS implementation will return a SOA record in the
Authority Section of an NXDOMAIN reply. This is required by RFC2308.
>
> 3 - Negative Answers from Authoritative Servers
>
>    Name servers authoritative for a zone MUST include the SOA record
of
>    the zone in the authority section of the response when reporting an
>    NXDOMAIN or indicating that no data of the requested type exists.
>
A DNS implementation that doesn't implement RFC2308 is broken and/or
very, very old. These should not be found or deployed in the ENUM
system. - end quote]
 
On the other hand the procedure is designed in such a way
that as a default (if the enclosing domain is not returned)
the call is forwarded to the PSTN.
 
This does not really hurt in the most cases, only in case of 
ENUM-driven number ranges. In this case the mandatory
requirement would be that at least the generic gateways must
live in a DNS-foodchain capable of returning the enclosing domain,
which should be doable.

Summary:

What needs to be done:
Include the above procedure in a BCP
Define the *void* flag in an RFC
Define the ;pstn indicator for tel: in an RFC

Best regards
Richard

> Richard Stastny
OFEG
Osterreichische Fernmeldetechnische Entwicklungs- und
Forderungsgesellschaft mbH
Buroadresse: Arsenal Objekt 24, 7. Stock, Bauteil Ost, A-1030 Wien
Postadresse: Postfach 147, A-1103 Wien
Telefon: +43 664 420 4100
Telefax: +43 1 79780 13
E-Mail: <mailto:[email-masked]> 
Web: <http://www.oefeg.at>

Die in dieser Mitteilung und Anhangen enthaltenen Informationen sind
ausschlie?lich fur den Adressaten bestimmt und konnen geheime,
vertrauliche oder vor Weitergabe geschutzte Informationen enthalten.
Falls es sich beim Leser dieses Absatzes nicht um den beabsichtigten
Empfanger oder dessen Vertretung handelt, wird er hiermit in Kenntnis
gesetzt, dass jegliche Weitergabe, Verteilung oder Vervielfaltigung
dieser Mitteilung verboten ist. Sollte dieses Schreiben irrtumlich
zugestellt worden sein, wird gebeten, den Absender zu benachrichtigen
und die Mitteilung zu loschen, ohne Kopien einzubehalten. Danke.

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