Yep, you are right: it has always been the maximum size.
The difference is that if you have capability negotiation before
(non fast-start), it is understood that you would attempt to indicate
a larger maximum size in the OpenLogicalChannel than what was indicated
in the terminal capability negotiation.

Also, I would guess that "fixed sized" payload (let say in
increments of 10 ms) may be less demanding on the hardware or DSP.

> Exactly, the caller has to make a series of educated guesses regarding
> outgoing caps, based on the implementor's experience and common sense.
>
> (Wait a minute. Let me get on my high horse... okay, I'm on... :-)
> These fields have always indicated _maximum_ framing. For
> example, if I
> indicate that I can receive packets containing as many as 20
> frames per
> packet (for G.711, a frame happens to be 1ms in duration),
> that means you
> can send me packets containing 1, 20, 10, 2, 15, 8, etc.,
> frames. Mix and
> match. Put a different number of frames in each successive
> packet if you
> want to. It doesn't matter. The _only_ constraint is that no
> packet may
> contain more than 20 frames. It has never meant that you can
> only send me 20
> frames per packet for each and every packet, which for G.711
> would be 20ms
> packets all the time. However, several vendors apparently have
> "extra-normative" technical constraints that they must deal
> with regarding
> packet size, i.e., DSPs that require being fed chunks of
> fixed-size audio,
> e.g., 20ms packets. But there is no way in H.245 and
> therefore H.323 to
> indicate a fixed-size packet. These vendors should either
> "fix" their DSPs
> or perform re-framing between transport and decoder. In our
> software-only
> implementation, we have a FIFO into which we shove all incoming audio
> frames. Once frames are installed in the FIFO, it doesn't
> matter where the
> packet boundary was. The decoder just processes frames in the
> order they
> were received. I'm sure that there are really good technical
> reasons why
> some implementations require fixed-size audio packets. Based
> on our perhaps
> too simplistic implementation, however, this has always puzzled me.
>
> Paul Long
> Smith Micro Software, Inc.
>