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

From: "Girzon, Gary" <[email-masked]>
Date: Thu, 13 Jul 2000 11:50:35 -0400

I see a couple of problems with Jonathan's response -

Does the RTP that comes into the Media Server have in-band audio
as well? If yes, then my Media Server has to know to throw it away, 
If not, then the source of the RTP has to generate 2 distinct RTP streams 
- one with audio (and maybe DTMF events), one with only DTMF events. 
So while you don't need any DSP resources, you 
most certainly need additional network processing resources on both ends...

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.
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.

Of course, if someone is building a Media Server with one big IP interface,
coupled with super fast network processor / DSP farm, the RTP proposal may
work.
But such an architecture does not make economical sense today (hey, it's
only
year 2000! (-: )

Gary

PS: regarding my first question, does RFC 2883 allow for sending only DTMF
or tone information with no media data?

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, July 13, 2000 10:57 AM
> To: Culpepper, Bert
> Cc: Christian Huitema; [email-masked]
> Subject: Re: [SIP] summary: DTMF and voice-over-packet
> 
> 
> 
> 
> "Culpepper, Bert" wrote:
> > 
> > The technical issue with only carrying DTMF in RTP is that
> > my media server just grew 7 to 10-fold in terms of media port
> > (RTP port plus vocoder port) count.  That's the increase in
> > media port capacity my pre/post-paid calling card service
> > node needs to provide an equivalent feature set and maintain
> > the same overall call handling capacity it had in the PSTN.
> > 
> > Is there a flaw in this logic? 
> 
> Yes.
> 
> There are no ports here. All this comes in over IP, on an ethernet
> interface or what have you.
> 
> There are NO DSP RESOURCES OR VOCODERS. The DTMF is already been
> detected. Its encapsulated in RTP in completely decoded form, EXACTLY
> THE SAME as you would get it in INFO.
> 
> The difference as far as your platform is concerned, pretty much comes
> down to whether a DTMF digit arrives in a big packet on port 
> 5060, or a
> smaller packet on a dynamic port. 
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 13 Jul 2000 11:48:03 -0400

> most certainly need additional network processing resources on both ends...

No. In either case, the box that does DTMF detection generates two
streams: one for audio (plus DTMF), one for DTMF. The only difference is
the packet format.

> 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.

> Media Gateways/Servers that must support thousands of ports of media.

There are no "ports of media" here.

> or tone information with no media data?

Yes, you can send just DTMF.

It seems to make very little difference to the sender whether you
encapsulate tones in SIP INFO messages or RTP packets, in terms of
processing resources. The only advantage is that the MG presumably
already knows RTP (but probably has no clue about SIP).
 
Implementing an RTP receiver for DTMF is probably a one-day project. You
don't need an RTP stack for that, just some socket programming.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 17 Jul 2000 01:31:51 -0400

> Media Gateways/Servers that must support thousands of ports of media.

Presumably any media server you buy supports some kind of dtmf
detection, speech recognition, or whatever. Presumably, there is some
kind of control path that allows these media events to be reported to a
control process somewhere in the media server. Using rfc2833 reuses all
of that infrastructure, but you save a huge amount on DSP resources
which you no longer need. 

-Jonathan R.