Draft: draft-ietf-rtcweb-jsep

Commentary: The second paragraph of section 3.6.1 seems odd when talking about creating answers , and downright incorrect when talking about offers . Minimally , it needs text to explain why x=0 / y=0 would ever make more sense than using " a = sendonly / recvonly / inactive . " 
 There was a clear rationale for why we did this , as I remember having this exact conversation before , but I need to go dig it up . 
 -- There was a clear rationale for why we did this , as I remember having this exact conversation before , but I need to go dig it up . Ideally , this rationale would be to the document once you find it . 
 Sounds like a good idea . 
 I was able to find it - the concern was that if you offered a = recvonly , you could then potentially change that to a = sendrecv via transceiver.setDirection , so a = imageattr of [ 0 , 0 ] provided a way to prevent any video from being sent without additional complexity . 
 I 'm coming around to  's viewpoint on this one - not sure we should be inventing a new syntax for saying ' do n't send me this video stream ' . 
 Section 3.6.1 describes mandatory constraints applied to an incoming track resulting in a new offer - answer exchange . Since this is " action at a distance " ( modify the track and the PeerConnection emits a negotiation - needed ) , I think this needs to be synced with the webrtc-1.0 API spec , and possibly even media - capture . Also , what 's the state of the track between the changing of constraints at the receiver and the renegotiation ? It seems to me that the track should be scaled at the receiver to fit the agreed - upon constraints . 
 OK , agreed we have moved away from this sort of approach . I guess we could add a new API to RtpReceiver if we decide we need this sort of functionality ; we can either spec said API here in JSEP for future implementation , or drop discussion of it altogether .  ? 
 Dropping discussion seems like the simplest approach ; that will mean that the receiver hands whatever comes to it into the track , and the track processes it like it processes any other source . Simple is good . 
 See PR
Paragraph (version A):
Video size negotiation is the process through which a receiver can
use the "a=imageattr" SDP attribute RFC6236 to indicate what video
frame sizes it is capable of receiving.  A receiver may have hard
limits on what its video decoder can process, or it may wish to
constrain what it receives due to application preferences, e.g. a
specific size for the window in which the video will be displayed.
Paragraph (version B):
Video size negotiation is the process through which a receiver can
use the "a=imageattr" SDP attribute RFC6236 to indicate what video
frame sizes it is capable of receiving.  A receiver may have hard
limits on what its video decoder can process, or it may have some
maximum set by policy.
Paragraph (version A):
In order to determine the limits on what video resolution a receiver
wants to receive, it will intersect its decoder hard limits with any
mandatory constraints that have been applied to the associated
MediaStreamTrack.  If the decoder limits are unknown, e.g. when using
a software decoder, the mandatory constraints are used directly.  For
the answerer, these mandatory constraints can be applied to the
remote MediaStreamTracks that are created by a setRemoteDescription
call, and will affect the output of the ensuing createAnswer call.
Any constraints set after setLocalDescription is used to set the
answer will result in a new offer-answer exchange.  For the offerer,
because it does not know about any remote MediaStreamTracks until it
receives the answer, the offer can only reflect decoder hard limits.
If the offerer wishes to set mandatory constraints on video
resolution, it must do so after receiving the answer, and the result
will be a new offer-answer to communicate them.
Paragraph (version A):
If there are no known decoder limits or mandatory constraints, the
"a=imageattr" attribute SHOULD be omitted.
Paragraph (version A):
Otherwise, an "a=imageattr" attribute is created with "recv"
direction, and the resulting resolution space formed by intersecting
the decoder limits and constraints is used to specify its minimum and
maximum x= and y= values.  If the intersection is the null set, i.e.,
there are no resolutions that are permitted by both the decoder and
the mandatory constraints, this MUST be represented by x=0 and y=0
values.
Paragraph (version B):
The receiver will first intersect any known local limits (e.g.,
hardware decoder capababilities, local policy) to determine the
absolute minimum and maximum sizes it can receive.  If there are no
known local limits, the "a=imageattr" attribute SHOULD be omitted.
Paragraph (version B):
Otherwise, an "a=imageattr" attribute is created with "recv"
direction, and the resulting resolution space formed from the
aforementioned intersection is used to specify its minimum and
maximum x= and y= values.  If the intersection is the null set, i.e.,
the degenerate case of no permitted resolutions, this MUST be
represented by x=0 and y=0 values.
Paragraph (version A):
The "a=imageattr" field is payload type specific.  When all video
codecs supported have the same capabilities, use of a single
attribute, with the wildcard payload type (*), is RECOMMENDED.
However, when the supported video codecs have differing capabilities,
specific "a=imageattr" attributes MUST be inserted for each payload
type.
Paragraph (version A):
This declaration indicates that the receiver is capable of decoding
any image resolution from 48x48 up to 640x360 pixels.
Paragraph (version B):
The "a=imageattr" field is payload type specific.  When all video
codecs supported have the same capabilities, use of a single
attribute, with the wildcard payload type (*), is RECOMMENDED.
However, when the supported video codecs have different limitations,
specific "a=imageattr" attributes MUST be inserted for each payload
type.
Paragraph (version B):
This declaration indicates that the receiver is capable of decoding
any image resolution from 48x48 up to 1280x720 pixels.