This comment has been minimized.

Here are some proposed changes to Section 8 in order to sync with the pull request:

The RTCRtpListener Object

The RTCRtpListener listens to RTP packets received from the RTCDtlsTransport, determining whether an incoming RTP stream is configured to be processed by an existing RTCRtpReceiver object. If no match is found, the unhandledrtp event is fired. This can be due to packets having an unknown SSRC, payload type or any other error that makes it impossible to attribute an RTP packet to a specific RTCRtpReceiver object. The event is not fired once for each arriving packet; multiple discarded packets for the same SSRC should result in a single event.

Note that application handling of the unhandledrtp event may not be sufficient to enable the unhandled RTP stream to be rendered. The amount of buffering to be provided for unhandled RTP streams is not mandated by this specification and is recommended to be strictly limited to protect against denial of service attacks. Therefore an application attempting to create additional RTCRtpReceiver objects to handle the incoming RTP stream may find that portions of the incoming RTP stream were lost due to insufficient buffers, and therefore could not be rendered.

8.1 Overview

An RTCRtpListener instance is associated to an RTCDtlsTransport.

8.2 Operation

An RTCRtpListener instance is constructed from an RTCDtlsTransport object.

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 the RTCRtpReceiver.RTCRtpParameters.RTCRtpCodecParameters.payLoadType, RTCRtpReceiver.RTCRtpParameters.RTCRtpEncodingParameters.ssrc, and RTCRtpReceiver.RTCRtpParameters.muxId attributes of configured RTCRtpReceiver objects.

onunhandledrtp of type EventHandler, , nullable
The event handler which handles the RTCRtpUnhandledRtpEvent, which is fired when the RTCRtpListener detects an RTP stream that is not configured to be processed by an existing RTCRtpReceiver object.

The unhandledrtp event of the RTCRtpListener object uses the RTCRtpUnhandledEvent interface.

Firing an RTCRtpUnhandledEvent event named e means that an event with the name e, which does not bubble (except where otherwise stated) and is not cancelable (except where otherwise stated), and which uses the RTCRtpUnhandledEvent interface must be created and dispatched at the given target.

This comment has been minimized.

At the ORTC CG meeting on January 27, 2015 the question was raised about whether the WebRTC 1.0 RTCMediaDiscardedEvent was designed to deal with incoming RTP streams which were unsignaled, or whether this (or another event) was to deal with malformed packets that would have to be discarded. Sentiment was to stay with unhandledrtp event, but to investigate the need for a mediadiscarded event as well.

This comment has been minimized.

I think the discarded event is because media cannot be routed to an m line for decoding. In SDP world, there's no easy fix because you need to do an offer / answer exchange and by the time you complete O/A it's too late to fix so discarded is appropriate. But in ORTC we can fix this without any O/A so therefor it's unhandled since a new receiver object can quickly be setup.