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

From: "codec issue tracker" <[email-masked]>
Date: Sat, 03 Apr 2010 05:39:09 -0000

#1: Application: 2.1.  Point to point calls supporting transcoding?
------------------------------------+---------------------------------------
 Reporter:  hoene@…                 |       Owner:     
     Type:  enhancement             |      Status:  new
 Priority:  major                   |   Milestone:     
Component:  requirements            |     Version:     
 Severity:  Active WG Document      |    Keywords:     
------------------------------------+---------------------------------------

Comment(by hoene@…):

 No consensus either until now. Again two opinions:

 a) "To have similar requirements as G.718 and to consider at least cross
 tandeming conditions with [email-masked] in the characterization phase."

 b) "I think that transcoding must be an explicit non-goal for this codec."
 "Sorry, but I still do not understand the need for this testing.  In a
 cell network to VoIP topology, the codec selected must be an ITU codec
 which we already know are working fine for transcoding.  In a VoIP to VoIP
 topology the codec selected is the one defined by this WG and by
 definition no transcoding is needed.  And that's it, no test needed,
 because nobody will use it this way."

 Again, I would suggest to look for volunteers who want to make the
 subjective tests with G.722.2 and CODEC.

-- 
Ticket URL: <https://svn.tools.ietf.org/wg/codec/trac/ticket/1#comment:1>
codec <http://tools.ietf.org/codec/>

---

From: stephen botzko <[email-masked]>
Date: Sat, 3 Apr 2010 06:54:03 -0400

I personally believe testing tandem operation is a MUST, since devices using
this CODEC will certainly connect into networks where it is not supported.
The idea below that this will "just work" with every ITU codec is
incorrect..

In addition, tandem operation occurs in virtually all conference bridges
(including back-to-back encode/decode with CODEC itself).  So surely
self-tandeming has to be tested anyway.  (Though of course is is common for
devices in the same conference to be using different codecs).

I do not favor just copying the tandem requirements from some other codec's
test plan - unless we are sure that it is in essentially the same ecosystem
as ours.  Ideally the community would identify common use cases, and the
test cases would be derived from those cases.

Stephen Botzko

On Sat, Apr 3, 2010 at 1:39 AM, codec issue tracker <[email-masked]>wrote:

> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec
>

---

From: "Christian Hoene" <[email-masked]>
Date: Sat, 3 Apr 2010 13:42:24 +0200

Hi,
 
depending on the use case, the second codec might vary.
 
1)      For example, if bandwidth is plenty and music can be streamed, MP3 might be the source.
2)      In case of calling a cellular phone, AMR-NB or GSM-EFR might be transcoding partner. 
3)      Or if mobile HD voice is deployed as announced  ( <http://www.orange.com/en_EN/press/press_releases/cp100214en.jsp>
http://www.orange.com/en_EN/press/press_releases/cp100214en.jsp ) G.722.2 (AMR-WB) shall be considered.
4)      CAT-iq and many VoIP phones use G.722.
5)      ISDN and PSTN gateways still require G.711?
 
In case of G.718, use cases 3) and 4) are considered.
 
Shall the transcoding tests done via subjective (MUSHRA, MOS-LQS) or objective (PEAQ, PESQ, …) methods?
 
With best regards,
 Christian

---------------------------------------------------------------
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/> http://www.net.uni-tuebingen.de/
 
From: stephen botzko [mailto:[email-masked]] 
Sent: Saturday, April 03, 2010 12:54 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [codec] #1: Application: 2.1. Point to point calls supporting transcoding?
 
I personally believe testing tandem operation is a MUST, since devices using this CODEC will certainly connect into networks where
it is not supported.  The idea below that this will "just work" with every ITU codec is incorrect..

In addition, tandem operation occurs in virtually all conference bridges (including back-to-back encode/decode with CODEC itself).
So surely self-tandeming has to be tested anyway.  (Though of course is is common for devices in the same conference to be using
different codecs).

I do not favor just copying the tandem requirements from some other codec's test plan - unless we are sure that it is in essentially
the same ecosystem as ours.  Ideally the community would identify common use cases, and the test cases would be derived from those
cases.

Stephen Botzko
On Sat, Apr 3, 2010 at 1:39 AM, codec issue tracker <[email-masked]> wrote:

---

From: stephen botzko <[email-masked]>
Date: Sat, 3 Apr 2010 08:10:57 -0400

All valid considerations.

G.711 and G.729 are very commonly used in today's enterprise VOIP
deployments.

In the enterprise video conferencing market, G.722, G.722.1 (wideband and
superwideband), G.719, and AAC-LD are in common use.

I think it is likely that if G.729/CODEC tandems well, G.711/CODEC would
also.  Just to point out that we do not necessarily need to test every
combination commonly used.

As an aside, at some point we will need to decide exactly how important the
music/entertainment application is.  Many going-forward audio codecs for
entertainment scale up to lossless. Personally I think the most important
use is conversational speech, and I see little need for yet another music
codec.

Stephen Botzko

On Sat, Apr 3, 2010 at 7:42 AM, Christian Hoene <[email-masked]>wrote:

> 3)      Or if mobile HD voice is deployed as announced  (
> http://www.net.uni-tuebingen.de/
>
>
>
> *From**:* stephen botzko [mailto:[email-masked]]
> *Sent:* Saturday, April 03, 2010 12:54 PM
>
> *To:* [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [codec] #1: Application: 2.1. Point to point calls
> supporting transcoding?
>
>
>
> I personally believe testing tandem operation is a MUST, since devices
> using this CODEC will certainly connect into networks where it is not
> supported.  The idea below that this will "just work" with every ITU codec
> is incorrect..
>

---

From: Koen Vos <[email-masked]>
Date: Sat, 03 Apr 2010 08:44:39 -0700

Any testing of tandem coding can only be about the audio quality.  
There is no binary question about whether "it works" or not, because  
any two codecs do indeed work together when connected through audio.

I don't see a need to add tandem testing to the requirements.  Quality  
will be high when operating towards the high end of the range in  
bitrates mentioned in the requirements, and tandem quality will be  
limited by the other codec. For lower bitrates the quality naturally  
goes down.. not sure what to test?

koen.

Quoting stephen botzko:
>>  Reporter:  hoene@...                 |       Owner:
>> Comment(by hoene@...):

---

From: "Dr. Christian Hoene" <[email-masked]>
Date: Sat, 03 Apr 2010 19:16:30 +0200

Quoting Koen Vos <[email-masked]>:

> I don't see a need to add tandem testing to the requirements.   
> Quality will be high when operating towards the high end of the  
> range in bitrates mentioned in the requirements, and tandem quality  
> will be limited by the other codec. For lower bitrates the quality  
> naturally goes down.. not sure what to test?

Assuming two codecs, for example, CELT and AMR-WB, you must compare  
all CELT modes (about 16) against all AMR-WB modes (about 16), using  
different sample contents (4), and with noise and without (2).  
Typically, you need 8 ratings from different persons to get precise  
results. Actually, one needs to make the tests in at least two  
different labs. Thus, only 65536 listening-only ratings are required.  
These results you put in a document that is not public accessible and  
that nobody will read.

Then everybody will believe that transcoding is a good idea and should  
be done at least twice in every call.

  Christian

---

From: "codec issue tracker" <[email-masked]>
Date: Sat, 10 Apr 2010 05:44:06 -0000

#1: Point to point calls supporting transcoding?
------------------------------------+---------------------------------------
 Reporter:  hoene@…                 |        Owner:        
     Type:  enhancement             |       Status:  closed
 Priority:  major                   |    Milestone:        
Component:  requirements            |      Version:        
 Severity:  Active WG Document      |   Resolution:  fixed 
 Keywords:                          |  
------------------------------------+---------------------------------------
Changes (by hoene@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Any testing of tandem coding can only be about the audio quality.
 There is no binary question about whether "it works" or not, because any
 two codecs do indeed work together when connected through audio.

 I don't see a need to add tandem testing to the requirements.  Quality
 will be high when operating towards the high end of the range in bitrates
 mentioned in the requirements, and tandem quality will be limited by the
 other codec. For lower bitrates the quality naturally goes down.. not sure
 what to test?

 koen.

 Problem solved: If tandem coding is a quality problem, just add bandwidth
 on the side of the Internet codec. CH

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/1#comment:2>
codec <http://tools.ietf.org/codec/>