[AVT] Comments on draft-ietf-avt-rfc2793bis-01

[Magnus Westerlund <[e-mail]>]

Hi Gunnar and Paul,

Here is my comments on the payload format.

1. Abstract: You need to remove the [1] reference.

2. Section 1: There is a MUST in the introduction. It should be changed 
to lower case must of two reasons. First, this document does not define 
that T.140 elements use ISO 10646-1. Secondly, having normative language 
in an introduction is not appropriate.

3. Section 3.2: Last sentence of second paragraph. "This T140block 
counter may be
   utilized to detect lost blocks." I would propose to change this to: 
"This T140block counter is intended to be
   utilized to detect lost blocks and avoid duplication of blocks."

4. section 3.3, last sentence: Is this SHOULD correct? Why does the 
paragraph implies that CCS SHOULD be place in one block, why not MAY or 
SHALL?

5. The robustness features of the draft. As I have privately commented I 
would prefer to see the robustness features be collected into a single 
chapter. I think by moving sections: 3.4, 3.5,  3.8, 3.9, and 4.4 into a 
new chapter, between 4 and 5 the draft can be made more understandable.

6. Section 3.6: I think one should be more explicit about the fact that 
the rendering of (reasonably) late blocks is recommend and very beneficial.

7. Section 3.6: End of last paragraph: I think I understand the 
motivation behind the recommendation that voice is discarded rather then 
the T.140 when going from IP to PSTN at a gateway. However I think one 
should reflect somewhat on the effects on the audio also.

8. Section 3.7: Timestamp. "For audio/T140, the clock frequency
     MAY be set to any value. If not specified by out of band mechanism,
     the frequency value is generally set to be 8000 Hz, as that is most
     common for audio."
I think the "generally set to be 8000 Hz" is not good enough. There 
needs to be strict rules on what to do, otherwise you are in trouble. I 
think that if not out-of-band signalling, where the interleaved audio 
can be matched in rate, a fixed rate shall be set.

I am also missing the sentence saying: "When using this payload format 
interleaved with an audio codec, the rate SHOULD be chosen to be the 
same as the audio codec(s) to avoid RTP timestamp rate switching."

9. Section 3.7: Missing marker bit definition. Even if not used it MUST 
be defined as being not used and set to 0.

10. Section 3.8: I think there are no reason to have a section called 
"additional headers" and then simply having it state, no headers exist. 
It is mostly about redundancy anyway, please rename.

11. section 3.9, second paragraph. This paragraph is very hard to 
interpret. First it talks about audio/t140, then about text/t140, and 
when you come to the rules you are rather confused about for what it 
applies. Please try to improve the paragraph through restructuring.

12. In regards to the robustness options. As we now have available 
mechanism to report packet losses, RFC 3611, but probably more important 
draft-ietf-avt-rtcp-feedback and its NACK format, there is now 
possibilities to do reactive repairs. I think the possibility should at 
least be mentioned, or if it doesn't work, that should be motivated. 
Please investigate this.

13. Section 5, Second paragraph: "To control the character transmission 
rate, the "fmtp" attribute [7]
   is used with the following syntax:"
I think this sentence should be changed to explain that; first CPS is a 
MIME parameter, secondly that this is how it is mapped according to 
section x to SDP.

14. Section 6.3: The RED SDP examples. Why does on have a=fmtp lines 
like this? To my understanding of the pt list it should only contain a 
single 98. This is either a bug here, or problem in the text/red document.

15. Section 7: I think the security section can be improved:
- Separate the three main issues, confidentiality, integrity, and source 
authentication. They are different, and have different severity and 
attacks, and different counters.
- The section should give recommendations to mechanism that allows one 
to counter these problems. For the two first SRTP works very well. For 
the last it provides some properties that can be used to accomplish 
that, combined with the signalling.
So please expand this.

16. Section 8: Should be titled "IANA Consideration". And the 
introduction to the chapter should request that the two mime types are 
registered.

17. Section 8.1, and 8.2: The registration should mention "This type is 
only defined for transfer via RTP."

18. Section 8.1, and 8.2: Security consideration: Please point at 
section 7 of RFC XXXX.

19. Section 8.2: The rate parameter for audio should contain the rule 
that it SHOULD be matched with interleaved audio codecs.

20. Section 11: Are really all references normative. I would expect that 
5, 6, and 8 are informative. I have however not looked closely at it.

21. As it seems there will be some more RFC editors notes, they may be 
moved into a separate RFC-editor section instead of being spread through 
the document.


Cheers

Magnus Westerlund 

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]



_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt