IETF Logo Mail Archive

Re: [codec] #18: Frame Sizes

Michael Knappe <mknappe@juniper.net> Wed, 12 May 2010 16:25 UTC

Return-Path: <mknappe@juniper.net>
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 1DC8628C170 for <codec@core3.amsl.com>; Wed, 12 May 2010 09:25:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.982
X-Spam-Level:
X-Spam-Status: No, score=-4.982 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_05=-1.11, 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 SEU3TIQWqLjn for <codec@core3.amsl.com>; Wed, 12 May 2010 09:25:25 -0700 (PDT)
Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id D8BE128C1D1 for <codec@ietf.org>; Wed, 12 May 2010 09:04:59 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKS+rRoVZ7KGfnORsTo45oW4S1rXIxl9I4@postini.com; Wed, 12 May 2010 09:04:50 PDT
Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 12 May 2010 09:01:33 -0700
From: Michael Knappe <mknappe@juniper.net>
To: "bens@alum.mit.edu" <bens@alum.mit.edu>, "codec@ietf.org" <codec@ietf.org>
Date: Wed, 12 May 2010 09:01:29 -0700
Thread-Topic: [codec] #18: Frame Sizes
Thread-Index: Acrx6vJ0hWP3m0U7Q/e/TuP/14yxOgAAW9pz
Message-ID: <C8101EE9.160AB%mknappe@juniper.net>
In-Reply-To: <4BEACBE5.2080502@fas.harvard.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-Entourage/13.3.0.091002
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [codec] #18: Frame Sizes
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: Wed, 12 May 2010 16:25:26 -0000

Yes, the option and decision to pack multiple frames into an RTP packet
should be up to the implementer of an overall voice system, and should also
be supported by the receiving jitter buffer mechanism, whether or not that
receiving jitter buffer is part and parcel of the defined codec.

Many voice systems today already support this, for instance it is typical
for many of today's VoIP gateway solutions to pack two G.729A frames into
each RTP packet.

Mike 


On 5/12/10 8:40 AM, "Benjamin M. Schwartz" <bmschwar@fas.harvard.edu> wrote:

> On 05/12/2010 11:08 AM, Cullen Jennings wrote:
>> Also, it seems that people working on maximizing efficient use of the network
>> might want size much long than 20 ms.
> 
> I agree.  The CELT RTP encapsulation draft provides, I think, a logical
> implementation of this, by allowing tight packing of several codec frames
> into a single RTP packet [1].
> 
> --Ben
> 
> [1] http://tools.ietf.org/html/draft-valin-celt-rtp-profile-01#section-3.3
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec

v2.23.0 | Report a Bug | By Email