Re: [codec] #1: Application: 2.1. Point to point calls supporting transcoding?

"Christian Hoene" <> Thu, 25 March 2010 16:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FC613A65A6 for <>; Thu, 25 Mar 2010 09:14:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bLDIPCOawgMD for <>; Thu, 25 Mar 2010 09:14:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 89CEB3A68D6 for <>; Thu, 25 Mar 2010 09:14:29 -0700 (PDT)
Received: from hoeneT60 ( []) (authenticated bits=0) by (8.13.6/8.13.6) with ESMTP id o2PGEYUW021967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Mar 2010 17:14:42 +0100
From: Christian Hoene <>
To: 'James Rafferty' <>
References: <> <> <000701cacad3$4b99c7c0$e2cd5740$@de> <> <000501cacb6c$37c4a0a0$a74de1e0$@de> <> <001501cacbd2$d8120230$88360690$@de> <> <> <>
In-Reply-To: <>
Date: Thu, 25 Mar 2010 09:14:33 -0700
Message-ID: <001801cacc36$47431780$d5c94680$@de>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01CACBFB.9AE43F80"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrLmA24qcg2J/VMT3OxQu3ys0/ZUAAAsiAwACY9snA=
Content-Language: de
X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06)
Subject: Re: [codec] #1: Application: 2.1. Point to point calls supporting transcoding?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Mar 2010 16:14:48 -0000

it might be interesting to have a look on the decision of the ITU-T regarding the requirements of the ITU-T G.718. The document TD
314 (WP 3/16) (Geneva, 22 April - 2 May 2008 ) lists in “TABLE A: Performance requirements and objectives for an embedded audio
coding algorithm” 


9. Interoperability for speech
Interoperability with other ITU-T speech encoding standards and 
Interoperability  with 2G and 3G mobile radio systems is desirable.
Interoperability with G.722.2 @ 12,65 kb/s is of particular interest.
In the second phase of characterization “Annex 1: Initial List of Test Conditions for Optimization/Characterization Phase II” lists
the following test conditions,
*   NB self tandeming at R1 and at R2
*   WB self tandeming at R1 and at R5
*   NB Cross tandeming with G729A input
*   WB Cross tandeming with G722.2@12.65 input 
*   WB Cross tandeming with G722@64kbps input
To my understanding, the common consensus on this list is to have similar requirements as G.718 and to consider at least cross
tandeming conditions with G722.2@12.65 in the characterization phase.
With best regards,
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of Tübingen 
Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532 
From: James Rafferty [] 
Sent: Wednesday, March 24, 2010 2:46 PM
To: stephen botzko
Cc: Christian Hoene;
Subject: RE: [codec] #1: Application: 2.1. Point to point calls supporting transcoding?
The “two gateway” or back-to-back gateway case will inevitably degrade quality to be G.711 level or worse.  The IP – IP case where
there is no PSTN codec conversion  is the much more interesting one for the marketplace.  I’d agree picking a limited set of HD
codecs (for example, G.722 and G.722.2) for these tandeming purposes is the practical approach.  
James Rafferty 
Product Line Director, Integrated Media Gateways 
Dialogic, Inc.  
15 Crawford Street 
Needham, MA 02494 

Tel:    781 433 9462
Mobile: 781 929 3895
Fax:    781 433 9268
Email:  james.rafferty <>
This e-mail is intended only for the named recipient(s) and may contain information that is privileged, confidential and/or exempt
from disclosure under applicable law. No waiver of privilege, confidence or otherwise is intended by virtue of communication via the
internet. Any unauthorized use, dissemination or copying is strictly prohibited. If you have received this e-mail in error, or are
not named as a recipient, please immediately notify the sender and destroy all copies of this e-mail.
From: stephen botzko [] 
Sent: Wednesday, March 24, 2010 2:22 PM
To: James Rafferty
Cc: Christian Hoene;
Subject: Re: [codec] #1: Application: 2.1. Point to point calls supporting transcoding?
Seems to me that there are two cases here - single gateway, and double gateway.:In the double gateway case, Endpoint A connects to
Endpoint B via a gateway pair using PSTN.  The audio is converted to G.711 narrowband by the first gateway, and back to the internet
codec by the second.  The best quality that can result is G.711, and the acoustic bandwidth is also limited to narrowband, even
though both endpoints can not see the G.711 hop.  Users may have other expectations, but they cannot be met.

In any event, measuring the tandeming quality performance of this codec with all other standard or popular) codecs would be a very
tedious exercise, and IMHO not practical.   We'd have to pick one or two codecs and let it go at that.

Stephen Botzko

On Wed, Mar 24, 2010 at 1:59 PM, James Rafferty <> wrote:
Hi Christian,

See below (JR).


-----Original Message-----
From: Christian Hoene []
Sent: Wednesday, March 24, 2010 9:23 PM
To: James Rafferty;
Subject: RE: [codec] #1: Application: 2.1. Point to point calls supporting transcoding?
Hi James,

>-----Original Message-----
>From: James Rafferty []
>Vendors of products on these network edges will take the steps needed to get endpoints to communicate
>(as driven by their service provider customers), even if it requires a codec change to complete the

So, the main requirement in these cases is the interoperability. Conversational quality is of lesser importance.
Thus, we need not particular quality requirements beside that it works OK?
JR - An ability to interop is the first consideration and quality is still important; the customer will expect (whether reasonable
or not) better than PSTN quality if wideband codecs are being used by both endpoints.


codec mailing list