Re: [codec] #18: Frame Sizes?

["codec issue tracker" <[e-mail]>]

#18: Frame Sizes?
------------------------------------+---------------------------------------
 Reporter:  hoene@…                 |       Owner:     
     Type:  enhancement             |      Status:  new
 Priority:  major                   |   Milestone:     
Component:  requirements            |     Version:     
 Severity:  -                       |    Keywords:     
------------------------------------+---------------------------------------

Comment(by hoene@…):

 [Stephen]:
 However, the possible frame sizes are often driven by the underlying
 technology (transform size being one example).  If we decided on 10 and 20
 ms for example, would we actually rule out a codec technology that had to
 run at 7.5, 15 and 22.5?

 [Cullen]:
 +1
 Also, it seems that people working on maximizing efficient use of the
 network might want size much long than 20 ms.

 [Mikael]:
 My belief is that the solution needs to support frame sizes ranging from
 5ms up to somewhere around 100-250ms. It might be that internally it's
 actually only doing 5-20 ms and it's the transport that package it
 together so that the fps is way down, but I think it still needs to be
 taken into account when design is done.

 [Ben]:
 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: http://tools.ietf.org/html/draft-valin-celt-rtp-
 profile-01#section-3.3

 [Mike]:
 Why would you need frame sizes approaching 250 ms? This would no longer be
 supporting two-way communications in a human interactive sense.

 ...

 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.

 [Mikael]:
 Because it might work better over your GSM data network which in itself
 has 1s delay.

 And you're wrong, I communicate over skype all the time with 2+ second
 RTT. It's free, the 500ms RTT version costs quite a lot of money. Doing
 bidirectional talk over long RTT is a matter of practice.

 [Mike]: 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.

 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.

 [Mikael]:

 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.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/18#comment:2>
codec <http://tools.ietf.org/codec/>