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

At 19:33 30.04.2006, Jim Reid wrote:

>>so it's really NRA block allocations which you're preloading in
>>User ENUM - a hit in a block will really tell you that the block is
>>allocated to some operator but nothing else, right?
>
>Yup, pretty much. Though a hit would presumably tell the client how
>to terminate some sort of service for that number via SIP or the PSTN.

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.

sip:

>>I have some doubts that telcos will come forward and have the
>>registry publish *for them* what is essentially a Point-of- 
>>Interconnect information in the User ENUM tree (right?).
>
>Well we have (mainly VoIP) providers queuing up to try this. They
>don't appear to share your doubts. :-)

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.. these guys ARE concerned 
about being taken out of business by a script kiddie which discovers 
sipsak .. but some might not have discovered that aspect yet.. which 
is why I am sure that none of the bigger fish in the VoIP pond will 
bite on the SIP uri CRUE entry

>You seem to be confused Michael. CRUE has NOTHING WHATSOEVER to do
>with Infastructure or Carrier ENUM. Or interconnect agreements
>between carriers. That subject has never even cropped up while the
>CRUE proposal was being worked on.

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

Providers/Carriers (that's the 'C' in 'CRUE'..) will
a) publish an open URI (which means "anybody may 'interconnect' with 
said provider) and
b) it is a 'sender keeps all' settlement regime
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
d) any sad idiot may bounce a SIP INVITE at 3:30AM to this sip URI

(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)

>Michael, I'm trying not to get angry with you. :-) There is only one
>public tree: e164.arpa.

that's ok.. it's a 'discourse', not a case of parental guidance as 
far as I'm concerned..

  The only difference between CRUE
>and the classical User ENUM model is that a provider gets the ability
>to register say 1 million numbers in one operation instead of
>numbers being registered and delegated one at a time by the
>individuals owning each number.

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

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

>If anything, CRUE provides a means of eliminating some of the
>existing alternate trees. [None of the UK providers who are about to
>use CRUE use alternate trees AFAICT.] Instead of each (UK based) VoIP
>provider running their own ENUM-like name space uknown to anyone else
>and being unable to talk to each other, they could in principle enter
>their Ofcom-assigned blocks into CRUE and all share a common,
>consistent tree.

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

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

on the "public default SIP URI for customers" use case I wish the 
registry operator and providers good luck and deep pockets

-Michael