From: Michael Knappe <mknappe@juniper.net>
To: "swmike@swm.pp.se" <swmike@swm.pp.se>
Date: Wed, 12 May 2010 22:45:45 -0700
Thread-Topic: [codec] #18: Frame Sizes
Thread-Index: AcryXZqtcpoa8UMxQeaHmO/ME7xg9QAAexgk
Message-ID: <05542EC42316164383B5180707A489EE1D593774FC@EMBX02-HQ.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "codec@ietf.org" <codec@ietf.org>
Subject: Re: [codec] #18: Frame Sizes
Precedence: list

Mikael,

I did miss reading that email, I will find it and read it.

Cheers,

Mike

----- Original Message -----
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Michael Knappe
Cc: codec@ietf.org <codec@ietf.org>
Sent: Thu May 13 01:31:43 2010=0A=
Subject: Re: [codec] #18: Frame Sizes

On Wed, 12 May 2010, Michael Knappe wrote:

> Fair enough, although a service provider's decision to offer a free=20
> service with long round trip delays is likely less dependent on the=20
> header efficiency gains made with such large payloads and more on their=20
> ability to carry said traffic cheaply as lower priority traffic over=20
> non-QoS controlled network hops.

This is not a service provider service, this is often a way of doing it=20
without the service provider wanting me to do it this way, that's the only=
=20
reason it's with 0 marginal cost to me and why it's long RTT.

> In any case, the ability to carry multiple codec frames within an RTP=20
> packet is already standard voip system implementation practice and, with=
=20
> the exception of jitter buffer support for unpacking these composite RTP=
=20
> packets when received, is outside the scope of the codec wg.

As long as this works, I'm fine. As I said, the whole *system* needs to=20
support this, and I have historically very bad experience with decisions=20
being made on each level that this is "out of scope for us" and the=20
resulting *system* then works very poorly, that's why I'm saying what I'm=20
saying.

We're aiming at much wider network conditions here, and quite a lot of=20
months back provided quite a lot of different network examples and what I=20
thought the *system* needed to handle. Since you asked about 250ms it's=20
obvious you didn't read my email (or you don't agree with the contents of=20
it), so it still worries me that quite a lot of people here don't=20
understand the network conditions the codec needs to work in, and that we=20
do not have consensus on this point.

--=20
Mikael Abrahamsson    email: swmike@swm.pp.se