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

[Colin Perkins <[e-mail]>]

I agree with Magnus' interpretation of the RED parameters, the complete
list should be specified. However, our intent when writing RFC 2198 was
never to include so many levels of redundancy: sending 4 copies of each
frame seems excessive. 

Colin



--> Magnus Westerlund <[e-mail]> writes:
> 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


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

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