Re: [rtcweb] AVPF vs AVP

[Christer Holmberg <[e-mail]>]

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