Re: [codec] #18: Frame Sizes

[Mikael Abrahamsson <[e-mail]>]

On Wed, 12 May 2010, Michael Knappe wrote:

> Fair enough, although a service provider's decision to offer a free 
> service with long round trip delays is likely less dependent on the 
> header efficiency gains made with such large payloads and more on their 
> ability to carry said traffic cheaply as lower priority traffic over 
> non-QoS controlled network hops.

This is not a service provider service, this is often a way of doing it 
without the service provider wanting me to do it this way, that's the only 
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 
> packet is already standard voip system implementation practice and, with 
> the exception of jitter buffer support for unpacking these composite RTP 
> 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 
support this, and I have historically very bad experience with decisions 
being made on each level that this is "out of scope for us" and the 
resulting *system* then works very poorly, that's why I'm saying what I'm 
saying.

We're aiming at much wider network conditions here, and quite a lot of 
months back provided quite a lot of different network examples and what I 
thought the *system* needed to handle. Since you asked about 250ms it's 
obvious you didn't read my email (or you don't agree with the contents of 
it), so it still worries me that quite a lot of people here don't 
understand the network conditions the codec needs to work in, and that we 
do not have consensus on this point.

-- 
Mikael Abrahamsson    email: [e-mail]