Re: Send-n, rat holes and real issues

Please read the thread.  The general problem is determining the length of a
number.  The subset is the problem of overlapped dialing where the endpoint
is sending digits blindly and the network doesn't know what the length of
the number is.

Other examples I have given include:
1. Validating the shape of an ENUM tree by the ENUM operator.
2. Intelligent end devices with SEND buttons and clever GUIs that react well
3. Proxy servers and other systems validating numbers before attempting to
route
4. Routing and rating systems diagnosing problems
The general problem of determining the length of a TN is a good problem.  I
think we should solve it.  Solving overlapped dialing by emulating how the
PSTN does it is, in my opinion, a poor choice of solution.

And, echoing Peter Koch, enum may not be the appropriate work group to solve
the problem.

Brian

> -----Original Message-----
> From: Pete Cordell [mailto:[email protected]]
> Sent: Thursday, July 03, 2008 12:21 PM
> To: Brian Rosen; 'Jay Daley'
> Cc: [email protected]
> Subject: Re: [Enum] Send-n, rat holes and real issues
> 
> - Original Message From: "Brian Rosen"
> To: "'Jay Daley'"
> >> However it is still completely orthogonal to send-n.
> > Why?  If you had the data I propose to get, it solves the send-n
> problem,
> > right?  Why would we want two ways to get the same information?
> >
> > This is the crux of the discussion we are having.  You think send-n is
> > solving a different problem, rather than a subset of a general problem.
> I
> > think send-n solves a subset (overlapped dialing) of a general problem,
> > and
> > I want a single solution to the whole problem.
> 
> Can you give some more examples of what the "general problem" is?  I'm not
> really getting that from your messages.
> 
> Also, what do you mean by overlap dialling here?  There's obviously the
> Q.931/SS7 way of doing overlapped sending with INFORMATION messages etc.
> Or
> do you use the term in a more abstract sense as in a process of dialling a
> number without having to press a 'Send' button at the end?
> 
> To me send-n is a way to iteratively determine the minimum length of an
> E.164 number.  That knowledge does allow you to do overlap dialling (in
> the
> sense of dialling without having to press a send button at the end), but
> it
> would also allow you answer pub quiz questions along the lines of "what
> are
> the minimum number of digits you would have to dial to get a connected
> call
> for a number that started +44336?" when no dialling is actually involved.
> 
> Thanks,
> 
> Pete Cordell
> Codalogic