Re: Issue 48: Undefined RTCRtpListener behavior

Since this is one of the oldest outstanding Issues filed against the ORTC API, it seems like a good idea to restart the discussion of how it might be resolved.   Below find a draft proposal for how the matching rules might work.  Comments welcome.

Section 8.3  Matching rules

To determine whether an RTP stream is configured to be processed by an existing RTCRtpReceiver object, the RTCRtpListener attempts to match the values of an incoming RTP packet's Payload Type and SSRC fields as well as the value of the muxId (if present in the MID RTP header extension) against two tables maintained within the browser, the Latching table and the Receiver table.    When the RTCRtpListener object receives a packet over an RTCDtlsTransport, the SSRC field is checked against the latching table.  If there is no match, the receiver table is consulted.  An RTP packet can be delivered to no more than one RTCRtpReceiver object, so once a match is found, the process terminates.

The Receiver table consists of (SSRC, PT, muxId, RTCRtpReceiver) tuples, based on RTCRtpReceiver objects. Entries are added on to the end of the table when .receive is called and are removed from the table when .stop is called.  Within a tuple, the value of SSRC is determined from RTCRtpReceiver.RTCRtpParameters.RTCRtpEncodingParameters.ssrc, the value of Payload Type is determined from RTCRtpReceiver.RTCRtpParameters.RTCRtpCodecParameters.payloadType
and the value of muxId is determined from RTCRtpReceiver.RTCRtpParameters.muxId.   TODO:  Revise this paragraph based on the outcome of the discussion on FEC/RTX/RED.  If the RTCRtpEncodingParameters.ssrc or RTCRtpParameters.muxId attributes are not set, then any values within an incoming RTP packet will match.  If RTCRtpCodecParameters.payloadType is not set then .receive will cause an exception to be raised and no tuple will be added to the Receiver table.

On checking for a match within the Receiver table, the SSRC and PT fields of the RTP packet, along with the MID RTP header extension (if present) are checked against each table entry.  If the SSRC field in the packet exactly matches the SSRC entry in the Receiver table (or if the SSRC table entry is not present), then the PT field in the packet is compared against the PT entry in the Reciver table.  If both the SSRC and PT fields match, then if the MID RTP header extension is present, the MID value is compared against the muxId entry in the Receiver table (if present). If a match is found on all table entries, then the RTP packet is routed to the RTCRtpReceiver identified in the table.  If a Receiver table entry does not match, the next Receiver table entry is consulted.

The latching table consists of (SSRC, RTCRtpReceiver) entries. If the SSRC field in the RTP packet matches an SSRC entry in the table, the RTP packet is routed to the corresponding RTCRtpReceiver object.  Entries are added on to end of the table when an RTP packet does not match any of the SSRCs within the Receiver table, but does match a PT or muxID entry.  Entries are deleted from the table when either .stop or .receive is called on an RTCRtpReceiver object. Implementers can also expire latching table entries based on timeout value chosen by the implementation.  In order to protect against denial of service attacks, implementations should limit the memory allocated to the Latching table.