[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] Comments on draft-ietf-avt-rfc2793bis-08
Magnus,
Thanks for your valuable review.
Comments below.
Regards
Gunnar
-------------------------------------------
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
Gunnar.Hellstrom at Omnitor.se
--------------------------------------------
>-----Original Message-----
>From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org]On Behalf Of
>Magnus Westerlund
>Sent: Tuesday, July 20, 2004 1:53 PM
>To: IETF AVT WG; Gunnar Hellstrom; Paul E. Jones
>Subject: [AVT] Comments on draft-ietf-avt-rfc2793bis-08
>
>
>Hi
>
>I have reviewed the draft and it looks good. However I have a few comments:
>
>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.
>
>4. Section 10.3:
>"The MIME type ("text") goes in SDP "m=" as the media name. "
>
>Please change to:
>
>The MIME type ("text" or "audio") goes in SDP "m=" as the media name.
>
>For clarity.
Thanks for spotting that. You are right.
>
>
>Cheers
>
>Magnus Westerlund
>
>Multimedia Technologies, Ericsson Research EAB/TVA/A
>----------------------------------------------------------------------
>Ericsson AB | Phone +46 8 4048287
>Torshamsgatan 23 | Fax +46 8 7575550
>S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
>
>
>_______________________________________________
>Audio/Video Transport Working Group
>avt at ietf.org
>https://www1.ietf.org/mailman/listinfo/avt
>
>
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt