Subject: RE: [Enum] Opt-in principle for calling users and communications providers

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Tue, 3 Sep 2002 10:10:15 -0500

One the most immediate uses of infrastructural ENUM does not have to do with voice calling at all.  There are a host of existing, non-call associated IP services for which ENUM is enormously useful.  Thse include SMS, store-and-forward fax, and voice messaging.  These services need an inter-carrier routing system that can be shared between providers, but does not necessarily require end-user participation.  I don't have a view as to whether these services require a separate root from the end-user services.  However, I thought we beat the separate root per service (or class of services) down in favor of the NAPTR multi-service approach.

Greg V.

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]]
Sent: Monday, September 02, 2002 10:08 AM
To: Stastny Richard; Patrik Fältström; Clive D.W. Feather
Cc: Lawrence Conroy; Rich; [email-masked]
Subject: RE: [Enum] Opt-in principle for calling users and
communications providers

I'm here but I still think we are talking across each other

> >
> > > I do not agree. If there has to be always a termination on the
> > > conventional network, and if the service provider may do as
> > he likes,
> > > than there must be a way for the calling user to FORCE the phone
> > > system not to use ENUM.
> > >
> > > Otherwise it would make no sense to state:
> > > "All E.164 numbers must have a Public Switched Telephone Network
> > > (PSTN) point of interface."
> >
> > No. It only means for me that if you dial on PSTN that
> > number, you will get the phone connected to something. It
> > might imply you hit a gateway to VoIP which in turn gateway
> > the call to SIP, and you will get the call terminated.
> >
> > I.e. for me the sentence state that it must be possible to
> > make a voice call using the E.164 number in question. Not
> > that the termination point _for_the_voice_call_ must be on
> > PSTN. Only that the point of interface is on PSTN, and that
> > might be a gateway.
> >
> > This is already the case for many many E.164 numbers today
> > which is IP based.
>
>Now we are at the point, why we need BOTH "user ENUM" and "infrastructure 
>ENUM" independently.
>
>Of course you may have a termination on the PSTN which is really on VoIP, 
>because the phone system is technology independant. And it is up to the 
>service provider, how to find his users, and of course he may do this also 
>with ENUM. This may be an internal DNS application or one in the "public" 
>DNS under whatever tree.

I certainly see how a service provider may want to use DNS technology 
internally in his network for a "infrastructure ENUM".  If a service 
provider begins to decompose his internal TDM network with IP based 
Inter-Machine Trunking or places significant numbers of Media Gateways 
withing their network then it makes more sense to use DNS for things like 
inter LATA routing than SS7.

The more you use IP in a service provider network the more useless SS7 
becomes, since service creation is at the edge and data routing is a 
function of BGP etc.

These are private implementations that, I'm presuming, are not globally 
visible to the average user of the internet. The management of the 
e164.arpa namespace is specifically about what is globally visible.

What is interesting to me in this converged architecture is how can a Class 
5 switch determine IF the call can be terminated on a IP endpoint.  At 
point of call ingress it is assumed that the switch has several databases 
available to it in order to make a call routing determination of which both 
a public globally visible ENUM AND a privately provisioned IP endpoint/GW 
database is available as well. However the choice of internal endpoint 
database may or may not be DNS .. it makes no difference since it is not 
globally viable.

>BUT, this ENUM cannot be the e164.arpa, because there the entries are 
>controlled by the end-user and not by the service provider. I cannot 
>imagine a service provider having a "routing" database which can be 
>manipulated by the user, who may potentially break the service.

Of course ... but where we seem to be crossing paths here is the difference 
is that one DNS tree is globally visible and the other is not.

>Of course I do see your example that "you hit a gateway to VoIP which in 
>turn gateway the call to SIP, and you will get the call terminated", but 
>this is a two stage process:
>
>First the provider queries his ENUM to terminate the call e.g. on the 
>provider supplied personal user agent (PUA). The subcriber may now have a 
>normal SIP or H323 service and is currently attached to the Internet or 
>not. If not, the call is terminating on an announcement or forwarded 
>somewhere else.

No problem here ..you are doing a internal network look up , a basic 
IF/THEN problem ..if there is no entry in the _internal_ endpoint database 
THEN query the golbal enum db.

>The provider may also offer the subscriber in parallel an sip or h323 ID, 
>which may be used by the end-user independently on his own "user ENUM" 
>entry in e164.arpa to terminate the call from the Internet on the same PUA 
>(as envisaged with +87810)

Or actually on his PSTN endpoint as well, this could work either way +87810 
would not be necessary.  This is a excellent point ..I do believe service 
providers will offer to their customers sip addresses mapped to their PSTN 
endpoints. There is a business case and service logic for doing this. The 
sip address simply maps to a GW which then rings the PSTN phone...this is 
then a called party pays or a personal freephone like service.

>Alternatively the user may have an agreement with the service provider, 
>that any call incoming from the PSTN via the gateway is first hitting the 
>PUA (by querying "infrastructure ENUM", which in turn queries "User ENUM" 
>and then forwards the call another SIP or H323 termination.

Exactly

>This would BTW be a nice way to port a number from PSTN first to an IP 
>based provider and then out on the Internet;-)
>
>Richard

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza   Bldg 10    Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto:[email-masked]> or <mailto:[email-masked]>
<http://shockey.us > ; <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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

---

From: Michael Mealling <[email-masked]>
Date: Tue, 3 Sep 2002 11:17:20 -0400

On Tue, Sep 03, 2002 at 10:10:15AM -0500, Vaudreuil, Greg M (Greg) wrote:
> I don't have a view as to whether these services 
> require a separate root from the end-user services.  However, I thought 
> we beat the separate root per service (or class of services) down in 
> favor of the NAPTR multi-service approach.

I thought we had too. In fact, I'd like someone to explain why simply
designating "infrastructure" enum-services as opposed to "user-designated"
enum-services isn't sufficient? When the user signs up with a service
they explicitly delegate the ability for their infrastructure provider
to insert "infrastructure" class NAPTR records in there for them but
that "user-designated" enum-services are still at the users discretion....

What's wrong with that model?

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net
--------------------------------------------------------------------------------
!! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !!
!! you can send something along with it! Business cards, momentos, cremains,  !!|| anything! See http://www.transorbital.net for details!                     !!