Re: [rtcweb] AVPF vs AVP

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

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.

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 

I think that if we are not going to use cap-neg we should make it
historical. 


Roni Even

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