RE: Issue 136: Handling of RTCRtpParameters

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