IETF Logo Mail Archive

Re: [codec] it MUST NOT exceed 1275 bytes?

"Benjamin M. Schwartz" <bmschwar@fas.harvard.edu> Mon, 25 July 2011 17:27 UTC

Return-Path: <bmschwar@fas.harvard.edu>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977B121F8B71 for <codec@ietfa.amsl.com>; Mon, 25 Jul 2011 10:27:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level:
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, 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 VwTKCL6SkiHd for <codec@ietfa.amsl.com>; Mon, 25 Jul 2011 10:27:13 -0700 (PDT)
Received: from us24.unix.fas.harvard.edu (us24.unix.fas.harvard.edu [140.247.35.204]) by ietfa.amsl.com (Postfix) with ESMTP id B4DAF21F8BC1 for <codec@ietf.org>; Mon, 25 Jul 2011 10:27:13 -0700 (PDT)
Received: from us24.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us24.unix.fas.harvard.edu (Postfix) with ESMTP id 014AC46DE72; Mon, 25 Jul 2011 13:27:13 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; s=mail; bh=3s/c4mFLSNYLMrR njMw0rCcGkwXZtzXXVyNNpp1vP9s=; b=snr5nwh4srtAc/Pryq73rYPIhtIMmol k3WyMlIzcYgH8DLzE1eOy9mtblae+wosWYhh0CC7XyQ+4BKgbrwnCiaN6if/1eOi P6UIUIBuBkF5H5QBDtyUKN8bFUfHxWVk0Jw1H3+kIu7qH3Z0T4WJa29p4wqJ1obc ac/rE4FjlzXs=
DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; q=dns; s=mail; b=PcPztGPib 7a2fbj2K8Qg1C1fIDQmLsEDT1E/7jqiYAU+xjrMKGi7C3qt3mpp/t4dVNXdo5CPD TxY0+zzcK/Z2/MCKpddUjJYm84BxEUjFe1OeCVQsqYDuXbj57vyCGHKqW8gpWK6g WKQ6Gx0tYdZblDTjvgnznADgupxcFY5DMc=
Received: from [172.23.141.135] (bwhmaincampuspat25.partners.org [170.223.207.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us24.unix.fas.harvard.edu (Postfix) with ESMTPSA id EE0AD46DE6B; Mon, 25 Jul 2011 13:27:12 -0400 (EDT)
Message-ID: <4E2DA76D.2010102@fas.harvard.edu>
Date: Mon, 25 Jul 2011 13:27:09 -0400
From: "Benjamin M. Schwartz" <bmschwar@fas.harvard.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: Christian Hoene <hoene@uni-tuebingen.de>
References: <007101cc4aee$e622bd50$b26837f0$@uni-tuebingen.de>
In-Reply-To: <007101cc4aee$e622bd50$b26837f0$@uni-tuebingen.de>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enigB26CEBE89F58193874249D97"
Cc: codec@ietf.org
Subject: Re: [codec] it MUST NOT exceed 1275 bytes?
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: bens@alum.mit.edu
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 25 Jul 2011 17:27:14 -0000

On 07/25/2011 01:18 PM, Christian Hoene wrote:
> 1) What must not exceed 1275 bytes, the total length of the payload or the
> length of the last VBR frame?

The latter.  No Opus frame may ever exceed 1275 bytes.

> 2) What are the calculations behind 1275?

"The maximum representable size is 255*4+255=1275 bytes."

Because the first N-1 frames in a packet cannot have a size greater than
1275, it would be very strange if this were permitted for the final frame.
 An unbounded frame size would also unreasonably increase the minimum
computational performance required of a conformant decoder.

> 3) The requirement "Repacketization by gateways, conference bridges, or
> other software." is not listed in the requirements draft.

Indeed, but the codec has a great deal of useful functionality beyond what
is required in that draft.

> As I still believe
> in the end-to-end principle, I also do not see the need for this
> requirement.

Opus is intended for use beyond the internet.

 Why do you need an Opus-to-Opus gateway if have can have
> end-to-end or if you can use a TURN server? 

An Opus-to-Opus gateway is appropriate when an Opus stream is being moved
between different networks, including non-IP-based networks, with
different limits and overheads related to packet size and rate.

--Ben

v2.23.0 | Report a Bug | By Email