RE: Re: Issue 48: Undefined RTCRtpListener behavior

Here is a revised version of the proposal, correcting some errors and omissions noticed when going over it again: 

8.3 Matching rules

When the RTCRtpListener object receives an RTP packet over an RTCDtlsTransport, the RTCRtpListener attempts to match the values of fields within the incoming RTP packet against the latching table and if no match is found, against the receiver table. If no match is found withn either table, the unhandledrtp event is raised. Once a match is found within either the latching table or the receiver table, the RTP packet is delivered to the RTCRtpReceiver object referenced in the matching table entry. Since the matching process terminates at that point, an RTP packet can be delivered to no more than one RTCRtpReceiver object.

The latching table consists of (SSRC, receiver) entries, sorted by SSRC from lowest to highest value. There are no wildcard SSRCs within the latching table, so that the SSRC attribute always has a specific value. The SSRC field in the RTP packet is compared against the SSRC attribute in the latching table entries and if an exact match is found, the RTP packet is delivered to the RTCRtpReceiver object represented by the value of the receiver attribute.

The receiver table consists of (SSRC, PT, muxId, receiver) tuples, sorted by SSRC from lowest to highest (with wildcard entries last), then by PT and finally, by muxId in lexical order. The SSRC, PT and muxId attributes are matched against fields from the RTP packet, with the receiver attribute representing the RTCRtpReceiver object to which the RTP packet is delivered if a match is found.

Entries are added to the receiver table when receiver.receive(parameters) is called, based on the RTCRtpParameters object parameters passed as an argument. All receiver table entries providing for delivery of RTP packets to an RTCRtpReceiver object receiver are removed when receiver.stop() is called.

A receiver table entry is added for each RTCRtpEncodingParameters object represented by parameters.encodings[i]. Within an entry, the value of SSRC is obtained from parameters.encodings[i].ssrc; the value of PT is obtained from parameters.encodings[i].codecPayloadType, the value of muxId is obtained from parameters.muxId.

If parameters.encodings[i].ssrc is not set, the SSRC attribute is set to zero and is considered a wildcard which will match any value of the SSRC field in the RTP packet. If parameters.muxId is not set, the muxId attribute is set to "" and is considered a wildcard which will match any value of the MID RTP header extension, if present. If parameters.encodings[i].codecPayloadType is not set for any value of i, then receiver.receive(parameters) will throw an exception and no entries will be added to the receiver table.

TODO: Revise this paragraph based on the outcome of the discussion on FEC/RTX/RED.

In order to check an entry in 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 receiver table entry. If the SSRC field in the packet exactly matches the value of the SSRC attribute in the receiver table entry (or if the SSRC table entry is not present), then the PT field in the RTP packet is compared against the value of the PT attribute in the receiver table entry. If both the SSRC and PT fields match, then if the MID RTP header extension is present, the MID value is compared against the value of the muxId attribute in the receiver table entry. If the packet fields match the SSRC, PT and muxId attributes, then the RTP packet is delivered to the RTCRtpReceiver object represented by the receiver attribute in the receiver table entry. If a receiver table entry does not match, the next receiver table entry is tested until all entries are exhausted. If no matches are found, then an unhandledrtp event is raised.

The latching table consists of (SSRC, receiver) entries, sorted by SSRC from lowest to highest value. The value of the SSRC attribute must exactly match the SSRC field in the RTP packet for a match to occur; the SSRC attribute in the latching table has no wildcard value. The receiver attribute represents the RTCRtpReceiver object which the RTP packet is delivered to if a match occurs. Latching table entries are added when an RTP packet matches a receiver table entry with an SSRC attribute with a wildcard value. Latching table entries with a receiver attribute are deleted when either receiver.stop() or receiver.receive() is called. Implementations may also remove latching table entries based on expiration of a timer. In order to protect against denial of service attacks, implementations should limit the memory allocated to the latching table.

Received on Wednesday, 3 December 2014 07:35:53 UTC