From: varney@cbnewsd.cb.att.com (Al Varney)
Newsgroups: comp.dcom.isdn
Subject: Re: DTMF interaction on ISDN
Date: 16 Oct 92 04:29:01 GMT
Distribution: na
Organization: AT&T Network Systems, Lisle, IL

In article <1992Oct14.082857.4571@ericsson.se> etxorst@eos.ericsson.se writes:
>
>This assumes that the receiving end is ISDN. But what if the call is
>from an ISDN set, through a digital CO, to an older analog CO and to a
>POTS line at the other end? Let's face it, it will be decades before
>one can count on end-to-end ISDN for a random call.
>
>Let's say you call your bank to read your account status. The bank sits
>in a different part of town and has an analog PABX which connects to an
>old analog CO. You open the call and send the address digits to your CO
>(digitally). Then what?  Do you get the CONNect ACK when the other
>party responds or when ringing starts at his phone? I've seen both in
>field trials, depending on if the other CO was on SS7 or not.

   The CALLING party gets a CONNect when the call is answered --
either by having the CALLED party send a CONNect (end-to-end ISDN),
receiving an SS7 ANM (answer) message (SS7 outgoing trunk)
or by having the switching network recognize answer in one of the
old-fashioned ways (non-ISDN line or trunk).  CONNect should not
be sent otherwise (as when ringing starts) by circuit-mode calls.

       From Bellcore's TR-TSY-000268, Sec. 4.2.2 --
  "For ... [circuit-mode calls], if the called party equates to an ISDN
   line and responds with a CONNect message, or if the called party
   equates to a non-ISDN voice line and answers the call, or if the
   called party is served by an interoffice trunk and answer supervision
   is returned, then the SPCS [switch] sends a CONNect message to the
   originating line."

>So you can't rely on CONNect ACK.

   True, but it's not sent to the caller.  But you can't rely on
a CONNect message either!!!  Why?  Well, there are a lot of cases
where you are routed to a TELCO or semi-TELCO connection that wants
DTMF, but DOESN'T return answer.  In all these situations, the
B-channel must also be connected to the handset -- otherwise you
wouldn't be able to talk to an operator (or the mechanical equivalent).
So CONNect isn't the answer.  Basically, you want to be able to
both send B-channel voice and DTMF either before or when the switch
connects the B-channel in the forward-call direction.  DTMF before
that (and after CALL PROCeeding) can't reach the far end anyway.

   Now for the big question -- if it ain't CONNect, what message
is the clue that DTMF can be used?  Well, anytime after the CALL
PROCeeding message -- the switch will refuse any more digits via
the D-channel, so why not switch then.  If you want to be helpful
to the user, you could wait for a PROGress, ALERTing or CONNect
message for a few seconds -- one of them should arrive with information
about the call.  If it's over a non-SS7 trunk, you'll get a PROGress
with call progress indicator "not end-to-end ISDN ..."  If it's
an SS7 trunk, you either get (avoiding some special cases) treated
like end-to-end ISDN, or you get the "not end-to-end ISDN" or you
get "inband information or appropriate pattern now available".
The latter is usually an indication the call did not complete for
some reason, and a tone/announcement is being played.

>... What about if you get a "call
>waiting" indication or want to place the current call on "hold" and
>call somebody else? *Normally* you want all signalling from your ISDN
>phone to your CO to be digital (D-channel). You ONLY want DTMF when
>you're calling certain special services.

   Incorrect, in my opinion.  After dialing, you want DTMF UNLESS THE
SWITCH SAYS OTHERWISE.  See below.  It's just like the POTS case;
the switch isn't usually interested in your tones/keypad after you dial
enough digits.  And it prompts you when it is interested.

> ... There are no 100 % reliable
>signals or indicators that you can use to automatically cross-over
>between DTMF mode and "normal" D-channel mode.
>But you also need a way to revert to "normal" manually in case you want
>to put the call on "hold".

   Most ISDN terminals use buttons (not KEYPAD presses) to accomplish
"hold", switching to another call appearance, etc.  For those features
that don't, the switch either has to prompt for DTMF (with dial tone
or something) or switch the KEYPAD back to D-channel mode with an
"Information Request" IE.  This the 100% reliable way to know the
switch wants D-channel keypad information, not DTMF.  Since "flash"
doesn't usually work (immediate disconnect, usually), there has to
at least be a button that means FEATURE REQUEST to replace it.

>You want the function to switch between D-channel dialling and DTMF
>signalling to be intuitive and easy to do but at the same time so
>foolproof that there's no way for the user to get stuck where he can't
>answer a "call waiting" because he's in DTMF. Congratulations, whoever
>got stuck with designing this function into a phone. You just won the
>booby prize, fella'.

   As I mentioned above, it's DTMF forever after the call is set
up, unless you get an "Information Request".  After all, the switch
knows when it's expecting more digits -- and it asks for them.

>And IF the call is ISDN end-to-end, then why do you need DTMF? The
>terminals can use user-user-info for faster and non-B-channel
>communication.


   Actually, if you have a real USER at the ISDN set, DTMF is really
faster -- the tones reach the other end without any D-channel message
formatting time or transmission/queuing delay.  And if it's a machine
that's sending the information, it doesn't need the KEYPAD -- just send
the INFO via the D-channel.

>Then, when you're done, you can start thinking about how to implement a
>similar functionality using user-user-info when the call actually is
>end-to-end ISDN. How do you switch the keypad between "dialling" mode
>and "u-u-info" mode? Do you send digits one by one (could be expensive
>if billing is "per package") or in batches (how do you terminate a
>batch)? If the other party provides responses by u-u-info, how do you
>present them? Does your phone have a display? Can it handle non-numeric
>info? How many characters? How many lines? What do you do when the CO
>sends a "display" element and the other party sends a u-u-info at the
>same time?

   Here's where I lose the reasoning -- it seems logical that, since
the switch is ignoring any future D-channel keypresses unless it asks
for more, the ISDN set should always be in DTMF mode soon after dialing,
and stay that way.  If you want to do u-to-u-info signaling, I think
the set will need a button that activates that mode, with something
else to trigger the end of the mode and the transmission of the
information.  Sets shouldn't assume that a keypress (which can be
accidental) after call connection implies u-to-u-info transfer....

   And maybe I want my ISDN display to only reflect my switch's
status, etc., and not the content of what you send via "u-u-info".
Shouldn't I be able to turn it on/off?

>Sorry if I sound negative, but this is about the point where I got
>disillusioned by ISDN. The ISDN "LEGO" blocks are great for building
>the foundation of your house, but when you reach the upper floors you
>find that some shape blocks are missing and others don't quite fit
>together. It's going to be a long time and lots of trial-and-horror
>before all equipment actually works together in the way it was intended
>to.

   Finally, if you are going to just use ISDN terminals to send KEYPAD
presses to a far-end ISDN terminal, I don't think DTMF should be ruled out.
In that case, "u-u-info" doesn't have any big advantage.  If you really
want to interface with a "interactive terminal" that's also an ISDN set,
use a keyboard and activate it with a switch.  That may be "non-standard",
but you can't expect ISDN to EVER standardize the leading edge of
telecom.  For example, would you want ISDN to have standardized full-
motion video encoding back in 1988?  I wouldn't -- but it can evolve
WHILE ISDN is being deployed.

   Sorry for the length....

Al Varney - just MY opinion.