Steve,
But H.323, the referencing document via H.225.0 of RFC 1889, says that bandwidth for the open logical channel bitrate and ARQ is calculated _without_ headers. We cannot change this, because it would break existing implementations. Are you suggesting that flowControlCommand should do it differently, i.e., include at least the RTP header? The value in consistently using the same, although arguably flawed, bandwidth calculations outweighs the benefit of having a mix of calculations.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Stephen Casner [SMTP:casner@CISCO.COM] Sent: Wednesday, May 05, 1999 10:20 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: flowControlCommand and packet overhead
On Wed, 28 Apr 1999, Paul Long wrote:
> Therefore, clarification text to the following effect should be added to > 6.2.11.2 (in v2) of H.323: > > "flowControlCommand applies to the information streams which are the > content of logical channel(s), not including RTP headers, RTP payload headers, > network headers and other overhead."
I'm mostly a lurker on this list, but I thought I would offer another perspective. The RTP spec, RFC 1889, says the following:
Bandwidth calculations for control and data traffic include lower- layer transport and network protocols (e.g., UDP and IP) since that is what the resource reservation system would need to know. The application can also be expected to know which of these protocols are in use. Link level headers are not included in the calculation since the packet will be encapsulated with different link level headers as it travels.
At a minimum, I would expect the RTP payload header to be included because that is specific to the encoding and would not be known by lower layers. The difficulty in pushing this problem off to lower layers is that they need to know the packet rate in order to know how much overhead the additional headers will add. -- Steve