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

From: "Stastny Richard" <[email-masked]>
Date: Mon, 2 Sep 2002 13:55:50 +0200

Comments inline
> -----Original Message-----
> From: Patrik Fältström [mailto:[email-masked]] 
> Sent: Monday, September 02, 2002 12:55 PM
> To: Stastny Richard; Clive D.W. Feather
> Cc: Lawrence Conroy; Rich; [email-masked]
> Subject: RE: [Enum] Opt-in principle for calling users and 
> communications providers
>  
> --On 2002-09-02 12.35 +0200 Stastny Richard <[email-masked]>
> wrote:
> 
> > 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.

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 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.

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)

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.

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

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 02 Sep 2002 14:14:54 +0200

--On 2002-09-02 13.55 +0200 Stastny Richard <[email-masked]>
wrote:

> 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.

This is a view which many service providers have, but remember that "voice
application" is just like "email application" or anything else which ends
up in ENUM.

The user _must_ (as you say) see that the correct information for the
service he subscribes to is in the ENUM service providers DNS of his choice.

The user is in control, correct, and the application service provider is
giving the information needed in ENUM to the user.

In reality, my view is that what the user does is to tell the service
provider what ENUM DNS provider he wants, and the service provider is
passing information needed to the ENUM DNS provider. OR the Enum DNS
provider collects the correct information on behalf of the user.

    paf