Re: Send-n, rat holes and real issues

In our enum implementation, the number holder (carrier) can provision an
entire range of numbers with a single provisioning action.  If the "pattern"
of the NAPTRs is the same, then provisioning is simplified.  A query to any
number in the range will return a result determined by pattern.  NAPTRs use
regexps, and we use that.  So, the rule may be (details omitted)
sip:\[email protected];user=phone, and could be applied to a range, say
+4412340000 through +4412349999

The provisioning action may apply to the entire range.  There is no
requirement that each and every number in the range be active (what I meant
by "working").  An enum query to +4412341234 would return
sip:[email protected];user=phone

Nothing fancy, but you can't infer that +4412341234 is a valid number with
active service. 

Brian


> -----Original Message-----
> From: Jay Daley [mailto:[email protected]]
> Sent: Saturday, July 05, 2008 4:49 AM
> To: Brian Rosen
> Cc: [email protected]
> Subject: Re: [Enum] Send-n, rat holes and real issues
> 
> Brian
> 
> > No.
> >
> > Send-n can't necessarily tell you that unless the ENUM tree is
> provisioned
> > with each separate number.  Real systems don't necessarily do that.
> Many,
> > including ours, lets you provision a range of numbers, and you won't be
> able
> > to tell if the number is actually valid unless you try it.  That is what
> I
> > meant.  The information on number length is not equivalent to working
> > number, and never could be.
> 
> Eh?  I have no idea what the first three sentences of that paragraph mean.
>  I'd be grateful if you could have another go at explaining that.
> 
> I understand your last sentence from your perspective - that a number with
> an identified SIP endpoint may still not be "working" but I don't get the
> logic of how it applies here - you are quite right that send-n can't deal
> with that but then neither can anything else!
> 
> Jay