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.

That would mean basically that a NXDOMAIN in UE can be used for "no such number" (SIT) signaling immediately (that is - before bouncing it to the PSTN to have that figure it out later), right?

Nope. All that can be inferred from an NXDOMAIN for a number in this scheme is it's not in the DNS. A number could have been ported to another provider and the end user for that number hasn't done anything about entering it into the public DNS. The number could still be in use even if it's not in the DNS. Or it might be in the twilight world between "not allocated to a customer" and "ready for re-use". IIRC Lawrence and Richard made a compelling case for the void: service type NAPTR to be used to indicate whenever a number was not in use. I see no justification for disagreeing with that point of view.

Is it just blocks or can do you plan to add portability-corrected NAPTR's as well, like npd:tel URI's?

The idea is that if a number is ported, it drops out of the CRUE block. The end user for that number could still register it using the standard User ENUM registration process and have its ENUM zone delegated to them. End user registrations will always supersede a CRUE entry. This was the detail I alluded to earlier. And now wish to postpone further discussion about until the new web site is up with all of the UK ENUM documents.

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

But let's assume that happens - what is the semantics of such a SIP URI for a) an end user and b) an operator - can I bounce a call to sip:number@bt.com if I find <number> in 4.4.e164.arpa and it returns such a registry-entered sip URI? Can I (do I need to?), as a end-user, distinguish who entered which record?

Michael, you're looking for complexity and scenarios that simply don't exist. The client just does a lookup in the public 4.4.e164.arpa tree. If that returns a sip: URI, the client may (or may not) -- it's the client's choice -- try to speak SIP to the named SIP server. It neither knows or cares about how that SIP URI was entered or who put it there. And it doesn't matter whether that client is an end-user or an "operator" is irrelevant. They're just clients on the public internet doing regular DNS lookups.

What if I have a IP Interconnect agreement with BT / what if not? I would assume BT might have an opinion here.. Tony?

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.

I think publishing blocks for real-time lookup is a potentially useful idea and it looks like it is more of a "best current practice" topic. BUT - the way you describe it: you're setting the rule on who enters what and if there is more than one way to publish this information I still think there is a interoperability issue because semantics of different public trees diverge.

Michael, I'm trying not to get angry with you. :-) There is only one public tree: e164.arpa. Anything else is not ENUM and not worthy of consideration here. CRUE only uses the UK public ENUM tree. 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. 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.

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.