Handling of RTCRtpParameters

[aboba]

At the July 20 ORTC CG meeting, it was proposed that the RTCRtpParameters object be completely filled in when passed to RTCRtpReceiver.receive() or RTCRtpSender.send(). If the passed RTCRtpParameters could not be implemented the browser would provide an Exception or Error rather than modifying RTCRtpParameters to indicate what it had implemented.

All of this put together implies that there is no longer a need for getParameters.

It also implies that we do not need a Promise for send.

[aboba]

I have some questions about how this affects latching rules.

Let us say that we want to specify the Payload Type for an incoming audio or video stream, but don't know the SSRC yet. Ideally, we would like to be able to receive the first stream without an RtpUnhandled event.

1. By requiring RTCRtpParameters to be "completely filled in", does this mean that there is no longer a way to indicate that "any SSRC" is acceptable (e.g. wildcard)? If so does this imply that the RtpUnhandled event will be thrown on reception of the first SSRC? Or is there a way to specify an SSRC wildcard?
2. Assuming that there is a way to specify an SSRC wildcard, presumably there is no RtpUnhandled event, since the stream was delivered to an existing RTCRtpReceiver object. If so, once the first stream is received on the Payload Type, what happens? Is this reflected in the RTCRtpParameters object (e.g. SSRC is filled in)? If not, where/how is the "latching" state reflected?

[aboba]

1. The definition of "Completely filled in" is different on the Receiver and the Sender. For a receiver, if RTCRtpEncodingParameters.ssrc is not filled in, the next SSRC will "latch" and there is no RTPUnhandledEvent. For a sender, if RTCRtpEncodingParameters.ssrc is not filled in, an InvalidParameters Exception is thrown.
2. There is no "latching event", nor does "latching" cause RTCRtpEncodingParameters to be updated. The developer should not need to know what the "latched" SSRC is.

[pthatcherg]

In another email, I pointed out that I think we should allow the
RtpParameters to not be "filled in" entirely, but allows some gaps that
mean "I don't care", which I think would resolve this issue in a clean way.

On Tue, Jul 29, 2014 at 1:13 PM, aboba notifications@github.com wrote:

The definition of "Completely filled in" is different on the Receiver
and the Sender. For a receiver, if RTCRtpEncodingParameters.ssrc is not
filled in, the next SSRC will "latch" and there is no RTPUnhandledEvent.
For a sender, if RTCRtpEncodingParameters.ssrc is not filled in, an
InvalidParameters Exception is thrown.
2.

There is no "latching event", nor does "latching" cause
RTCRtpEncodingParameters to be updated. The developer should not need to
know what the "latched" SSRC is.

—
Reply to this email directly or view it on GitHub
#136 (comment).

[aboba]

Suggestion from Peter: http://lists.w3.org/Archives/Public/public-ortc/2014Jul/0061.html

[pthatcherg]

And now I'm contradicting myself, because the more I think about it, the
more I think we should just let the JS leave things blank, and there's no
reason to let the JS know what was "filled in" because it doesn't matter.

On Tue, Jul 29, 2014 at 2:29 PM, aboba notifications@github.com wrote:

Suggestion from Peter:
http://lists.w3.org/Archives/Public/public-ortc/2014Jul/0061.html

—
Reply to this email directly or view it on GitHub
#136 (comment).

[aboba]

Proposed Resolution: http://lists.w3.org/Archives/Public/public-ortc/2014Aug/0038.html