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

From: Mike Kallas <[email-masked]>
Date: Mon, 7 Aug 2000 13:41:22 -0700 (PDT)

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
> > 
> > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> > 
> > 
> > 
> > _______________________________________________
> > SIP mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/sip
> > 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip

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

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

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 08 Aug 2000 09:18:01 -0700

Hi,

- Message waiting info is not specific to IP telephony. It is equally 
relevant for email, voicemail, video, faxes, file sharing drop boxes, etc.

- MGCP, Megaco, and H.323 already have their own (different) ways of 
handling both DTMF and Message Waiting.  A unifying approach only works 
when all the the protocols share the need for a solution.

- We already have a BCP for SIP Interworking with the PSTN.  It seems that 
the WG has already taken a chunk of IP telephony under SIP's wing as a 
subset of the SIP solution space.

Becasue of these issues, it doesn't seem like a stretch to keep both DTMF 
and Message Waiting in scope.

thanks,
-rohan