Subject: [MMUSIC] RFC 6263 - interpretation validation: "a=imageattr" is advisory, not mandatory

From: Harald Alvestrand <[email-masked]>
Date: Thu, 19 Apr 2012 17:34:01 +0200

Hello MMUSICers,

Roni Even and I just had a discussion on the rtcweb list, which led to 
an interesting conclusion with regard to the meaning of a=imageattr from 
RFC 6236.

My question (part of a thread) was:

>  I interpret the example in 4.2.1 (second alternative) as consisting of
>  4 messages; in an offer/answer exchange, this would look like:
>  
>  1) Alice ->  Bob: OFFER
>        a=imageattr:97 send [x=800,y=640,sar=1.1,q=0.6] [x=480,y=320] \
>                       recv [x=330,y=250]
>  2) Bob ->  Alice: ANSWER
>        a=imageattr:97 recv [x=800,y=640,sar=1.1] \
>                       send [x=[320:16:640],y=[240:16:480],par=[1.2-1.3]]
>  3) Alice ->  Bob: OFFER (re-invite, probably)
>        a=imageattr:97 send [x=800,y=640,sar=1.1] \
>                       recv [x=336,y=256]
>  4) Bob ->  Alice: ANSWER
>        a=imageattr:97 recv [x=800,y=640,sar=1.1] \
>                       send [x=336,y=256]
>  
>  So after message 2, Bob cannot send anything, since he can't reproduce
>  what Alice asked for, right?
>  
>  And after message 2, Alice can only send 800x640 with a sar of 1.1,
>  right? It's forbidden for Alice to send a noncompensated image, or a
>  640x480 image?
>  
>  Again, it's the use of the words "wishes" and "desires" that I want to
>  be sure I understand correctly - as used in RFC 6236, they both mean
>  "demand" / "require" / "MUST". Right?
>  

Roni's response was:
> This is a good question, my view will be that since Alice gave a preference
> like profile and level (and maybe bandwidth) in the original offer than Bob
> can send any video that will be within this level. The image attribute says
> that Alice prefers to get something specific to help with processing (note
> that Alice can limit the received video by using max-mbps and max-fs for
> H.264). It may be good to discuss it with others from MMUSIC.
> The usage of the image attribute in my view is more relevant to allow the
> receiver to ask for a specific image size since this is not defined in H.264
> (in H.263 you can specify the common specific resolutions and frame rate
> using the optional parameters in RFC 4629). This was a requirement to allow
> a receiver to ask for a specific size.
> The usage of "wish" was because H.264 encoder is not required to support
> scale to a specific resolution and a compliant decoder must support
> everything within the negotiated profile and level. So when a receiver asks
> for a size it can happen only if the encoder can do it but if the encoder
> cannot it is still compliant.
If this interpretation is correct, it means that the imageattr attribute is useful only for carrying "desired" (non-mandatory) constraints on the incoming video stream, and cannot be used to require a specific resolution or range of resolutions from the sender (mandatory constraints).

If RTCWEB wishes to have such mandatory constraints, it must propose a followup or extension to RFC 6236; it cannot simply refer to RFC 6236 for this.

Is this a correct interpretation?

                         Harald Alvestrand