Re: Issue 136: Handling of RTCRtpParameters

I think we should allow things to not be completely filled in, but have
missing values, such as SSRCs.  If they are not filled in, they basically
mean "I don't care", and the JS would never have a way to get to them
(getParameters() would not be "filled in"; it would still be missing
values).  For the sender, the sending browser would just pick a value.  For
the receiver, it would mean "demultiplex on something else", perhaps the
receiverId or the payload type.

The RtpUnhandled event would still get called if the packet couldn't find
an RtpReceiver to route to, such as if a packet came in with no RtpReceiver
that matched by SSRC, Payload Type, or receiverId.  But I suppose one could
add an RtpReceiver that includes every possible payload type, and "I don't
care" SSRC, and that would make sure all packets to go that RtpReceiver (if
not already taken by another RtpReceiver), and thus RtpUnhandled wouldn't
be fired.

I don't see any reason to have the "latching state" be reflected anywhere.
 The only reason I can imagine wanting that is for debugging, in which case
maybe some stats about it might be useful, but I don't see anything other
than that.


On Tue, Jul 29, 2014 at 9:43 AM, Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

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