Re: [rtcweb] AVPF vs AVP

[Harald Alvestrand <[e-mail]>]

On 09/16/2011 03:03 PM, Roni Even wrote:
> Magnus,
> Maybe we can take the approach from
> draft-holmberg-mmusic-sdp-multiplex-negotiation and offer the same m-line
> with the same port number twice, one as AVP and one as AVPF and let the
> other side chose, he can answer with a port=0 for the profile it does not
> want. If the multiplex proposal has backward interoperability than this
> proposal also does.
The backwards compatibility case for this one (grouping type = PICKONE?) 
would be that the responder establishes two RTP sessions, one with AVP 
and one with AVPF. Presumably, one has to do a second SDP O/A to get rid 
of the one the initiator doesn't want, and hope that the responder 
hasn't started using that one for media.

In draft-holmberg, the backwards compatibility case is that the 
responder establishes two RTP sessions, and both are used - each for one 
media type. No second pass is needed (as far as I can tell from current 
discussion).

A lot of things become simpler if 2-pass SDP O/A is an acceptable 
mechanism - first send a very rich offer in order to figure out what the 
other side is willing to do, then a very lean offer with only the 
mechanisms one prefers and knows that the responder is capable of 
supporting.
But is this an acceptable strategy? It has costs both in time-to-setup 
and possibly a quite confusing intermediate state of the SDP session.

> 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
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>