Subject: [Enum] RE: New Enumservice NoPSTN?

From: "Stastny Richard" <[email-masked]>
Date: Tue, 23 Mar 2004 14:11:04 +0100

Richard Shockey wrote:

> >If there is no domain related to this number in the DNS, there is
> >currently the intrinsic assumption, that the number may exist on the
> >PSTN or at least the PSTN finally knows that the number does not exist.
> >So the call may be routed to the PSTN if the SIP-server is able to do
> >so.
> 
> Well it depends on network topology ..if the 1 hop edge SIP proxy executes
> a query and gets a 404 that would indicate a default condition of PSTN
> routing and IMHO the TEL URI needs to be modified to indicate that a ENUM
> query has been made.

[Richard>] you mean the ;enum-dip-indicator, the SIP proxy could also
add the ;pstn indicator.
 
> 
> >For ENUM-only number ranges we have a problem here. ENUM-only number
> >ranges exist only in the DNS.
> 
> You mean E.164 numbers that cannot be routed on the PSTN

[Richard>] To be correct, the number can be routed on the PSTN, but
it will be routed again to a IP-gateway (the so-called generic gateway)
see below, so the correct terminology is: 

I mean E.164 numbers that cannot be TERMINATED on the PSTN.
> 
> >The PSTN is recognizing the number range
> >as ENUM-only, so any call originating on the PSTN is routed to a gateway
> >capable of doing an ENUM query. If such a gateway is not finding an
> >entry for the specific number, he should have a logic built in not to
> >route the call back to the PSTN, but to signal this fact back to the
> >user (e.g. SIT).
> 
> OK ..no problem
> 
> Spell this out not everyone knows what SIT tones means though I have put
> them on my answering machine to stop predictive dialers... ( the tone
> generated by the switch when the number is unreachable . usually used in
> number disconnect situations.

[Richard>] SIT (Special Information Tone) is generated if a number does not
exist. If the number exists, but is (currently) not available, 
Trunk Busy is generated.
 
> 
> >If the above mentioned SIP-server is querying an ENUM-only number range,
> >finding no entry, routing the call to the PSTN, the call is finally
> >routed to an ENUM-enable gateway by the PSTN and properly treated.
> 
> Well here is where you seem to be losing me . if it is a ENUM only range
> and the 1st hop proxy gets a 404 .. it insert the dip indicator...then
> pass
> to the PSTN..
> Unless the 1st hop proxy has knowledge of ENUM number ranges locally and
> can interpret a 404 as call failure and not attempt to pass the call
> across.
[Richard>] The problem is that there is no local number ranges on the Internet (see also below)
> 
> 
> >So this is a minor problem, but it is not nice to bother the PSTN or
> >even to need it to properly treat a call originating on the Internet.
> 
> OK I get it .. the PSTN carriers do not want to be bothered by trying to
> route calls from IP only number ranges ..both situations would create
> failure ( SIT) but the latter is unecessary.
[Richard>] It is even worse: the generic gateway from the PSTN to IP, where the call is finally routed to needs to know ALL ENUM-only number ranges worldwide. Because if not, it may drop the call again to the PSTN,
especially if you consider that the gateway is also receiving call calls
forced to the gateway, eg with an access code. This is not impossible, but
not elegant and not fool proof, so a more elegant solution is required.
> 
> 
> >There are two solutions coming to my mind:
> >
> >A. Populate the DNS for this number range with all numbers possible, and
> >enter a proper default NAPTR
> 
> Never going to happen ...
> 
> >B: use a wildcard for the whole number range
> 
> not going to happen either...
[Richard>] Why not?
> 
> 
> >But both solutions raise the question how the NAPTR record finally
> >should look like.
> 
> Well
> 
> 
> >One solution could be to use the ENUMservice "ann" (as defined in ETSI
> >TS 102 072), but this service is more intented for end-user information
> >and may be also in addition to other enumservices. Furthermore this
> >enumservice has until know not even been discussed at IETF.
> >
> >Another solution could be to define an enumservice "nopstn", "noentry"
> >or "void". The question here is which URI should be used to keep the
> >syntax?
> 
> I'm still not clear why these error conditions in SIP cannot be dealt with
> with extensions to the tel URL or why local edge proxy's cannot be made
> aware of ENUM number ranges in order to prevent necessary PSTN call
> routing.
> 
> This is a interesting case in ENUM bahaivor that should be documented
> ..but
> I'd rather see decision trees like this one dealt with at the edge and not
> higher up the network.
> 
> 
> >One way could be to use http://.....html and point to a web-page, where
> >the entity responsible for the number range places some text.
> 
> huh?

[Richard>] You need at least some URI
> 
> >On the other hand, SIP-servers or any other application querying ENUM
> >could immediately recognize that there is no such number.
> >
> >What is the opinion of the group and are there any additional proposals?
> >
> >Is this the group where this should be discussed and/or in IPTEL or
> >SIPPING?
> 
> Well IMHO probably IPTEL but it has relevance here...
> 
> 
[Richard>] I also think it should be dicussed here

Richard

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