W3C home > Mailing lists > Public > public-ortc@w3.org > May 2014

Re: Issue 80: filterParameters

From: Peter Thatcher <pthatcher@google.com>
Date: Mon, 19 May 2014 12:40:41 -0700
Message-ID: <CAJrXDUHHF15WLo2YZD0_9Z6swigxuCFP7Jn0p+7J69Hp=qti=Q@mail.gmail.com>
To: Bernard Aboba <Bernard.Aboba@microsoft.com>
Cc: "public-ortc@w3.org" <public-ortc@w3.org>
​Now that we've removed ​filterParameters/createParameters, I think we need
to find another way to make the simple use case and simple example work.  I
really don't want our "simple example" to be dependent on a JS library, or
have to choosing ssrcs.   I'd like the simple examples to remain simple.

So what can we do?  Here is an idea:

1.  Allow passing in RtpCapabilities into RtpSender.send and
RtpReceiver.receive.  That way, the signalling could just exchange
capabilities and not have to create RtpParameters for the simple case.

2.  Send and receive with the preferredPayloadType.  The sender just picks
some SSRC, and the receiver automatically locks onto them, as if the JS had
listened to "onunsignalledrtp" and added SSRCs manually.

That doesn't support header extensions (since the receiver wouldn't know
the IDs) or layering or FEC, but that might be OK for the simple use case.

Are there dragons that I'm not thinking of that would make this not work?

On Fri, May 16, 2014 at 10:40 AM, Bernard Aboba <Bernard.Aboba@microsoft.com
> wrote:

> Based on the discussion at the 15 May ORTC CG meeting, should we:
> * Remove filterParameters/createParameters ?
> * Modify Examples 7 & 8 which call these functions?
> * Do something else?
> My suggestion would be to remove the filterParameters/createParameters
> functions, but keep them in Examples 7 & 8,
> noting that these functions are expected to be provided in Javascript
> libraries.
Received on Monday, 19 May 2014 19:41:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:18 UTC