Re: [MMUSIC] [AVTCORE] New Possible Errata in RFC2326 (And Draft) regarding Blocksize

[Julius Friedman <[e-mail]>]

Hence my argument about being supported by the underlying transport
session.

But just to be clear,   a client may request a blocksize of 1 and the
server would:

1) either be able to oblige and deliver a 13 byte packet at minimum

OR

2) respond with a blocksize of x where x is the lowest available closest
multiple supported.

There is no corner case.

I would also expect as a result that the transport level framing is not
included in this count either?  E.g. 4 for binary interleaved transport.

Thanks for clarifying this.

The problem is then with the binary interleaved section and I will wait for
further feedback in that regard.

Thanks again,

-Julius
On Jan 29, 2015 10:10 PM, "Dale R. Worley" <[e-mail]> wrote:

> Julius Friedman <[e-mail]> writes:
> > ", it seems
> > to me that it counts only the bytes after the "RTP Fixed Header Fields"
> > and any RTP header extensions, and that number legitimately could be
> > small (depending on the media encoding in the RTP).
> > "
> >
> > - There must be 12 octets which are the fixed header, this is where that
> > information comes from.
>
> That's incorrect.  See the text you quoted earlier:
>
>    12.7 Blocksize
>
>    This request header field is sent from the client to the media server
>    asking the server for a particular media packet size. This packet
>    size does not include lower-layer headers such as IP, UDP, or
>    RTP. [...]
>
> Note that it says "This packet size does not include ... headers such as
> ... RTP."  The RTP header is *not* counted in this blocksize, so its 12
> octets do not constitute a minimum allowed value of blocksize
>
> Dale
>