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

Re: Proposal for some constrains we need

From: Roman Shpount <roman@telurix.com>
Date: Fri, 1 Feb 2013 10:23:10 -0500
Message-ID: <CAD5OKxsrBtcRASe5vASpXXa4HMzPwhU3xNKqXFeWqxHkR38oYg@mail.gmail.com>
To: Tim Panton new <thp@westhawk.co.uk>
Cc: Harald Alvestrand <harald@alvestrand.no>, public-webrtc@w3.org
On Fri, Feb 1, 2013 at 5:16 AM, Tim Panton new <thp@westhawk.co.uk> 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
>
>
First of all, if we decide that legacy interop settings are required, I
would not bundle them under a catch all clause like
"MaximizeLegacyPhoneInterop". This would not be extremely usable in
practice, since requirements for one device might be quite different from
the other. Also, if the developer is dealing with an interop problem, we
better assume he understands what this problem is. Otherwise,
inexperienced developers tend to turn on options named like
"MaximizeLegacyPhoneInterop" for all the calls, just to avoid potential
problems.

Second, since we assume that an media proxy would be required for most of
the legacy interop (since there are no legacy end points supporting ICE and
dtls-srtp that I can think off), I don't think we need legacy interop
constraints unless they implement features that affect complexity or
performance of such proxy. From this point of view UseAVPF, UseRtcpMUX, and
UseRtpExtensions do not qualify. Media proxy can deal with all of those at
the same time as it is dealing with ICE and dtls-srtp.

_____________
Roman Shpount
Received on Friday, 1 February 2013 15:23:44 UTC

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