[AVT] How is SDP a=fmtp used for RFC 2198?

[Magnus Westerlund <[e-mail]>]

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:

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

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

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

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

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