Re: [payload] Progressing draft-ramalho-payload-g7110-00

["Michael Ramalho (mramalho)" <[e-mail]>]

Hi Noboru,

Thanks for your comments.

Michael Ramalho


<snip>

> MAR: There are some applications (e.g., acceleration of real-time
> protocols
> over WANs) whereby "multiplexing multiple G.711 flows" is desired.
> Granted
> there are few, if any, products AT PRESENT doing this. However, for
> those
> applications, I think a "standardized method" to put multiple channels
> in one payload is desirable.

If there was any strong need for the function, someone who desires the
functionality would better propose a standardized method for
"multiplexing multiple G.711 flows" within the G.711 payload first.

MAR: There are companies that are doing this (or planning to do this)
type of multiplexing today for WAN acceleration. A characteristic of
this type of product is to transport everything over UDP (yes, even TCP
streams) in a tunnel and then congestion control the totality of UDP
packets in the tunnel. The manner in which they do this is definitely
"non-standard" in that they do things to "fake-out" the ends of the
connections. In the case of TCP, they fake-out the state machines at the
ends - thus the sequence numbers are even different in the TCP socket
ends! [Although the basic end-to-end congestion control mechanisms of
TCP - window sizes - are the same.] See next comment.

Then we can discuss how to reflect the function in the G.711.0 payload
based on the defined multiplexing multiple G.711 flows payload.
This way, we can make sure what is the real requirements for the
functionality.

MAR: What I envision is that the association between the "channels" and
the "RTP session endpoints" will be done in proprietary ways in this
type of product. The capability we could give those designers is at
least a standardized way to put multiple G.711.0 channels in one RTP
payload.

MAR: If there is an additional desire to standardize this application
(multiplexing multiple G.711 or G.711.0 flows), we could go to mmusic to
get input. The second draft I proposed (the "compression in the middle
draft") could propose a particular method via header extensions ... but
I have not thought that part out yet.

MAR: IS there anyone out there on the avtext or payload lists have a
comment here?

<snip>

Note that this channel example proposed here is slightly different from
what is described in RFC 3551 when any of channels contains more than
one G.711.0 frames.

MAR: Not really ... as you state ... if the ptime of all the channels is
identical ... then even if there are multiple G.711.0 frames per ptime
for a given channel ... we should be OK.

> MAR: If channels > 1, the buffers in the G.711 decoding process may
> need to be larger ... but that is easily accomplished with some
#defines
> in the given application.

The G.711 decoding process does not require larger buffer size though
buffer size for the decoded G.711 samples shall be large enough to
accommodate the decoded samples, such as, "ptime octets" for each
channels ("ptime * channels" octets in total).

MAR: Yep. That is what I meant to say.

Therefore, we don't have to change the processing buffer size which 
the current G.711.0 reference software implementation uses.
The bintstream can be processed frame by frame from the first frame to
the last regardless if the bitstream contains multi-channel stream or
not.

MAR: OK.