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