Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs)

Roman Shpount <roman@telurix.com> Thu, 17 January 2013 14:31 UTC

Return-Path: <roman@telurix.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D320C21F850B for <rtcweb@ietfa.amsl.com>; Thu, 17 Jan 2013 06:31:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.478
X-Spam-Level:
X-Spam-Status: No, score=-0.478 tagged_above=-999 required=5 tests=[AWL=-2.502, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46+KRYoVkYe3 for <rtcweb@ietfa.amsl.com>; Thu, 17 Jan 2013 06:31:20 -0800 (PST)
Received: from mail-we0-x22b.google.com (we-in-x022b.1e100.net [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D98D321F84ED for <rtcweb@ietf.org>; Thu, 17 Jan 2013 06:31:19 -0800 (PST)
Received: by mail-we0-f171.google.com with SMTP id u3so270080wey.2 for <rtcweb@ietf.org>; Thu, 17 Jan 2013 06:31:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=BHsUhib+S6U5N7VMJ40n8uFfcCKfemg+NV3nQihSb1o=; b=gTSJrjC1PcDUqHIQ//U+9uHK0PaCMtiy6TWRyLpJpf3tWd8gfrZb8/9hDGdyCQmS2K XBktiY0n8Q4gpDSreNASZOcbBL1XYThKJjFLwnqI74+cv4r3cM34V0LoZhJTG7Pg/qlg BZyY3WceooZx50FoB1RfY0KHAg6Fa7YFHu7VQF2DCy3Dq/WN18EyHGNKho7xceG8zFvf ePBW+Ak/sHlaxH6uE6l11f3/aBJWEbn3tjQuhsi523tCl2v3PXckLghSOEW7rEDbeLEL YmByBIBbCVsQMaUxJVQwMS8xlCeRZp6EGyInvLrbos5Zn0UdUjDDNQD5mk5e73rkv/sI qS+w==
X-Received: by 10.194.58.175 with SMTP id s15mr8791095wjq.31.1358433079006; Thu, 17 Jan 2013 06:31:19 -0800 (PST)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx.google.com with ESMTPS id hu8sm13134630wib.6.2013.01.17.06.31.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Jan 2013 06:31:18 -0800 (PST)
Received: by mail-wi0-f172.google.com with SMTP id o1so4530061wic.17 for <rtcweb@ietf.org>; Thu, 17 Jan 2013 06:31:16 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.80.73 with SMTP id p9mr8955154wjx.4.1358433076408; Thu, 17 Jan 2013 06:31:16 -0800 (PST)
Received: by 10.216.16.134 with HTTP; Thu, 17 Jan 2013 06:31:16 -0800 (PST)
In-Reply-To: <9BA7D840-480D-4883-B170-303305376698@phonefromhere.com>
References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <BLU0-SMTP880A602A311CE05C9DC39FD0290@phx.gbl> <A26C56D5-C501-4823-8099-62AF7910B8A4@ntt-at.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <CAD5OKxtsWMfAV=K4sM+zLXoyVCgihwujH2gG9ziA5GuEtsU0sQ@mail.gmail.com> <50F43ACA.80206@nostrum.com> <CAD5OKxug2qB+Xi_cp87Lt7BiPwJ1Eq1rNuioj+zDZFf=RRckPw@mail.gmail.com> <50F44AF0.4060304@nostrum.com> <CAD5OKxs7Ueto0k-5TWnQtgb+Pocp-SSu3ctr3qFs5qrcPgMtkQ@mail.gmail.com> <50F4619F.7040208@nostrum.com> <CAD5OKxu3_JJ3zS8hCeG-nHM72t=0j--ihUR8E5NvL9--wmmnEA@mail.gmail.com> <7CBFD4609D19C043A4AC4FD8381C6E2602386636@DEMUEXC014.nsn-intra.net> <50F5A74C.3030203@nostrum.com> <CABkgnnXRcFHj4gi6WEDDqU+S-adnjd91wQW4bL2S6pO8YtzE3w@mail.gmail.com> <CAD5OKxsz1AqsDG4_cZhGxbLbzmBYeYcqexbCR1LCe7Ecx0PQ9w@mail.gmail.com> <9BA7D840-480D-4883-B170-303305376698@phonefromhere.com>
Date: Thu, 17 Jan 2013 09:31:16 -0500
Message-ID: <CAD5OKxusYaJLcRejz-JayW-LRp==xT9HAP21=8NxHxS+pfbsUQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Tim Panton <tim@phonefromhere.com>
Content-Type: multipart/alternative; boundary="047d7bb04daef8704404d37cd83b"
X-Gm-Message-State: ALoCoQmhz5t3YaY1rBWKgqQ/n3AV44VObSg7f3LA+yoYHQs8FR7LLrm4/YRzmTKP7wUOGieYlr73
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Jan 2013 14:31:20 -0000

On Thu, Jan 17, 2013 at 9:16 AM, Tim Panton <tim@phonefromhere.com> wrote:

>
> Wait, you run the risk of double counting (at least to some extent). The
> overall jitter from Alice to Bob isn't changed by transcoding.
> I think you are implying that because we transcode in the middle, there
> will be 2 jitterbuffers and the sum of the depth of these jitterbuffers will
> exceed the depth of the single jitterbuffer that would be needed if there
> was no transcoding. I agree, but I dispute that the sum of these 2
> jitterbuffers would be more than 20ms greater than the individual
> jitterbuffer that Bob would run anyway.
>
> If you look at the typical deployment scenario for 722 - Bob is either a
> conference mixer engine or using a desktop phone on a wire to a reliable
> low loss company network. Most of the packet jitter (and loss) occurs in
> the first couple of hops from Alice's browser through the wifi and the
> cafe's DSL,
> so the jitterbuffer in the middle is probably the right place to put it.
>


Well not exactly double counting. If jitter on both calls legs are
independently normally distributed and if we have jitter of X from webrtc
client to transcoder, and jitter Y from transcoder to the end client, then
in case of jitter buffer in the middle the total delay is X+Y, in case of
end-to-end transmission it is sqrt(X^2 + Y^2). So in case of two 100 ms
jitters the difference is 200 ms of overall delay vs 141 ms of overall
delay.

Regarding the deployment scenarios, you are correct in some cases where
transcoder is sitting on the edge of well configured VoIP network. In such
cases your penalty is essentially equal to jitter within the VoIP network.
Unfortunately, there is still a use case when both end points are on
consumer IP connections, for instance, when you add webrtc client to a
hosted PBX service. Your legacy phones are located at homes or small
offices and your WebRTC clients are on similar connections. You would see
significant jitter on both.
_____________
Roman Shpount