Re: [rtcweb] AVPF vs AVP

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

Christer,
You can start with avpf asin the offer in capneg and not AVP depending on
the media type. Typically for audio you will have avp and video avpf

As for the current proposal what  I said is that if you are offering video I
think that the text should mandate offering AVPF if and not AVP with the
AVPF parameters. Otherwise it will break with what is called "legacy" that
support AVPF and the important feedback messages like (FIR, PLI, TMBBR,
etc.) will not be sent form the "legacy" answerer and may be ignored when
received from by the answerer since the offer was for AVP.
Roni

> -----Original Message-----
> From: Christer Holmberg [mailto:[e-mail]]
> Sent: Friday, September 16, 2011 8:54 AM
> To: Roni Even; Magnus Westerlund; [e-mail]
> Subject: RE: [rtcweb] AVPF vs AVP
> 
> 
> Hi,
> 
> >This is not the issue, since the capneg talks about how to
> >address the systems that do not support it.
> 
> I think it is. Because, if they don't support CapNeg, they will still
> end up using AVP - even if they support AVPF - because that is the only
> thing they will understand in the offer.
> 
> >In the current proposal it will work as long as it will have
> >a distinction when to send AVP or AVPF and for video calls it
> >must say that you MUST send AVPF regardless of what is the
> >system on the other side otherwise it will fail to achieve a
> >reasonable video call.
> >What I object is to always sending AVP with AVPF information.
> >This usage should be based on the type of media that is being
> >used (video MUST always use AVPF!!!!) Roni
> 
> I don't anyone has suggested that you are not allowed to mandate AVPF
> for video. You can do that by including AVPF in the video m= line.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> > > -----Original Message-----
> > > From: Christer Holmberg [mailto:[e-mail]]
> > > Sent: Friday, September 16, 2011 8:34 AM
> > > To: Roni Even; Magnus Westerlund; [e-mail]
> > > Subject: RE: [rtcweb] AVPF vs AVP
> > >
> > >
> > > Hi Roni,
> > >
> > > >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.
> > > >
> > > >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
> > >
> > > Do those devices support CapNeg?
> > >
> > > Regards,
> > >
> > > Christer
> > >
> > >
> > >
> > > > > -----Original Message-----
> > > > > From: [e-mail]
> > [mailto:[e-mail]] On
> > > > > Behalf Of Magnus Westerlund
> > > > > Sent: Wednesday, September 14, 2011 6:09 PM
> > > > > To: [e-mail]
> > > > > Subject: [rtcweb] AVPF vs AVP
> > > > >
> > > > > Hi,
> > > > >
> > > > > There has been this long thread with the subject partially
> > > > containing
> > > > > "AVPF". I want to clarify something in this context around
> AVPF.
> > > > > Rather than the SRTP question.
> > > > >
> > > > > An end-point that is AVPF compliant is in fact
> > > > interoperable with an
> > > > > AVP one as long as the trr-int parameter is set
> > reasonably large.
> > > > > A parameter value of 1.5-5 seconds (I would recommend 3s) will
> > > > > ensure that they are in fact compatible. This avoids
> > the risk of
> > > > > any side timing out the other if the AVP side is using
> > the default
> > > > > 5
> > > > s minimum
> > > > > interval.
> > > > >
> > > > > Based on this one could in fact have the RTCWEB nodes
> > > > always use AVPF
> > > > > for RTP/RTCP Behavior. The AVPF feedback messages are
> > explicitly
> > > > > negotiated and will only be used when agreed on.
> > > > >
> > > > > This leaves us with any signaling incompatibilities when
> > > > talking to a
> > > > > legacy device. If one don't want to use cap-neg I see two
> > > > directions
> > > > > to
> > > > > go:
> > > > >
> > > > > 1) RTCWEB end-point will always signal AVPF or SAVPF. I
> > signalling
> > > > > gateway to legacy will change that by removing the F to AVP or
> > > SAVP.
> > > > >
> > > > > 2) RTCWEB end-point will always use AVPF but signal it as
> > > > AVP. It will
> > > > > detect the AVPF capabilities of the other end-point
> > based on the
> > > > > signaling of the feedback events intended to be used.
> > > > >
> > > > > I think 1) is cleaner for the future. 2) might be more
> > pragmatic.
> > > > >
> > > > > In both cases I believe there are methods for
> > negotiating a lower
> > > > > trr-int than some AVP fallback value to preserve
> > interoperability.
> > > > >
> > > > >
> > > > > However, this still don't resolve the question if the "S"
> > > > should be in
> > > > > front of the RTP profile indicator or not. But it might help by
> > > > > removing the F or not in the profile.
> > > > >
> > > > > 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
> > > >
> > > > _______________________________________________
> > > > rtcweb mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/rtcweb
> > > > =
> >
> > =