Re: "mediadiscarded" and "unassignedmediaarriving" - action needed if we want them

On 21/08/15 07:38, Bernard Aboba wrote:
> I understand Martin's PR for mediadiscarded, which roughly parallels
> the RtpUnhandled event from ORTC.
> In both specs, the solution is to obtain an RtpReceiver to handle the
> discarded or unhandled stream.

As far as I understand the PR, this is not part of it (it is just a 
"mediadiscarded" event).

> For 1.0, is the idea to have another way to create RtpReceivers,
> other than vending them?

I do not have the details on what the intention was here really (all 
info I have is what is in the PR comments by Harald), I'd really like to 
see this clarified.

>> On Aug 20, 2015, at 22:01, Stefan Håkansson LK
>> <> wrote:
>> Hi all,
>> a long time ago a PR adding a "mediadiscarded" event was submitted
>> [1]. The purpose was to inform the application that (perhaps due to
>> an SDP offer or answer not having arrived) media that the UA can't
>> associate with an existing track (or RTPreceiver) is arriving (and
>> being dropped on the floor).
>> That PR was in line with what was discussed at the 2014 TPAC.
>> However, there were some later (private) discussion of adding
>> another event that allowed the app to instruct the UA to create a
>> track (and RTPreceiver) for the incoming media. I called that
>> event "unassignedmediaarriving" in the subject line. To my
>> understanding Firefox is even implementing something like this.
>> There is currently no PR that addresses "unassignedmediaarriving",
>> or how "mediadiscarded" and "unassignedmediaarriving" should
>> relate. As we've said that for a feature to be part of 1.0 a
>> (relatively baked) PR should exist before the Seattle f2f meeting
>> we're asking people who want this to start working on such a PR.
>> Stefan for the chairs
>> [1]

Received on Friday, 21 August 2015 06:44:11 UTC