Re: [codec] #16: Multicast?

"Christian Hoene" <hoene@uni-tuebingen.de> Tue, 11 May 2010 17:47 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 3A6FF28C223 for <codec@core3.amsl.com>; Tue, 11 May 2010 10:47:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.473
X-Spam-Level:
X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.176, 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 ttwaGctAIXvG for <codec@core3.amsl.com>; Tue, 11 May 2010 10:47:57 -0700 (PDT)
Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id A3EEC28C1E9 for <codec@ietf.org>; Tue, 11 May 2010 10:47:56 -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 o4BHla1Q002100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 May 2010 19:47:42 +0200
From: Christian Hoene <hoene@uni-tuebingen.de>
To: 'Marshall Eubanks' <tme@americafree.tv>
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> , <009901caede1$43f366d0$cbda3470$@de> <BCB3F026FAC4C145A4A3330806FEFDA93AB072BCC6@EMBX01-HQ.jnpr.net> <CB68DF4CFBEF4942881AD37AE1A7E8C74B90345C0D@IR! V ! E XCHCC... <1273441 939. 4be72e937fdf5@webmail.fas.harvard.edu> <20100510232234.16632o6l2ecu3wyy@mail.skype.net> <006101caf117$aaf3b2c0$00db1840$@de> <1273595415.1684.33.camel@dell-desktop> <2B114368-93C0-410B-AB66-53CA33E921A8@americafree.tv>
In-Reply-To: <2B114368-93C0-410B-AB66-53CA33E921A8@americafree.tv>
Date: Tue, 11 May 2010 19:47:31 +0200
Message-ID: <009f01caf132$0df158e0$29d40aa0$@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: AcrxKdJwmS5c5MCnS/Wh6L1AC6/79QACBipA
Content-Language: de
X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05)
X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.236; VDF: 7.10.7.90; host: mx05); id=5136-oFVKwe
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: Tue, 11 May 2010 17:47:58 -0000

Hi,

I will ask the ITU-T SG12 chair and the authors, whether we can make those documents public.

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/


>-----Original Message-----
>From: Marshall Eubanks [mailto:tme@americafree.tv]
>Sent: Tuesday, May 11, 2010 6:48 PM
>To: Ben Schwartz
>Cc: Christian Hoene; codec@ietf.org
>Subject: Re: [codec] #16: Multicast?
>
>
>On May 11, 2010, at 12:30 PM, Ben Schwartz wrote:
>
>> On Tue, 2010-05-11 at 16:38 +0200, Christian Hoene wrote:
>>> Until 400ms quality is still acceptable (about toll quality). The
>>> ITU-T G.107 quality model reflects this opinion.
>>>
>>> However, in the recent years, new results have shown that the impact
>>> of delay on conversation quality is NOT as strong as assumed.
>>
>> I have been unable to locate the paper that is the source of these
>> claims.  However, I will note that
>>
>
>As a point of order, I object to any graphs without an available paper
>behind them.
>
>> (1) The results conflict with common sense.  A round-trip delay of 800
>> ms makes normal conversation extremely irritating in practice.  I'm
>> not
>> surprised these results don't show up in laboratory tests, because
>> fast
>> conversations with interjections and rapid responses typically
>> require a
>> social context not available in a lab test.
>>
>
>This depends a lot on what sort of discussion is at issue (and, also
>on the culture of the participants).
>
>For example, in my experience telepresence sessions tend to be
>structured meetings and can typically tolerate even half second delays
>without too much disruption, while for a one-on-one conversation on
>the same equipment the same delay can be pretty objectionable.
>
>Having said that, I myself also find the previously attached graphs a
>little odd, and want to see a written description of just what sort of
>experiments they describe.
>
>> It's possible that the ITU regards "extremely irritating" as
>> "acceptable", since effective conversation is still possible.  In that
>> case, I would say that the working group intends to enable
>> applications
>> with much better than "acceptable" quality.
>>
>> (2) Tests may have been done in G.711 narrowband, which introduces its
>> own intelligibility problems and reduces quality expectation.  Higher
>> fidelity makes latency more apparent.  Similarly, the equipment used
>> may
>> have introduced quality impairments that make the delay merely one
>> problem among many.
>
>Again, without the papers behind them, we are wasting our time having
>such discussions.
>
>Regards
>Marshall
>
>P.S. This thread has wandered far from multicast...
>
>
>>
>> (3) I presume the tests were done with careful equipment setup to
>> avoid
>> echo.  The perceived quality impact of echo at 200 ms one-way delay is
>> enormous, as shown in
>>
>> http://downloads.hindawi.com/journals/asp/2008/185248.pdf
>>
>> Using an echo-canceller impairs quality significantly.  Imperfect echo
>> cancellation leaves some residual artifact, which is also irritating
>> at
>> long delays.
>>
>> The tests (even in the paper above) were performed using a telephone
>> handset and earpiece.  High-quality telephony with a freestanding
>> speaker instead of an earpiece demands especially low delay due to the
>> difficulties with echo cancellation.
>>
>> --Ben
>>
>> _______________________________________________
>> codec mailing list
>> codec@ietf.org
>> https://www.ietf.org/mailman/listinfo/codec
>>