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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 21 Jan 2004 18:48:53 +0100

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 21 Jan 2004 20:26:44 +0000

> Here is my comments on the payload format.
...
> least be mentioned, or if it doesn't work, that should be motivated. 

Unless specified otherwise, it should be assumed that the standard, payload
format independent, repair schemes can be used with any new payload format.
I don't see any need to list them specially here.

> single 98. This is either a bug here, or problem in the text/red

The SDP fragments such as

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

appear to be correct. The "a=fmtp:100 98/98" line indicates that both
primary and redundant coding use payload type 98. 

> that, combined with the signalling.

Note that this is recommendations, rather than "MUST" requirements, since
SRTP is not appropriate in all cases.

-- 
Colin Perkins
http://csperkins.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 22 Jan 2004 09:38:02 +0100

Hi,

Okay, some further comments. Sorry for including the wrong address to 
Gunnar (its an .se not .com address).

Colin Perkins wrote:

>>mechanism to report packet losses, RFC 3611, but probably more
>>    
>>
>important 
>  
>
>>possibilities to do reactive repairs. I think the possibility should
>>    
>>
>at 
>  
>

Yes, your right. Although I like to make people more aware of the 
possibilities, it is probably a less good idea to create unnecessary 
convolution.

>primary and redundant coding use payload type 98. 

I think we have an inconsistency between the MIME type registrations in 
RFC 3555 and draft-ietf-avt-text-red, and whats in RFC 2198. In the RFC 
3555 the following is written about the payload type list paramter:

   Required parameters:
        pt: a comma-separated list of RTP payload types.  Because
        comma is a special character, the list must be a quoted-string
        (enclosed in double quotes).  For static payload types, each
        list element is simply the type number.  For dynamic payload
        types, each list element is a mapping of the dynamic payload
        type number to an embedded MIME content-type specification for
        the payload format corresponding to the dynamic payload type.
        The format of the mapping is:

           dynamic-payload-type "=" content-type

        If the content-type string includes a comma, then the
        content-type string MUST be a quoted-string.  If the content-
        type string does not include a comma, it MAY still be quoted.
        Since it is part of the list which must itself be a quoted-
        string, that means the quotation marks MUST be quoted with
        backslash quoting as specified in RFC 2045.  If the content-
        type string itself contains a quoted-string, then the
        requirement for backslash quoting is recursively applied.  To
        specify the audio/RED payload format in SDP, the pt parameter
        is mapped to an a=fmtp attribute by eliminating the parameter
        name (pt) and changing the commas to slashes.  For example,
        'pt="0,5"' maps to 'a=fmtp:99 0/5'.  A more complicated
        example, with a dynamic payload type, is:

           pt = "0, 103 = \"audio/G729D;annexb=yes\" "

           m=audio 49170 RTP/AVP 99 0 103
           a=rtpmap:99 RED/8000
           a=fmtp:99 0/103
           a=rtpmap:103 G729D/8000
           a=fmtp:103 annexb=yes

In RFC 2198 the following paragraph can be found:

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.

So how do we resolve this. I think that the intention of declaring 
primary and secondary codec looks nice but is not really necessary and 
has problems. I think the most important factor is to know which PTs 
that may appear in the RED format so be able to set up the correct 
processing. The reason I think the primary/secondary concept is wrong is 
the case where you have more than two codecs, and the possibility that 
more than one is in fact the primary. An example of this is when having 
congestion control indication that the bandwidht must be reduced. Then 
maybe the best way of doing this is to switch primary encoding while 
still using redundancy. In this case the RFC 2198 language can't express 
it.

This needs to be resolved for the text/RED MIME registration.

Cheers

Magnus Westerlund