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

["Gunnar Hellstrom" <[e-mail]>]

Magnus,
Thanks for the comments on RFC2793bis-03,

Comment 16 reflects another interpretation of RFC2198 than I have done.
-----------------------------------------------------------------------
> 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
>
---------------------------------------------------------------------------
-----
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
[phone]
Mob: [phone]
www.omnitor.se
[e-mail]
--------------------------------------------


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]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,
>
> 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 [phone]
> Torshamsgatan 23           | Fax   [phone]
> S-164 80 Stockholm, Sweden | mailto: [e-mail]
>
>
>
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/avt
>



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