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