[enum-wg] Follow up on Jim Reid's presentation - CRUE and relation to IETF work

This is my final posting on this thread. I'm fed up explaining this  
and clearing up Michael's misconceptions. I suggest we defer further  
discussion until UKEG publishes the CRUE document in a couple of  
weeks. By which time we will have operational experience of how it  
works in reality.

On May 1, 2006, at 12:27, Michael Haberler wrote:
> great, lets look at what that buys us WRT to tel: uri's:
> I take the call processig logic of an average sip provider or  
> customer, which looks as follows
>
> if (destination number in user ENUM) {
>         if (SIP URI present) {
>                 bounce call to dest URI and hope it gets accepted;
>         }
>         if (tel URI present) {
>                 bounce call to your default PSTN gateway a)
>         }
> } else {
>         bounce call to your default PSTN gateway  b)
> }
>
> The only difference I can spot is that I bounce the call to my  
> default pstn gateway through branch a) instead of branch b) since  
> the default (NXDOMAIN) is to bounce to the PSTN anyway - customer  
> experience ist identical.

Yes but you miss the point. You're assuming that ENUM-aware  
applications only care about sip: URIs. Which is probably true, but  
not the whole truth. The tel: URI in CRUE is a default for  
applications that need to route the "call" when they're not  
interested in SIP.
Now you might assume that all applications will have a default action  
of "dump to PSTN" but this can't be guaranteed or assumed: hence this  
tel: URI as a safety net.

This also ties in with some aspects of the UK ENUM Code of Conduct  
about "higher rate calls". Users are expected to give consent -- or  
explictly configure their software -- before they "make calls" that  
might incur charges that are higher than they reasonably expect. eg  
Dumping to the PSTN when the end user was expecting a free SIP or  
Skype call.

> So you're basically assuming providers will publish an openly  
> contactable SIP URI *for their customers*... that doesnt quite  
> match our experience of provider belief systems..

Fine. We don't live in the same countries Michael. We shouldn't  
expect the Austrian environment to be identical to the UK's or vice  
versa.

I can assure you some UK VoIP providers (and others) are very  
interested in CRUE. For them it's a no-brainer. They can publish  
internet-reachable SIP addresses so callers don't need to contact  
their customers via the PSTN. That means not having to pay  
termination charges to  a "regular" telco for inbound PSTN calls to  
those numbers.

Please remember that the key objective of CRUE is to get loads of  
meaningful data -- for some definition of meaningful -- into  
4.4.e164.arpa. If that data can be used for other purposes, that's a  
side effect. Some of them could be good: eg encouraging the uptake of  
ENUM by providers and pump-priming the UK market. Others could be  
bad: new vectors for SPIT and suchlike. Providers can weigh up these  
advantages and disadvantages before choosing to participate in CRUE.

> Well yes it does, and its in your policy assumption WRT sip, which is:

No, that's *your* assumption Michael.

> Providers/Carriers (that's the 'C' in 'CRUE'..) will
> a) publish an open URI (which means "anybody may 'interconnect'  
> with said provider)

True. Though I don't consider that to be "interconnect" in the way a  
telco does. It doesn't involve contracts, tarrifs or settlements for  
instance.

> b) it is a 'sender keeps all' settlement regime

What "settlement regime"? If calls to a number come in over the  
internet to some SIP gateway (or whatever), there are no cross- 
operator tarrifs to settle.

> c) said provider is "willing to go away" if the user opts into User  
> ENUM - which is only going to happen if he cant make any money on  
> the user in the first place with said entry

Nope. Here's a likely use scenario. Provider sells VoIP over  
broadband (say) for a fixed fee to an end user. This comes with CRUE.  
The provider can now up-sell customer to an ENUM delegation and  
extract more money for DNS hosting, NAPTR management & provisioning,  
presence services, integrated messaging, value-added services on top  
of additional NAPTRs,  etc, etc.

> d) any sad idiot may bounce a SIP INVITE at 3:30AM to this sip URI

Any sad idiot can call any phone number at any time. So what? Maybe  
these providers could offer add-on services to filter inbound SIP  
traffic? For a fee of course. :-)

> (d) which is why we're engaging in SPEERMINT - this NEEDS to be  
> resolved before public SIP goes the route SMTP mail did - see  
> http://www.enum.at/ietf/ - draft-lendl* which applies to User ENUM  
> just as well)

We are in violent agreement. However the problems of SPIT and  
suchlike are completely orthogonal to CRUE. They exist whether or not  
a number is entered into ENUM using CRUE of the classical delegation  
model.

> a million tel: entries is great provided they convey meaningful  
> information

Which is why UKEG came up with CRUE.

> meaningful IMV could be for instance: number exists; number hosted  
> by carrier X/through routing number Y; number does definitely not  
> exist

Well if CRUE grows legs, in principle it could be extended to add  
more (non-SIP?) NAPTRs to the block registrations: say a void:  
service type or something like that.

> can you come forward with sensible *use cases* for tel: and sip: ?

I did. See above.

> the fact that a well formed E.164 number may or may not resolve to  
> a tel: URI will not change the call processing logic of any SIP  
> user/provider wrt numbers reachable on the pstn, which is pretty  
> much all of them as of today

CRUE says nothing about SIP gateway call processing logic, far less  
wanting to change that.
If it did, that would be an egregious layering violation. However you  
seem to have assumed that the only thing that will do an ENUM lookup  
is a SIP gateway. That can't be guaranteed. Even if most ENUM lookups  
do come from SIP gateways.