Re: Issue 136: Handling of RTCRtpParameters

I like your description, and I think we should support both A and B, except
that I don't think we need to have a "fill-in" function.  A JS library
could do that easily, and no support from the browser is needed.  And the
"easy path" for simple apps that aren't using a library should be "B" (use
the receiverID).




On Tue, Jul 29, 2014 at 4:11 PM, Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

>  Agree for the receiver object, where it makes sense to have missing
> values such as SSRCs mean “I don’t care”.   As long as there is enough
> information in RTCRtpEncodingParameters to determine which receiver object
> to route an incoming RTP packet to (e.g. via the Payload Type) an
> RtpUnhandledEvent would not fire.   While the receipt of the initial SSRC
> would cause internal “latching” this need not imply “filling in”
> RTCRtpParameters, which always retains the same value it had when
> RTCRtpReceive.receive was called.  A use case where the developer would
> need to retrieve the “latched” SSRC does not come to mind (and if we ever
> think of one, we should probably fix the API so that it isn’t needed).
>
>
>
> For the sender object, it seems that the situation depends on whether we
> have a  “trackID”.  For the sender object, we can have missing values mean
> “browser picks”, and we only need to retrieve the information if there is a
> need to signal it to the receiver.  It would simplify things for the
> developer if the receiver object would not need to preset SVC layering
> information or SSRCs.   Where the decoder can decode anything the encoder
> can encode, this seems possible, at least for SST-SS.  The receiver object
> can specify a payload type but no SSRC,  and rely on “latching” to steer
> the layer (all with the same SSRC) to the receiver object.
>
>
>
> However, if simulcast or SST-MS is being used, we need to steer multiple
> SSRCs into the same “track”.   Two ways of doing this come to mind:
>
>
>
> a.       Filling in the SSRCs in RTCRtpEncodingParameters on the
> receiver.  Presumably the SSRCs need to be obtained via signaling which
> implies that they need to be retrievable on the sender.  One way to handle
> this is to have a “fill in” function that is called prior to calling
> RTCRtpReceiver.receive.
>
> b.      Track-ID.  If there is a track-ID in the RTP packets (e.g. via an
> RTP extension), then the RTCRtpEncodingParameters can include the “track
> id” and any received SSRC with that trackID would “latch” into the
> RTCRtpReceiver object.  So the Receiver no longer needs to preset the SSRCs
> it is expecting and therefore we don’t need to retrieve them on the sender
> side.
>
>
>
>
>
> *From:* Peter Thatcher [mailto:pthatcher@google.com]
> *Sent:* Tuesday, July 29, 2014 1:56 PM
> *To:* Bernard Aboba
> *Cc:* public-ortc@w3.org
> *Subject:* 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?
>
>
>