Re: [rtcweb] AVPF vs AVP

["Roni Even" <[e-mail]>]

Hi Christer,
Again, the word is MUST for video. I think that systems that will interwork
with RTCWEB systems will support AVPF since they will need to support
current video codecs. I do not see RTCWEB systems interwork with systems
that support only H.261 or even H.263, so I assume that the interworking
will be with systems that also use AVPF for video.


As for CLUE, we can discuss it in CLUE if relevant at all. It may be
relevant only for the video capture that should be used for interworking
with non CLUE systems.
 
Roni


> -----Original Message-----
> From: Christer Holmberg [mailto:[e-mail]]
> Sent: Friday, September 16, 2011 8:51 AM
> To: Roni Even; Magnus Westerlund
> Cc: [e-mail]
> Subject: RE: [rtcweb] AVPF vs AVP
> 
> 
> Hi,
> 
> >I can agree that if you are doing video call you must send
> >AVPF regardless if you are talking with this type of systems
> >that you call "not legacy" or systems that you call "legacy".
> >This must be a MUST in the text otherwise the so called
> >"legacy" end point will think it is AVP and will not send
> >feedback messages which will break video conferencing applications.
> 
> If the video conf app *requires* AVPF, you should include AVPF in the
> m= line.
> 
> The AVP+a=rtcp-fb proposal is an alternative to CapNeg, where there is
> "built-in" fallback to AVP in case the answerer does not support AVPF.
> 
> And, IF we choose to go forward with this proposal, it should also be
> adopted by CLUE.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> > > -----Original Message-----
> > > From: Magnus Westerlund [mailto:[e-mail]]
> > > Sent: Thursday, September 15, 2011 7:06 PM
> > > To: Roni Even
> > > Cc: [e-mail]
> > > Subject: Re: [rtcweb] AVPF vs AVP
> > >
> > > On 2011-09-15 16:01, Roni Even wrote:
> > > > Magnus,
> > > > I noticed that you claim that all AVPF feedback messages are
> > > explicitly
> > > > negotiated, is this a requirement. At least RTCP-SR-REQ is not
> > > negotiated in
> > > > SDP.
> > >
> > > You are correct, had not actually noticed that. Fortunately
> > that isn't
> > > an real issue.
> > >
> > > First of all the support of AVPF can still be negotiated with the
> > > a=rtcp-fb. Simply the trr-int configuration lets both side show
> > > support of AVPF.
> > >
> > > Secondly, for the RTCP-SR-REQ if one uses the header extension to
> > > deliver the synch data then that is explicitly indicated.
> > And if you
> > > ignore or don't understand the request then you simple fall back to
> > > normal synchronization procedures with more delay before
> > completing it.
> > >
> > > >
> > > > As for using AVPF while signaling AVP that will confuse endpoint
> > > > that
> > > so not
> > > > understand this convention and can support AVPF. They will see an
> > > offer with
> > > > AVP but with parameters that are not part of AVP. They can
> respond
> > > with AVP
> > > > without the AVPF parameter and behave like AVP endpoints
> > even though
> > > they
> > > > support AVPF. This will prevent them from sending AVPF feedback
> > > messages.
> > >
> > > They can still use AVPF timing rules, even if the other
> > end-point is
> > > AVP only. They only need to restrict themselves from
> > sending feedback
> > > messages.
> > >
> > > > This may be a problem for what you call "legacy" video
> > conferencing
> > > > endpoint. (I do not like the term legacy here since these are not
> > > legacy
> > > > endpoint but AVP/AVPF compliant EPs
> > >
> > > Yes, I agree it is not without issues in that regard.
> > >
> > > I would also like to note that if you require AVPF and don't think
> > > talking to AVP only end-points then one really should
> > include the AVPF
> > > in the m= line to prevent fallback.
> > >
> > > >
> > > > I think that if we are not going to use cap-neg we should make it
> > > > historical.
> > >
> > > I kind of agree with that also. But if it constantly fails in the
> > > market I think we have to recognize that and do something else that
> > > works better.
> > >
> > > Cheers
> > >
> > > 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]
> > >
> > ---------------------------------------------------------------------
> -
> >
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> > =