[enum-wg] Follow up on Jim Reid's presentation - CRUE and relation to IETF work
Jim Reid jim at rfc1035.com
Sun Apr 30 19:33:38 CEST 2006
> 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 at 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.
[ enum-wg Archives ]