Re: [rtcweb] AVPF vs AVP

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

Christer,
This is not the issue, since the capneg talks about how to address the
systems that do not support it.
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

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