a=imageattr negotiation specification

This change adds a=imageattr generation, parsing, and guidelines for usage.
On 06/11/2014 05:16 PM, Martin Thomson wrote:
>
> In draft-ietf-rtcweb-jsep.xml:
>
> > +            digits, and rounding the maximum up to four decimal digits.</t>
> > +          </section>
> > +
> > +          <section title="Intersection of imageattr values">
> > +            <t>When it is necessary to form an intersection between local
> > +            capabilities and proposed capabilities, as will happen when
> > +            generating answers and when considering an answer the following
> > +            procedure is used, where "result" is the proposal being generated,
> > +            and "proposal" is the imageattr from the corresponding incoming
> > +            m-line.</t>
> > +
> > +            <t>The intention of the intersection algorithm is that the result
> > +            should be a set of capabilities that are acceptable by both sides,
> > +            with priority given to the formats preferred by each side.</t>
> > +
> > +            <t>[[TODO: Specify an actual algorithm]]</t>
>
> I think that the only reasonable thing to do is what you always do 
> with SDP: share what you are willing to receive. And then the same 
> rules apply in both directions equally.
>
> Sure, the answerer has the advantage of knowing what the offerer is 
> willing to receive, but I'm going to recommend that they don't alter 
> their recv attributes at all.
>

For the recv part of a=imageattr, makes sense.
The question is more what we put in the send part of a response.


> —
> Reply to this email directly or view it on GitHub 
> <https://github.com/rtcweb-wg/jsep/pull/49/files#r13654699>.
>