Re: Issue 48: Undefined RTCRtpListener behavior

One of the longest outstanding issues relating to the ORTC API has been the behavior of the latching rules (see: https://github.com/openpeer/ortc/issues/48) that govern how an incoming RTP packet is steered to an existing RTCRtpReceiver object (or if such an object cannot be identified, when an RTPUnhandled Event is thrown).

Now that other aspects of the API are more solid, it is a good time to come back to the latching rules (and in particular, the goals for those rules).

Several  use cases come to mind:


1.       Payload Type matching.  For audio applications where only a single stream is expected, it would be useful if it were not necessary to specify RTCRtpEncodingParameters.ssrc or RTCRtpParameters.muxId in either RTCRtpReceiver.receive() or RTCRtpSender.send(), only to provide a Payload Type value in RTCRtpCodecParameters.payloadType.

2.       SSRC conflict handling.  As we have discussed, if  the developer does not specify SSRCs within the RTCRtpParameters object passed to RTCRtpSender.send(), then the browser chooses the SSRCs, and an RTCSsrcConflictEvent is never thrown (see Section 6.4).  Since there is no way for the developer to retrieve the new SSRC value (or the originally chosen value for that matter), it would be highly desirable for the latching rules to make it unnecessary for the application developer to need this information.  As an example, fi the developer originally set RTCRtpParameters.muxId when calling RTCRtpSender.send(), but did not set RTCRtpEncodingParameters.ssrc, it would be useful if the latching rules caused the RTP stream with the newly chosen SSRC and the same muxId to be steered to the same RTCRtpReceiver that received the stream with the previous SSRC and muxId.