Re: [codec] #16: Multicast?

"Christian Hoene" <hoene@uni-tuebingen.de> Fri, 07 May 2010 12:32 UTC

Return-Path: <hoene@uni-tuebingen.de>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32DD33A69F0 for <codec@core3.amsl.com>; Fri, 7 May 2010 05:32:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.879
X-Spam-Level:
X-Spam-Status: No, score=-3.879 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kpp3SHNWR1em for <codec@core3.amsl.com>; Fri, 7 May 2010 05:32:09 -0700 (PDT)
Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id DF3103A683C for <codec@ietf.org>; Fri, 7 May 2010 05:32:07 -0700 (PDT)
Received: from hoeneT60 ([178.2.215.148]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o47CVisD006995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 May 2010 14:31:50 +0200
From: Christian Hoene <hoene@uni-tuebingen.de>
To: "'Raymond (Juin-Hwey) Chen'" <rchen@broadcom.com>
References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <D6C2F445-BE4A-4571-A56D-8712C16887F1@americafree.tv> <C0347188-A2A1-4681-9F1E-0D2ECC4BDB3B@csperkins.org> <u2x6e9223711004210733g823b4777y404b02330c49dec1@mail.gmail.com> <000001cae173$dba012f0$92e038d0$@de> <r2q6e9223711004211010gfdee1a70q972e8239fef10435@mail.gmail.com> <001101cae177$e8aa6780$b9ff3680$@de> <t2t6e9223711004211119i6b107798pa01fc4b1d33debf1@mail.gmail.com> <002d01cae188$a330b2c0$e9921840$@de> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A017@IRVEXCHCCR01.corp.ad.broadcom.com> <4BD11C50.2020206@usherbrooke.ca> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A287@IRVEXCHCCR01.corp.ad.broadcom.com> <002c01cae939$5c01f400$1405dc00$@de> <CB68DF4CFBEF4942881AD37AE1A7E8C74B903454B3@IRVEXCHCCR01.corp.ad.broadcom.com>
In-Reply-To: <CB68DF4CFBEF4942881AD37AE1A7E8C74B903454B3@IRVEXCHCCR01.corp.ad.broadcom.com>
Date: Fri, 07 May 2010 14:31:42 +0200
Message-ID: <009901caede1$43f366d0$cbda3470$@de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrimhyNUh3NLsf5RvSfcmuOhmvRfwBUwYUAAVLFoDAApwRsUACBX9Bg
Content-Language: de
X-AntiVirus-Spam-Check: failed (checked by Avira MailGate: version: 3.0.0-4; spam filter version: unknown; host: mx05)
X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.236; VDF: 7.10.7.64; host: mx05); id=30568-DyPR2Z
Cc: codec@ietf.org
Subject: Re: [codec] #16: Multicast?
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 May 2010 12:32:11 -0000

Hello Raymond,

thank you for your insights into high-density VoIP gateways. I have been told that similar statement are valid also for other
gateway manufactures and that the design of high-density gateways is much more demanding than of softphones:  Because data and code
memory is limited and code cannot be loaded on demand, costs are already high, power consumption is a problem, execution is highly
paralleled, etc... Thus, it makes sense to have a codec (profile) optimized for this use case. 

What are those specific codec requirements, then?
- narrow-band?
- 5ms or 10ms frame size?
- low complexity
- low memory footprint
- transcoding robust ...

And, are these requirements unique or are they covered by existing codecs like G.711 and G.729 already? Is it likely that gateways,
which operate already on their limits, can support yet another codec?

With best regards,

 Christian Hoene





---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of Tübingen 
Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532 
http://www.net.uni-tuebingen.de/


>-----Original Message-----
>From: Raymond (Juin-Hwey) Chen [mailto:rchen@broadcom.com]
>Sent: Wednesday, May 05, 2010 1:01 AM
>To: Christian Hoene
>Cc: codec@ietf.org
>Subject: RE: [codec] #16: Multicast?
>
>Hi Christian,
>
>Sorry for the delay of my response.  I was busy with other things and not available to respond to IETF
>emails until now.
>
>You wrote:
>> The arguments on costs of the gateways is raised often. Thus, it is worthwhile to
>> consider in-depth.
>
>> May I ask you for more information about the design of VoIP Gateways. Particular, I am > interested
>in the partition between audio
>> processing and protocol stack on DSP and CPU.
>
>> Does DSP take over all codec processing? May the CPU do some parts of the computation > before,
>during or after DSP does the signal
>> processing?
>
>[Raymond]: I asked an engineering manager who was deeply involved in the design of high-density VoIP
>gateways. He said that in such gateways, due to the high number of voice channels (thousands) per box,
>a large number of DSPs and micro-controllers are used, and they are usually structured in a
>hierarchical way.  The DSPs typically take care of all speech codec processing, echo cancellation,
>DMTF tone detection, and fax, etc.  The DSPs are usually divided into groups, with each groups of DSPs
>controlled by a single micro-controller, which handles things like RTP, jitter buffering,
>packetization, QoS statistics, and moving the voice traffic to and from the DSPs in the group.  Then,
>on top of that there may be higher-performance controllers, each connected to many such groups of
>micro-controller + DSPs.  These higher-performance controllers may handle things like call setup,
>UDP/IP/RTP, routing to and from internal processor groups, and routing to and from external
>networks/devices.
>
>> How do you count number of channels? Do all voice channels have the same weight
>> regardless their sampling rate?
>> Say suppose, if the mixing is done for 48kHz instead of 8kHz, how many resource are we
>> allowed to consume more?
>
>[Raymond]: I am not sure what you meant. The channel count is just counting the actual physical voice
>channels that the gateway can handle simultaneously; it is not a weighted sum. Are you thinking that a
>48 kHz channel should be counted more than an 8 kHz channel because it requires more computational
>resources? Typical VoIP gateways only support 8 kHz telephone-bandwidth speech, so 48 kHz is out of
>the picture.
>With that said, the complexity difference between speech codecs can make a big difference in the
>channel density.  Let's say a VoIP gateway supports X simultaneous voice channels running the G.711
>codec.  Since the complexity of G.711 PCM is next to nothing, the complexity of each voice channel is
>dominated by the echo canceller (EC).  Now if you replace the G.711 codec by the G.729A codec which
>takes about 10 MIPS of computational complexity for a full-duplex codec, that can easily decrease the
>channel density to X/2.5 per gateway, depending on the EC and other things.  If you replace the G.711
>codec by the G.728 codec that takes 30+ MIPS, the channel density can easily go down to X/4 ~ X/5 or
>worse.
>Thus, if you choose a high-complexity codec, you would need to buy a lot more VoIP gateways to support
>the same number of voice channels than if you use a low-complexity codec. The cost difference is very
>real and can be very big.
>
>Raymond
>