Subject: RE: [SIP] DTMF and Universal Key Input

From: Christian Huitema <[email-masked]>
Date: Mon, 7 Aug 2000 10:04:15 -0700

Fact is, good service centers also plan to support rotary phones. Hence,
"press 1 or say 'one'." In fact, the most foolproof way to handle a
multiservice IVR is to branch a good quality audio leg to that center. If
you have the horsepower to recognize 'one', then dtmf recognition is really
in the noise...

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Roy, Radhika R, ALCOO" <[email-masked]>
Date: Mon, 7 Aug 2000 17:00:19 -0400

Hi, Mike:

It would help if you could clarify the following:

1. What do we exactly mean by the IP Telephony (application)?
2. What is the relationship between the IP Telephony (application) and SIP?

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Mike Kallas [mailto:[email-masked]]
Sent: Monday, August 07, 2000 4:41 PM
To: Scott Petrack; Richard Shockey
Cc: Henning Schulzrinne; Skip Cave; [email-masked];
[email-masked]
Subject: Re: [SIP] DTMF and Universal Key Input

I think we need to start distinguishing between the
session layer protocol and the application layer
protocols. I think that DTMF, message waiting or any
messages not related to session initiation or tear
down should not be in SIP.

However there is a huge demand for standardization of
the communication of events that are:
1-	application specific (IP Telephony) and 
2-	are either in session or out of session.

I believe we need to create an IPTelephony
Service/Application platform interface protocol.

This protocol will interface between a telephony
server running SIP signaling, Megaco Control or even
H.323 and the service / application platform that
needs the used input or user indication:

This protocol would be an application level protocol.
The application being "IPTelephony". It would be
independent of SIP and would handle all the event
signaling and function invocation needed by a service
platform.

Keep SIP simple and clean and address all the
application stuff in one place

Mike
--- Scott Petrack <[email-masked]> wrote:
> the point is not which one will take over the world.
> The point is that the
> applications are similar in many many cases. Today
> the user experience is
> that s/he can
> 
> press '1' or say 'yes'
> 
> Now it's just not really relevant that 99% of the
> people press '1' and 1%
> say 'yes.' Nor is it relevant that there will be
> many places where one can
> only press '1'. What is relevant is that the
> INFORMATION to be encoded and
> transported is IDENTICAL, whether '1' is pressed or
> 'yes' is said. So from
> the presentation layer down to the transport layer,
> it's hard to see why
> we need two different methods.
> 
> I got the impression that Skip and others wanted to
> enable the Internet
> and Internet-connected devices to offer the same key
> input service that
> the PSTN and
> PSTN devices offer today. Well, today, whether '1'
> is pressed or 'yes' is
> said, the real-time data is transported to a remote
> device and gets
> interpreted into a 'user input command'. 
> 
> The point of people who identify voice reco with key
> input is that it is a
> recipe for trouble if these two end-user events get
> transported in two
> completely different ways. If you need the keypress
> to be transported
> along the signalling path, then you also need the
> "yes" to be transported
> along the signaling path. And the encoding should
> also be as similar as
> possible, since the information to be encoded and
> transported is similar.
> 
> In both cases the data should be encoded and
> transported as RTP, because
> this is the only way you will get the same key input
> service that you have
> today. It is the only way to put saying 'yes' and
> pressing '1' on an equal
> footing, where they need to be. 
> 
> If you want to build an IVR controlled signaling
> point, it is no problem
> at all: the first answer to the SIP INVITE points to
> a host that can
> receive ONLY the DTMF payload type, no other. At
> this point, the calling
> phone can receive prompts via G.xxx ordinary audio,
> and the calling phone
> can only send DTMF back (because that's the only
> codec the answerer
> supports). This host might well be a signalling
> server. It is hardly
> rocket science to build an RTP stack which supports
> the DTMF codec only. 
> After some DTMF, the session can be modified so that
> the call is
> transferred to another host which can handle the
> proper audio codecs.
> This is the translation into IP telephony of the
> service which exists
> today, which as far as I understand, is the
> requirement. What is the
> problem with this solution? Is the problem that the
> signaling server now
> has to understand DTMF-in-RTP, this is really not a
> very difficult codec
> to master, and surely we all prefer to have one way
> of doing one thing
> than having two or three? In addition, I'll bet that
> you'll find it really
> useful to be able to have multiple receivers for the
> DTMF, etc. all the
> standard RTP services for this audio signaling.
> 
> It may well be that there is a need for some new
> signaling to tell a
> device to go into key input mode, or to send the
> DTMF codecs to one place
> and the ordinary audio to another, or something. But
> these needs have
> nothing to do with the encoding or transport of the
> information, it seems
> to me.
> 
> 
> Scott Petrack
> http://800.edial.com/[email-masked]
> 
> 
> On Sun, 6 Aug 2000, Richard Shockey wrote:
> 
> > At 10:41 AM 8/5/2000 -0400, Henning Schulzrinne
> wrote:
> > >It's not that I think that key(board) input will
> go away, just that it
> > >won't be 12 buttons with numbers and */#. The
> notion that this is in any
> > >way tied to telephone service will go away. We'll
> obviously have lots of
> > >key input. It's the web now, both forms
> (including speech input) and
> > >applets, telnet/ssh/rlogin, IM, irc and maybe
> other mechanisms.
> > >
> > >Why tie remote key(board) input to SIP or VoIP?
> If telnet (and kin) or
> > >web-based input modalities are not good enough,
> we need to discuss this,
> > >but that has nothing whatsoever to do with VoIP.
> SIP may or may not be
> > >the appropriate solution there. I don't want to
> SUBSCRIBE to the
> > >keyboard, I want to have an appropriate
> interaction with an abstract
> > >user interface that is far richer. For simple
> ASCII, telnet will
> > >probably do the trick (or the WAP "card" mode, if
> you like that model).
> > 
> > For what its worth I completely agree with Skip
> here on the use of 12d 
> > keypads in applications. These classes of
> terminals will not go away and 
> > will only increase in usage for several reasons
> particularly mobile.
> > 
> > 1. The use of E.164 numbering to identify SIP
> endpoints ( aka The ENUM WG , 
> > since I'm co-chair I need to get a small ad in
> here) and E.164 numbering is 
> > Globally Unique.
> > 
> > 2. As Skip rightly pointed out numbers are
> Linguistically Neutral 
> > ..something the IETF is still trying to deal with
> in IDN.
> > 
> > 3. Numbers are "domain less" addressing.
> > 
> > 4. I continue to hear arguments about voice
> recognition taking over  but 
> > I've heard these arguments for 10 years now and
> DTMF imput for applications 
> > just gets bigger and bigger.
> > 
> > 
> > 
> >  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > 
> > Richard Shockey
> > Senior Technical Industry Liaison
> > NeuStar Inc.
> > 1120 Vermont Avenue N.W.
> > Suite 550
> > Washington DC. 20005
> > Voice 314.503.0640
> > Fax to EMail 815.333.1237 (Preferred for Fax)
> > DC Number 202.533.2811
> > INTERNET Mail & IFAX : [email-masked]
> > or   [email-masked]
> > http://www.neustar.com
> > 
> > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> > 
> > 
> > 

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/

---

From: Mike Kallas <[email-masked]>
Date: Tue, 8 Aug 2000 09:59:52 -0700 (PDT)

Hi Roy,

IP Telephony Applications are things like Voice Mail,
IVR, Call Center, or any new imaginative ones we can
come up with

I think that SIP is the session layer protocol that is
used to establish and tear down sessions or calls in
IP telephony. but it could be used to setup any
session for application other than voice or telephony.
SIP should not have application dependence.

Mike

> > > >but that has nothing whatsoever to do with
=== message truncated ===

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 10 Aug 2000 21:14:10 -0400

There's been far more email exchanged than it would take to implement
this. To remedy this, let me provide a basic C implementation skeleton,
free of charge.

typedef struct {
    unsigned int version:2;   /* protocol version */
    unsigned int p:1;         /* padding flag */
    unsigned int x:1;         /* header extension flag */
    unsigned int cc:4;        /* CSRC count */
    unsigned int m:1;         /* marker bit */
    unsigned int pt:7;        /* payload type */
    unsigned int seq:16;      /* sequence number */
    u_int32 ts;               /* timestamp */
    u_int32 ssrc;             /* synchronization source */
} rtp_hdr_t;  

typedef struct {
   unsigned int event:8;
   unsigned int e:1:
   unsigned int r:1:
   unsigned int volume:6;
   unsigned int duration:16;
} tone_hdr_t;

struct {
  rtp_hdr_t rtp;
  tone_hdr_t tone;
} packet;

Sending:
  (setting other constant RTP header fields omitted)

  packet.rtp.ts = whatever;
  packet.rtp.seq = seq++;
  packet.rtp.tone.event = 9;   /* for the digit '9' */
  packet.rtp.tone.e = 1;       /* one digit per packet here */
  packet.rtp.tone.volume = 0;  /* we don't care */
  packet.rtp.tone.duration = whatever;  /* however long the user pressed
the key */

Receiving just unpacks this. Transmit using TCP for reliability, if you
like, or add redundancy for an additional two hour programming exercise.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs