Re: [rtcweb] Feedback messages (and problem with RTP usage document)

[Bernard Aboba <[e-mail]>]

I'd prefer choice A.  It makes sense to me for all fb message recommendations to be handled within the same document.  Right now RPSI and SLI are discussed in the RTP usage document, but are OPTIONAL,  Since there will be substantial benefits in terms of interoperability,  I'd like to see commonly used fb messages RECOMMENDED for implementation (since implementation is not required in the codec documents a MUST is probably too much). 
 
It might also be appropriate to include a general statement that WebRTC implementations supporting a particular video codec need to conform to the requirements of the codec specification with respect to fb messages.  
 
I am indifferent to whether the RTP usage document includes a reference to the VP8 or H265 payload specifications or not (I'd suggest that either reference be non-normative). RFC 6184 does not have a section on fb messages similar to the ones in the VP8 and H265 payload specs, so that will not be of much help. 
 
> Date: Tue, 14 Jan 2014 10:54:31 +0100
> From: [e-mail]
> To: [e-mail]; [e-mail]
> CC: [e-mail]; [e-mail]
> Subject: Re: [rtcweb] Feedback messages (and problem with RTP usage document)
> 
> Hi Bernard and Tim,
> (As document author)
> 
> I have reviewed this issue and have the following comments regarding it.
> So, both VP8 and H.265 RTP Payload formats specifies how, but does not
> mandate support of RPSI or SLI/SPLI. To my understanding such
> requirement would be expressed by a user of the codec, like WebRTC. The
> RTP usage document has so far avoided specifying any specifics for a
> particular video codec and its payload format. And I would note that the
> solution so far allows negotiation of these features, at least as long
> as one accept to arrive at symmetric capabilities in send vs receive.
> 
> Thus the question is in which direction you think this should be addressed:
> 
> A) A generally changing the requirement on RPSI and SLI to enable its
> usage with all video codecs (capable of using them) in WebRTC. Raising
> the requirements level either to RECOMMENDED or SHALL.
> 
> B) Write a draft-ietf-rtcweb-video that has a section saying:
> Codec Specific Requirements
> ---------------------------
> - If you implement VP8 in WebRTC also RPSI and SLI SHALL be supported.
> - If you implement H.265 in WebRTC also RPSI and SPLI SHALL be supported.
> 
> Note that SHALL could be replaced by RECOMMENDED depending on the WGs
> consensus for what is appropriate here.
> 
> Note that the WG can choose to do both of the above alternative (A and
> B) but for example use A) to raise these to RECOMMENDED and use B to
> mandate them for specific codecs.
> 
> For the H.265 RTP Payload format and the SPLI message we might have
> issues with its publication not finishing, less so with VP8, but not
> impossible. We might have to deal with more unfinished pointers as we
> get closer to the publication request state.
> 
> I believe that we need more input from the WG about this question. Both
> what an appropriate way forward for this issue is, and what requirements
> level people are interested in.
> 
> Cheers
> 
> Magnus
> 
> On 2013-12-30 16:28, Bernard Aboba wrote:
> > Tim Panton said: 
> > 
> >> No - just that if you disable rtcp-fb in a VP8 session, you'll have a
> > poor experience - try it in a few wireless environments.
> > 
> > [BA] Totally agree -- and yet the RTP usage document does not properly
> > account for this.  
> > 
> > draft-ietf-payload-vp8 Section 5 refers to the RPSI and SLI feedback
> > messages. 
> > draft-ietf-payload-rtp-h265 Section 8 refers to the RPSI and (newly
> > defined) SPLI messages. 
> > 
> > And yet draft-ietf-rtcweb-rtp-usage Section 5.1.3 indicates that support
> > for SLI is OPTIONAL while Section 5.1.4 indicates that support for RPSI
> > is OPTIONAL.  
> > 
> > 
> > 
> > 
> > 
> 
> 
> -- 
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
>