Subject: [AVT] Comments on draft-ietf-avt-rfc2793bis-03.txt

From: Magnus Westerlund <[email-masked]>
Date: Wed, 24 Mar 2004 17:22:51 +0100

Hi,

Here is my comments from a review of this draft. As this draft was 
intended I will be extra hard on the ID nits, see link on:
http://www.ietf.org/ID.html

1. The whole draft has 15 extra left columns. This can't be there, there 
is a strict requirement on maximum of 72 columns of text.

2. The correct page breaks are missing.

3. The author list contains a blank line.

4. The first line in the left column of the header says AVT Working 
Group. Of historic reasons it should say "Network Working Group"

5. The updated boiler plate according to RFC 3667 and RFC 3668 must be 
used.

6. The RFC editor notes on the first page, are to early. Please move 
them back, at least to after the TOC. But this is also commonly a 
section at the end of the draft.

7. Section 3. I think this section is mixing to many things into one 
brew. I have previously complained on the structure. I think that a 
simple restructuring of the draft would help immensely. I would propose 
the following:
In section 3 define the RTP payload format, RTP header fields, and other 
things directly related to the payload.

Create a new section for on usage of RFC 2198 redundancy. This would 
basically be moving section, 3.4, 3.5, 3.8, 3.9 and parts of 4.3 into 
this new section.

8. Section 3.1: I think this section need to be a bit clearer on what it 
defines. Currently it says:

   "A text conversation RTP packet as specified by the text/t140 payload
    format consists of an RTP header as defined in RFC 3550 [2] followed
    immediately by a block of T.140 data, referred to as a "T140block"
    (see section 3.3).  There are no additional headers specific to this
    payload format."

I would suggest that this is reformulated to:

The text/t140 conversation RTP payload format consists of one and only 
one block of T.140 data, referred to as a "T140block" (see section 3.3). 
There are no additional headers specific to this payload format. The 
fields in the RTP header is set as defined in section 3.7.

The problem with the old text is that it doesn't clearly define what the 
RTP payload was. Instead it defined an RTP packet, which when combined 
with RFC 2198 never exist in the described form. Because then the RTP 
header has its field defined per RFC 2198, and also the payload is per 
RFC 2198. Also due to text later in the discussion on usage of the 
redundancy there is need for a clear understanding of what the RTP 
payload is.

9. Same as 8 but for section 3.2.

10. Section 3.4: "The T140blocks MAY be transmitted redundantly 
according to the payload format defined in RFC 2198 [3]." Please replace 
  "T140blocks" with the "t140 RTP payloads". Reason is that RFC 2198 
sends RTP payloads redundantly.

11. Section 3.6: "Association of RTP streams is dependent on the 
particular session application and is outside the scope of this 
document." Please remove "session".

12. Section 4.2: "With both text/t140 and audio/t140, the loss of the 
last packet of a sequence of packets cannot be detected until the next 
text packet is transmitted." Please replace transmitted, with received. 
The receiver needs to get a new sequence number or T140 block counter to 
be able to determine if things has become lost.

13. Section 4.3:
   "As an alternative (or in addition) to redundancy, Forward Error
    Correction mechanisms MAY be used when transmitting text, as per RFC
    2733 [8] or any other mechanism with the purpose of increasing the
    reliability of text transmission."

This text is redundant with section 3.5. Please gather things in one place.

14. Section 5.
   "To control the character transmission rate, the MIME parameter "cps="
    in the "fmtp" attribute [7] is defined (see section 8 ). It is used
    in SDP with the following syntax: "

The parameter is named "cps" not "cps=" The equal sign is a result of 
the name value pair that is used in fmtp lines.

15. Section 5, last paragraph. The network is another reason why a 
receiver may receive higher character rates. For example buffering that 
is more quickly sent than gathered could give this behaviour.

16. Section 6.3:
   "Below is an example of SDP similar to the above example, but also
    utilizing RFC 2198 to provide redundancy for the text packets:

        m=text 11000 RTP/AVP 98 100
        a=rtpmap:98 t140/1000
        a=rtpmap:100 red/1000
        a=fmtp:100 98/98 "

I think one should point out in this text that one signals only that one 
will use on layer of text redundancy. IF one would use three levels of 
redundancy then the fmtp line would read:
    a=fmtp:100 98/98/98/98

17. Section 11, The SRTP reference is only informative. A normative 
reference is something that one has a normative dependency of in this 
specification.

18. Don't forget to update section 13, and 14.

And please go through the ID-Nits list. I have not checked everything on 
this list, but I expect you to do it.

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

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

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

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Fri, 26 Mar 2004 20:56:08 +0100

Magnus,
Thanks for the comments on RFC2793bis-03,

Comment 16 reflects another interpretation of RFC2198 than I have done.
-----------------------------------------------------------------------
> redundancy then the fmtp line would read:
---------------------------------------------------------------------------
-----
I have not understood that from RFC2198.

This is what RFC2198 says about the FMTP line:
-------------------------------------------------------------------------
To receive a redundant stream, this is all that is required.  However
   to send a redundant stream, the sender needs to know which codecs are
   recommended for the primary and secondary (and tertiary, etc)
   encodings.  This information is specific to the redundancy format,
   and is specified using an additional attribute "fmtp" which conveys
   format-specific information.  A session directory does not parse the
   values specified in an fmtp attribute but merely hands it to the
   media tool unchanged.  For redundancy, we define the format
   parameters to be a slash "/" separated list of RTP payload types.

   Thus a complete example is:

       m=audio 12345 RTP/AVP 121 0 5
       a=rtpmap:121 red/8000/1
       a=fmtp:121 0/5

   This specifies that the default format for senders is redundancy with
   PCM as the primary encoding and DVI as the secondary encoding.
   Encodings cannot be specified in the fmtp attribute unless they are
   also specified as valid encodings on the media ("m=") line.
-----------------------------------------------------------------
I cannot from this description read that there needs to be one figure in
fmtp for each generation of redundant data. I rather expect the fmtp line
to express possible codecs, with the first one being the primary, and then
enumerating the ones used for redundancy taken in any order.

The payload format is specified per block of text in the block header.
Therefore I do not see the need for SDP to specify exactly the planned PT:s
per redundant generation.

Thus
a=fmtp:100 98/98

Would be enough regardless how many generations of PT 98 data we intend to
handle.

OK?

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Magnus
> Westerlund
> Sent: Wednesday, March 24, 2004 5:23 PM
> To: Gunnar Hellstrom; Paul E. Jones
> Cc: IETF AVT WG
> Subject: [AVT] Comments on draft-ietf-avt-rfc2793bis-03.txt
>
>
> Hi,
>
> This communication is confidential and intended solely for the
> addressee(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you believe this message has been
> sent to you in error, please notify the sender by replying to
> this transmission and delete the message without disclosing it.
> Thank you.
>
> E-mail including attachments is susceptible to data corruption,
> interruption, unauthorized amendment, tampering and viruses, and
> we only send and receive e-mails on the basis that we are not
> liable for any such corruption, interception, amendment,
> tampering or viruses or any consequences thereof.
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 29 Mar 2004 09:31:15 +0200

Hi Gunnar,

See comments inline. However feedback from actual users and the authors 
of RED is kindly requested, to help resolve this problem.

Gunnar Hellstrom wrote:

>    encodings.  

I am basing this on this part. As it gives clear indication that one 
should indicate what generation of redundancy the codec is specified for.

This information is specific to the redundancy format,
>    also specified as valid encodings on the media ("m=") line.

Also this example clearly indicates that PT=0 (PCM) is used as primary, 
and DVI as secondary encoding. That ranking could not have been done 
unless the list implies an order from primary to higher degrees of 
redundancy.

I also think that it would be simpler to use the list to indicate all 
codecs that MAY appear in the redundancy format. However as in my view 
the text indicates that one should indicate what specific configuration 
of redundancy codecs that should be used. This is also a matter of 
backwards compatibility, for RED in general. Therefore I seek input on 
how this has been interpreted and used so far.

Cheers

Magnus

-- 

Magnus Westerlund