filterParameters #80

Closed
robin-raymond opened this Issue May 9, 2014 · 8 comments

Projects

None yet

3 participants

@robin-raymond
Contributor

What exactly does it do?

@robin-raymond robin-raymond added the 1.1 label May 9, 2014
@aboba
Contributor
aboba commented May 9, 2014

May I ask another (perhaps related question)? What does it do that createParameters doesn't or can't?

For example, it would appear to me that I can rewrite Examples 8 and 9 from the Editor's draft to accomplish the same thing without calling filterParameters. Am I missing something?

EXAMPLE 8

// Assume we already have a way to signal, a transport
// (RTCDtlsTransport), and audio and video tracks. This is an example
// of how to offer them and get back an answer with audio and
// video tracks, and begin sending and receiving them.
function initiate(signaller, transport, audioTrack, videoTrack) {
var audioSender = new RTCRtpSender(audioTrack, transport);
var videoSender = new RTCRtpSender(videoTrack, transport);
var audioReceiver = new RTCRtpReceiver(transport);
var videoReceiver = new RTCRtpReceiver(transport);

signaller.offerCaps({
// The initiator offers its receiver and sender capabilities.
"rtpRecvCaps" : RTCRtpReceiver.getCapabilities(),
"rtpSendCaps" : RTCRtpSender.getCapabilities()
}, function (answer) {
// The responder answers with its sender and receiver capabilities.
// The initiator then creates its audio and video send and receive
// parameters.
var audioSendParams = RTCRtpSender.createParameters(audioTrack,
answer.rtpRecvCaps);
var videoSendParams = RTCRtpSender.createParameters(videoTrack,
answer.rtpRecvCaps);
var audioRecvParams = RTCRtpReceiver.createParameters(
"audio", answer.rtpSendCaps);
var videoRecvParams = RTCRtpReceiver.createParameters(
"video", answer.rtpSendCaps);

audioSender.send(audioSendParams);
videoSender.send(videoSendParams);
audioReceiver.receive(audioRecvParams);
videoReceiver.receive(videoRecvParams);

// Now we can render/play 
// audioReceiver.track and videoReceiver.track.

});
}

EXAMPLE 9

// Assume we already have a way to signal, a transport
// (RTCDtlsTransport), and audio and video tracks. This is an example
// of how to answer an offer with audio and video tracks, and begin
// sending and receiving them.
function accept(
signaller, remote, transport, audioTrack, videoTrack) {
var audioSender = new RTCRtpSender(audioTrack, transport);
var videoSender = new RTCRtpSender(videoTrack, transport);
var audioReceiver = new RTCRtpReceiver(transport);
var videoReceiver = new RTCRtpReceiver(transport);

// The responder answers with its sender and receiver capabilities.
signaller.answerCaps({
"rtpRecvCaps" : RTCRtpReceiver.getCapabilities(),
"rtpSendCaps" : RTCRtpSender.getCapabilities()
});

// The responder creates its audio and video send and receive
// parameters.
var audioSendParams = RTCRtpSender.createParameters(audioTrack,
remote.rtpRecvCaps);
var videoSendParams = RTCRtpSender.createParameters(videoTrack,
remote.rtpRecvCaps);
var audioRecvParams = RTCRtpReceiver.createParameters(
"audio", remote.rtpSendCaps);
var videoRecvParams = RTCRtpReceiver.createParameters(
"video", remote.rtpSendCaps);

audioSender.send(audioSendParams);
videoSender.send(videoSendParams)
audioReceiver.receive(audioRecvParams);
videoReceiver.receive(videoRecvParams);

// Now we can render/play
// audioReceiver.track and videoReceiver.track.
}

@aboba
Contributor
aboba commented May 16, 2014

Based on the discussion at the 15 May ORTC CG meeting, should we:

  1. Remote filterParameters/createParameters ?
  2. Modify Examples 7 & 8 which call these functions?
@aboba
Contributor
aboba commented May 19, 2014

[Peter Thatcher] http://lists.w3.org/Archives/Public/public-ortc/2014May/0121.html

​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?

@aboba
Contributor
aboba commented May 21, 2014

if we changed:

sequence headerExtensions;

To:

sequence headerExtensionPreferences;

in RTCRtpCapabilities, then we could also obtain the information required to do header extensions via exchange of capabilities.

@juberti
juberti commented May 30, 2014

I think this is a slippery slope - you can get something very basic working quickly, but if it's only for demo purposes, who would want to use this over 1.0?

@aboba
Contributor
aboba commented May 30, 2014

To help us understand the implications of Peter's proposal, here is a detailed look at everything that would need to be changed, and what the sample code would look like:
http://lists.w3.org/Archives/Public/public-ortc/2014May/0140.html

@robin-raymond robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Jun 15, 2014
Robin Raymond - Added support for non-multiplexed RTP/RTCP and ICE freezing, as des…
…cribed in Issue 57


w3c#57

- Added support for getRemoteCertificates(), as described in Issue 67
w3c#67

- Removed filterParameters and createParameters functions, as described in Issue 80
w3c#80

- Partially addressed capabilities issues, as described in Issue 84
w3c#84

Addressed WebIDL type issues described in Issue 88
w3c#88

- Addressed Overview section issues described in Issue 91
w3c#91

- Address readonly attribute issues described in Issue 92
w3c#92

- Added ICE restart method to address the issue described in Issue 93
w3c#93

- Added onerror eventhandler to sender and receiver objects as described in Issue 95
w3c#95
f74b889
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment