Subject: [SIP] summary: DTMF and voice-over-packet

From: "Kevin Davis" <[email-masked]>
Date: Tue, 11 Jul 2000 21:03:36 -0400

(Hoping to cut short yet another rampant deteriorating
discussion thread, I here attempt to summarize.)

 It is necessary to support applications based upon
DTMF and also applications based upon speech recognition
Thinking-outside-the-box visions for the year 2020 are
good, but let us not loose sight of the years 2001-2019.

1) Many applications, both current and future, are better
  enabled through speech recognition (instead of DTMF)
2) Some applications are better served by non-verbal
  keypad input.  It can be readily argued that the
  standard 12-button telephone keypad will persist for
  a significant number of years to come; though it
  it may someday go the way of rotary-dial phones.
3) In cases where both interfaces are feasible,
  different users may prefer one over the other
4) Today, the telephone keypad interface is linked to DTMF.
  If or when this relationship should change is another
  matter.  If it should change, it is still important to
  maintain compatibility with a huge installed base of DTMF.

> > It is not just security - it is security plus convenience.
> > I guess that DTMF will be used even in year 2020.
>
>You are missing the bigger picture.  In the future you will not have
>to say "one", "two"..., you can simply ask for what you want.  This
>>is the by product of current DTMF design.
>On security, there are many different methods including speech
>authentication and time sensitive pin code that would not matter if
>someone over heard you.
>I sure hope we will not be using DTMF in year 2020.

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

---

From: "Girzon, Gary" <[email-masked]>
Date: Thu, 13 Jul 2000 12:15:25 -0400

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
... 
> >"Girzon, Gary" wrote:
...
> > Most Media Server (and Media Gateway) hardware architectures today
> > split their ethernet pipes. There is typically one physical 
> interface
> > for the controlling protocol (like MGCP/ Megaco or even 
> XML) and one for the
> > 
> > streaming media (like RTP). So even though everything 
> eventually flows
> > through a single IP pipe, it makes sense to split the data since
> > the media bandwidth is significantly higher. Furthermore, 
> the protocol port
> > is shared by all the media ports and is typically exposed 
> only to another
> > SIP
> > server (ie., the Application Server). It does not have an RTP stack.
> 
> See below on "stack". Even with two different interfaces, there's
> presumably one processor or at least two tightly coupled processors,
> running the same OS and code, so even if you wanted to use an 
> RTP stack,
> you would have one sitting around in the neighborhood.
> 

Actually, I would guess that in the Media Gateways / Servers build around
cards from NMS, AudioCodes, Intel/Dialogic, Brooktrout, etc., RTP runs on
board
(ie., is embedded) while the MGCP runs on the host (typically
Pentium/SPARC).
Some people may even be doing RTP in DSPs which are distributed.
So these processors are not tighly coupled at all.
 
Please correct me if I am wrong. 

> > In this architecture, maintaining RTP connection in the MS 
> ports creates
> > a significant overhead, as Bert has pointed out. And I am 
> talking about
> > Media Gateways/Servers that must support thousands of ports 
> of media.
> 
> There are no "ports of media" here.

What do you mean by that?

> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 

Thanks for answering the RTP question!

Gary Girzon

---

From: "Culpepper, Bert" <[email-masked]>
Date: Thu, 13 Jul 2000 13:02:28 -0500

See my comments on your first point below.

> From: Girzon, Gary [mailto:[email-masked]]
> ...
> > > split their ethernet pipes. There is typically one physical interface
> > > for the controlling protocol (like MGCP/ Megaco or even  XML) and one
for the
> > > streaming media (like RTP). So even though everything  eventually
flows
> > > the media bandwidth is significantly higher. Furthermore,  the
protocol port
> > > is shared by all the media ports and is typically exposed only to
another
> > > SIP server (ie., the Application Server). It does not have an RTP
stack.
> board (ie., is embedded) while the MGCP runs on the host (typically
> Pentium/SPARC).

What I think needs to be done is a separate NIC (standard/low cost board) in
the media server (or better yet in the app server) that is used for
processing
RFC 2833 DTMF packets.  The call leg can be distinguished by the port the
packets arrive on (since the port was provided in the SDP component in the
SIP message).  As Henning said, only some socket (and RFC 2833 decoding)
programming is needed.  This removes the dependency on 3rd party component
functionality.

As for the practical aspect, finding gateways/terminals that support sending
DTMF separate (via RFC 2833) from the primary media stream may be a trick.
But I would guess that there's at least two implementations somewhere since
the method has obtained RFC status.

> > > In this architecture, maintaining RTP connection in the MS  ports
creates
> > > a significant overhead, as Bert has pointed out. And I am talking
about
> > > Media Gateways/Servers that must support thousands of ports of media.
> > 

Regards,
Bert Culpepper