Handling of a=imageattr

[ekr]

Section 5.2.1
o [OPEN ISSUE: Handling of a=imageattr]

[martinthomson]

Discussed in DC: chicken chicken chicken

Harald is being assigned this particular task. He will produce text regarding the generation of and adherence to some image size preferences.

[juberti]

From #30:

IETF 92: add a=imageattr:X recv that contains the decoder limits, minimaxed with an app-specified receive limit (possibly multiple of these if there are multiple codecs with different limits).

Open question: how does the offerer set receive limits other than decoder limits? This again does suggest that RtpReceiver might need to be created at an earlier stage than ontrack.

[martinthomson]

At the answerer, there is always the possibility of setting (mandatory) constraints on the MediaStreamTrack instances. The offerer would have to redo offer/answer to do this though. Mucking with RTCRtpReceiver is another way to achieve the same end, with the same limitation.

We should definitely pick just one option, and probably pick something in the W3C. JSEP only has to explain that there is nothing offer/answer can do to allow the answerer this control.

[juberti]

Well, I wonder if we should generate the RtpReceiver when the offerer's track is added. We wouldn't fire ontrack in that case, but you could get the receiver and frob it before calling createoffer.

[martinthomson]

That's not a bad idea: you do know what RTCRtpReceiver instances are potentially present once you have called setLocalDescription. That's a pretty significant change to the API though (even if it is just a matter of surfacing a new event).

[juberti]

We could just not surface an event; the only implication would be that rtpreceivers could exist before getting ontrack, which would be a non-issue i think. Some spec tweaking needed, but no app changes needed.

[martinthomson]

Yeah, but handling the case where the peer chooses not to send is awkward: the receiver for a rejected media section would have to silently disappear also.

[juberti]

Not necessarily; it could just become dormant.
Agree that we would have to figure out the details, but I think it would be workable.

[fluffy]

If you go back to the WebRTC meeting in seattle / china - being able to do this was one of the key motiviations for creating the doohicky objects

[juberti]

I don't think this was an explicit design goal, but we have bumped into this a couple times now and if we can deal with it without wrecking the design I think it will help us solve this and future problems.