Re: [rtcweb] AVPF vs AVP

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

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

Roni

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