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

[Magnus Westerlund <[e-mail]>]

Hi,

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

Colin Perkins wrote:

>--> Magnus Westerlund <[e-mail]> writes:
>  
>
>>Hi Gunnar and Paul,
>>
>>Here is my comments on the payload format.
>>    
>>
>...
>  
>
>>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.
>>    
>>
>
>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.
>  
>

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.

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

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 

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]



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