Re: [rtcweb] AVPF vs AVP

Hi,
RFC4585 talks about coexistence of AVP and AVPF systems in a multicast group
in section 5. Example 3 in section 4.4 of RFC 4585 talks about signaling but
claims to be incomplete and suggests using grouping for the alternatives
offers. The MMUSIC group did cap-neg for the alternatives.

Roni Even

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Harald Alvestrand
> Sent: Wednesday, September 14, 2011 10:33 PM
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] AVPF vs AVP
> 
> On 09/14/11 17:08, Magnus Westerlund wrote:
> > 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.
> If 2) is more pragmatic, the IETF should update the definition of AVP
> to
> allow use of AVPF functionality.
> The responses seem to indicate that in practice, this is already being
> done (and this is a clear indication that the concept of "profile" in
> RTP has failed to achieve its purpose).
> 
> *shudder*
> > 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  +46 10 7148287
> > Färögatan 6                | Mobile +46 73 0949079
> > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> > ---------------------------------------------------------------------
> -
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb