Re: Send-n, rat holes and real issues

"Pete Cordell" <[email protected]>
Newsgroups gmane.ietf.enum
Message-ID <03a101c8dd28$bae96f30$ea00a8c0@Codalogic>
- 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.