When you get a busy signal, it comes through the same band (using the same bandwidth) as the voice you hoped to hear. This in-band signal is convenient because it appears just where you were listening and you know what to do.

It also ties up a lot of switching equipment and trunk capacity for a rather small bit (BooleanRepresentation) of information. And it isn't all that easy to interpret when it's a machine placing the call. Finally, in-band signals are subject to spoofing which has been the mechanism of considerable telephone fraud.

--------

Compare these two idioms ...

* while ((ch=getchar()) != EOF) { ... }
* [aStream atEnd] whileFalse: [aCharacter := aStream next. ...]

The former uses an in-band signal for ''end-of-input'',
the latter sends it through a separate ''band''. One is easily made atomic, though not idempotent. The other conserves type-space even though it is hardly in short supply. 

----
In WritingSolidCode by SteveMaguire, he spends a chapter discussing InBandSignal(s), and how, especially in the C libraries, they make it easy to write bad code. Two examples from the book:

1) The getchar() function mentioned above. Because of the name, it's easy to think that it returns a ''char'',
even though it returns an 
''int''
because of the InBandSignal

2) Memory management functions like ''realloc'',
which return the InBandSignal 
''NULL''
which indicates an "unable to complete operation" signal. If a programmer isn't careful, the signal will be ignored, leading to memory leaks, e.g.

  pbBuf = realloc(pbBuf, sizeNew);
  if (bpBuf != NULL)
	/* use the larger buffer */

Modern languages generally use exceptions instead of in band signals.

A more recent example of an InBandSignal being used (in C) for nefarious purposes are FormatStringAttack''''''s

----
CategoryJargon