Re: Proposal for some constrains we need

On 01/02/2013 5:16 AM, Tim Panton new wrote:
> On 1 Feb 2013, at 00:19, Harald Alvestrand wrote:
>
>> 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.)
>>
>>
>>
> When we first discussed the constraints API, the hope was that the names would reflect the web developer's aspirations,
> not the mechanism to achieve them.
> So instead of "UseAVPF=false" and "UseRtpExtensions=false"  you'd have
>
> MaximizeLegacyPhoneInterop=true

     Right, if you're going to use a declarative API that's the way it 
should work. That being said, I personally favor an imperative API all 
the way. I've gotten nothing but grief from declarative APIs in the 
past. You can implement a declarative API using imperative calls, but 
not the other way around.

     RTCPeerConnection.setLegacyPhoneInterop(true);
     RTCPeerConnection.setAVPF(false);

     The main advantage of the current approach is that implementations 
are allowed to silently ignore constraints they don't support, but that 
is precisely the annoying thing about declarative syntax: you never get 
exactly what you're looking for and reporting errors is a lot more 
difficult.

Gili

Received on Friday, 1 February 2013 14:58:04 UTC