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

Magnus,

> 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.

OK.. I'll add some text here for the next draft.  How does this sound:
``This document updates and extends RFC 2793.  The text is intended to try
to clarify any ambiguities in RFC 2793, improve on the specific
implementation requirements learned through development experience, and to
introduce a means of transporting text interleaved with voice within the
same RTP session.''

> 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.

Colin pointed out the same.  I've modified section 3.5 to try to address
this.  Please look for changes in the next draft.

> 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.

There are syncronization issues, as mentioned.  For example, when the
ingress side transmits text at 300bps and the egress side can only produce
text at 45.45bps, we have a problem.  I've tried to address this in my
working copy.

> 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.

We actually did have some discussion on this, though I can't recall if it
was on the list or not.  Esentially, the word "multiplexing" seems to be a
bad word.  Every form of multiplexing proposed... and we had several... was
generally rejected for one reason or another.  I actually did have text that
proposed the use of two SSRCs, but has long since been removed.

So far, the only acceptable solution has been to interleave audio and text
in the transmitted stream.  This is what we've tried to capture in this
draft.

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

What would you suggest?  There is an explicit reference to that section of
RFC 3550.  Would you like to remove the reference and state it quite
explicitly here?  (Sometimes, referring to the text that describes the
mechanism is better than try to re-explain the same. That was the approach
taken here.)

> 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.

Please explain what you have in mind here.  We didn't mention FEC in the
draft at all, as the use of FEC is something "one level higher" than this
draft.

> 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.

You want a MUST NOT?  I have no objection to that, if that's what you want.

> 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.

You might be right.  It's certainly static.  How about "SDP Attribute for
Character Transmission Rate" with appropriate changes to the text within?

> 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.

Done.

> 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).

Done.

> 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.

Removed as requested.

> 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.

It has been requested that we move this to a separate I-D.  We'll remove it
from here and then put that motivation in the separate I-D.

> 10. End of draft: Missing IPR statement.

Added.

> 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.

What do you mean, exactly?  This was taken from RFC 2198, I believe,
unchanged.  Can you point me to an example with something that is an
alternative to this?

Paul

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt