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.