1. I think there are a few places where the draft is implicitly breaking
the restriction of text/RED. When having defined a PT it implies a
certain number of levels of redundancy. However the draft does not seem
to keep to this. Examples where it is unclear are:
- Section 5.3, last paragraph on page 11.
- Second paragraph in Section 7.2
There are two explanations to this virtual discrepancy from what text/red says about
specifying levels of redundancy by sdp.
1. Occationally there is no data to transmit. That may be seen as a temporary shift in
level of redundancy but I think it is just the nature of redundant repetition. When there
was no primary data to repeat, no redundant info can be included. That explains section
7.2, and why this topic is brought up in section 5.3.
2. I got the impression from the previous disussion about specification of the level of
redundancy that it rather was an accepted limitation when you use sdp to specify the level
that it should be fixed and signaled with the PT.
For other ways to specify the media, that restriction may not apply, and the possible
variations in levels implied by the rule in section 5.3 may be valid.
I would prefer not to change the text to explain that, but expect designers working under
the restrictions of sdp to keep to these restrictions. The rule in 5.3 about how to figure
out the level of redundancy may be used anyway as a complement to sdp parsing.
2. Section 9.
"The congestion considerations from section 10 of RFC 3550 [2],
section 6 of RFC 2198 [3] and the section about congestion in
chapter 2 of RFC 3551 [11] apply with the following application
specific considerations."
I would like to change this sentence to be applicable for any profile:
The congestion considerations from section 10 of RFC 3550 [2],
section 6 of RFC 2198 [3] and any used profile, e.g. the section
about congestion in chapter 2 of RFC 3551 [11], apply with the
following application specific considerations.
In 7.3 we already have this:
Note - While these examples utilize the RTP/AVP profile, it is not intended to limit the
scope of this memo to use with only that profile. Rather, any appropriate profile may be
used in conjunction with this memo.
Do you still think we need to emphasise that statement according to your proposal?
3. Section 9:
-With the (unusually high) load of 20 characters per second, in a
language that make use of three octets UTF-8 characters, no header
compression, two redundant levels and 300 ms between transmissions,
the maximum load of this application is 3300 bits/s.
-When the restrictions mentioned above are applied, limiting
transmission to 10 characters per second, using 5 s between
transmissions, the maximum load of this application in a language
that uses one octet per UTF-8 character is 300 bits/s.
Could you please clarify what is included in the bit-rate calculations.
Currently I don't know if they include more than RTP header or not.
It is:
IP v4 IP and UDP headers, RTP header, redundancy headers, payload.
I think that is a normal set when talking about network load.
In reality we also might have Ethernet headers, or be in IPv6 environment.
I think I should not include lower level headers ( like Ethernet ), But I might need to
check how much IP v6 would change. Minor, I guess.