[MMUSIC] T38FaxMaxDatagram

"Attila Sipos" <Attila.Sipos@vegastream.com> Fri, 16 March 2007 15:02 UTC

Return-path: <mmusic-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSDwd-0005PX-Kn; Fri, 16 Mar 2007 11:02:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSDwd-0005PS-4u for mmusic@ietf.org; Fri, 16 Mar 2007 11:02:15 -0400
Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSDwb-0002S9-Re for mmusic@ietf.org; Fri, 16 Mar 2007 11:02:15 -0400
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Subject: [MMUSIC] T38FaxMaxDatagram
Date: Fri, 16 Mar 2007 15:02:12 -0000
Message-ID: <8F1F2062CA7D754A838F0E66097D23A0C24213@veg-brk-svr-pri.vegastream>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [MMUSIC] SDP Capability Negotiation Design Team: Meet in Prague
Thread-Index: AcdnZJe6dRjjTCkhT2m6/uiTVNwcOQActz1g
From: Attila Sipos <Attila.Sipos@vegastream.com>
To: mmusic <mmusic@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
Errors-To: mmusic-bounces@ietf.org

(Sorry if this is the wrong group to post to)

in draft-jones-avt-audio-t38-04.txt, they describe
T38FaxMaxBuffer:

      T38FaxMaxBuffer: Indicates the maximum number of octets that can
      be stored on the remote device before an overflow condition
      occurs. It is the responsibility of the transmitting application
      to limit the transfer rate to prevent an overflow. The negotiated
      data rate should be used to determine the rate at which data is
      being removed from the buffer.  Value is an integer.

My problem is that I don't see how this value tells us anything.

e.g.
say the T38FaxMaxBuffer is 200
and say T38MaxRate is 14400

So at 14,400bps, we generate 1800 bytes/second.

Now it says:
>>      The negotiated
>>      data rate should be used to determine the rate at which data is
>>      being removed from the buffer.  Value is an integer.

So this means the data is being removed 9 times per second (1800/200).
So why is this important?

My thinking is that if we have the T38MaxRate parameter,
then how does T38FaxMaxBuffer tells us anything extra?
What are we supposed to do with this information?

Can someone explain how to use the T38FaxMaxBuffer parameter
when it is received?

Regards,

Attila


Attila Sipos
http://www.vegastream.com


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic