Subject: [AVT] Comments on draft-hellstrom-avt-rfc2793bis-01.txt

From: Magnus Westerlund <[email-masked]>
Date: Fri, 26 Sep 2003 16:26:08 +0200

Hi,

Here are some comments on this draft as result of a quick read through.

1. I think the draft introduction should be much clearer about that this 
draft updates and extends RFC 2793. I think the reason for the update 
should be made much more evident. The reasons are also very important so 
that the requirements can be understood.

Based on the chair author discussion my understanding of the purpose is 
to enable the extraction of T.140 in a Voice gateway and distribute it 
correctly over an IP network. That means that there are certain 
considerations regarding the how to multiplex voice and text or possible 
another media.

There where also expressed an requirement to be backwards compatible 
towards the format in RFC 2793.

The authors has in this version tried to meet the requirements by 
specifying basically a new format with the MIME type audio/t140 which 
has its own text block sequence number allowing the RTP sequence number 
space to be non continuos in regards to the text transport. However 
there has not been any big consideration on what this may do on the 
audio codec sharing the SSRC with the text transport.

This scenario also needs to be made much clearer if that is what should 
be used.

There exist alternatives to this solution that I think may not be 
sufficiently worked through.
- RTP session multiplexing
- SSRC multiplexing

I would encourage some discussion on this topic.

2. Section 3.5: I think this section should much clearer about the 
potential usage of RTCP for inter media synchronization.

3. Section 4.2: I think one should consider the application of targeted 
FEC when one uses RTCP for explicit packet loss notification with NACKs.

4. Section 4.4, last paragraph: "Redundancy for the last T140block 
SHOULD NOT be implemented by repeatedly transmitting the same packet 
(with the same sequence number) because this will cause the packet loss 
count, as reported in RTCP, to decrement." I would like to see this 
being even stronger.

5. Section 5: I don't think "flow control" is the appropriate words 
here. At least in my ears flow control is something dynamic instead of a 
simple session duration limitation on maximum character rate.

6. Section 7: Please provide a pointer to RFC 3550 security 
consideration. Secondly I think that authentication should actually be 
even more important then confidentiality through encryption.

7. There is need for a RFC-editors consideration section pointing out 
that there are some places where the RFC number needs to be inserted. 
The common practice is to use RFC XXXX, YYYY, etc. To give mappings 
between future number and the draft(s).

8. Section 8.1, 8.2: Change controller: I don't see a need for having 
any C/O for the IETF AVT WG. If something needs to be addressed this is 
probably in the hands of the chair currently sitting then.

9. Section 8.3: I understand the need for registering the MIME type for 
RED also for text. However the introduction and abstract should motivate 
why this is necessary.

10. End of draft: Missing IPR statement.

11. If you are giving copyright of your individual submission to the 
IETF through the large statement, I think you can include the short 
statement on the first page.

-- 

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: [email-masked]

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