Subject: [SIP] DTMF discussion from WG meeting

From: Rohan Mahy <[email-masked]>
Date: Wed, 02 Aug 2000 19:41:00 +0200

Hi Folks,

Below is a summary of one proposal for DTMF (basically what I said at the
mic today).

- Terminals which *send audio* must be able to send and receive DTMF via
RTP.  (If for no other reason, than PSTN interworking).

- First-party applications which *receive audio*, must be able to receive
DTMF via RTP, because the sender may send their DTMF over RTP.

- Third-party applications which want to find out about keypresses (IP
endpoints) or DTMF events (PSTN endpoints) of a party in a call, should
send a SUBSCRIBE to that party for dtmf-events.  The third party may
request [using some kind of parameter (ex: ";silent" or ";private")]  that
DTMF is not sent via RTP during this subscription.  Otherwise the first
party still sends DTMF to its audio peers using RTP.

Applications of the "silent" parameter would be private signalling to
calling card things, to conference control services, etc.

- Alternatively a third party MAY send a script/document/application (ex:
VoXML doc) to an endpoint to run, which could result in other SIP
messages//notifies, etc.  This script/doc/app MAY trap DTMF locally (and
silently).

- A first-party MAY NOT subscribe to dtmf-events, but MAY trap DTMF based
on a local script/app/doc.

Key here was the difference between a first party participant and a third
party participant.

Thoughts?

thanks,
-rohan

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 03 Aug 2000 10:53:41 -0400

I continue to be concerned by the complexity of all of this. As pointed
out, every Ethernet phone will need to support RFC 2833 (and it's pretty
trivial to implement, given that RTP/RTCP is needed anyway). Instead of
adding another mechanism, it would seem better to have the generic
ability to get end systems to send to multiple copies of audio streams,
including subsets. This is more generally useful for multi-party calls. 

(As a side note, I'm still not sure how useful this audio/DTMF split is
in practice, given the wide use of voice recognition. Also, given that
not all end systems will implement anything beyond basic 2833, in
practice you'll end up with trivial 'RTP splitters' that route DTMF
packets to one server and audio to another.)

Finally (separate issue), I just don't see that there is a practical
difference between DTMF and 'user input'. User input is just a subset of
DTMF (minus loudness). Hopefully, both will disappear over time, as user
devices have richer input capability. We don't want to redo
telnet/rlogin or X11 in SIP.