Re: [rtcweb] AVPF vs AVP

[Christer Holmberg <[e-mail]>]

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
>