W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2013

Re: Fwd: Proposal for some constrains we need

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 01 Feb 2013 01:19:01 +0100
Message-ID: <510B09F5.2090102@alvestrand.no>
To: public-webrtc@w3.org
On 02/01/2013 12:58 AM, Matthew Kaufman (SKYPE) wrote:
> I do hope that despite your belief that this is just a reiteration of a previous claim, you will address the comments in my email regarding whether or not programmatic changes to default behavior are "just for legacy interop" or not.

Oh, thanks for pointing out that there was an actual question in there. 
The absence of question marks misled me into thinking that you were 
making a position statement.

What I said was "My thinking for some of these is that they're backwards 
compatibility hacks that are only needed when talking to legacy devices 
where standard SDP negotiation won't do the Right Thing."

"Some of these" was intended to refer to Cullen's list of possible 
constraints.

I was particularly thinking of UseRtcpMUX; I can see no concievable 
reason to set this constraint to "false" except for interoperation with 
legacy devices that can't handle RTCP on the same port as RTP, and are 
unable to even negotiate away the option correctly using SDP.

Similar for "UseAVPF=false" and "UseRtpExtensions=false" (for UseAVPF, 
negotiation may be difficult, though).

But my imagination has certainly failed me in the past; if you see a 
reason for using these 3 constraints that is outside the realm of legacy 
interop, I'm certainly happy to learn about them.

(Some others, like MaxBandwidth, or other methods of specifying the same 
thing, are no doubt needed for a lot of purposes other than legacy interop.)






>
> Matthew Kaufman
>
> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> Sent: Thursday, January 31, 2013 3:56 PM
> To: Francois Audet
> Cc: Matthew Kaufman (SKYPE); public-webrtc@w3.org
> Subject: Re: Fwd: Proposal for some constrains we need
>
> We've been over this ground.
>
> #22 has been repeated. Thank you.
>
>
Received on Friday, 1 February 2013 00:19:31 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:32 UTC