Handling of RTCRtpParameters #136

Closed
aboba opened this Issue Jul 21, 2014 · 6 comments

Projects

None yet

2 participants

@aboba
Contributor
aboba commented Jul 21, 2014

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
Contributor
aboba commented Jul 29, 2014

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
Contributor
aboba commented Jul 29, 2014
  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).

@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 aboba closed this Aug 7, 2014
@robin-raymond robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Aug 19, 2014
Robin Raymond Clarification of the ICE restart issue, as noted in:
w3c#93

Clarified onerror usage in sender and receiver objects, as noted in:
w3c#95

Clarified SST-MS capability issue noted in:
w3c#108

Clarification of send() and receive() usage as noted in:
w3c#119

Changed ICE state diagram as noted in:
w3c#122

Removed getParameters methods and changed send() method as noted in:
w3c#136

Changed definition of framerateScale and resolutionScale as noted in:
w3c#137

Substituted "muxId" for the "receiverId" as noted in:
w3c#138
w3c#140

Clarified the setting of track.kind as described in:
w3c#141

Added SSRC conflict event to the RTCRtpSender, as described in:
w3c#143

Addressed the "end of candidates" issues noted in:
w3c#142
w3c#144
4916cd5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment