Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)
Extracted elements (26)
It is recommended that a device with no image size preference still includes 'imageattr' with wildcard parameters (e.g., 'a=imageattr:97 send * recv *') so that the other side can express its own preferences. Without this, the answerer cannot include imageattr in the answer.
Rescaling video on the sender/encoder side is preferred because camera software already has zooming/cropping functionality, quality loss from rescaling is lower before encoding than after decoding, and it enables 'what you send' preview on the display.
The answerer should not include an image attribute in the answer if it was not present in the offer, because the offerer likely does not understand the attribute, and inclusion may conflict with offer/answer rules for handling the attribute.
The attribute is named 'imageattr' rather than a size-specific name to make it generic enough to accommodate future image-related parameters beyond just image size, such as sample aspect ratio and picture aspect ratio.
The sar parameter allows a range of values to be offered (e.g., sar=[0.91,1.0,1.09,1.45]) so that the receiver can select the preferred sample aspect ratio rather than requiring rescaling on the receiver side when the sender's sar does not match the receiver's display.
For H.263, the fmtp line defines supported image sizes and maximum framerates that the answerer cannot modify. The CUSTOM profile may be used for image size negotiation, but asymmetry requires two unidirectional media descriptions with sendonly/recvonly.
The 'imageattr' attribute can be used within the SDP Capability Negotiation (SDPCapNeg, RFC 5939) framework using the 'a=acap' parameter, and with the SDP Media Capability Negotiation extension using 'a=mscap' or parameter substitution with '%1%' notation.
When 'imageattr' is used with layered codecs transported in different RTP streams, the attribute must be specified per media description. The solution is either to specify the same image attribute for each layer's media description or to specify it only for the base layer.
When using 'imageattr' with H.264, the codec's sprop-parameter-sets in the fmtp line describes the image size for the stream and cannot be changed by the answer; potential conflicts between imageattr negotiation and sprop-parameter-sets must be resolved, possibly requiring a second offer/answer round.
A receiver of SDP containing the image attribute MUST ensure that the parameters have values that are reasonable and that the device can handle the implications in terms of memory and CPU usage. Failure to sanity-check parameters may result in memory or CPU exhaustion.
An entity processing the 'imageattr' attribute MUST ignore any unknown parameters in the offer and MUST NOT include them in the generated answer, ensuring backwards compatibility with future parameter additions.
For sendrecv streams, both send and recv directions SHOULD be present in the SDP. For inactive streams it is RECOMMENDED that both directions are present.
If the image attribute is included in the SDP answer but none of the entries are usable or acceptable, the offerer MUST resort to other methods to determine the appropriate image size and MUST issue a new offer/answer without the image attribute.
If the image attribute is not included in the SDP answer, the offerer SHOULD continue to process the answer as if the mechanism had not been offered.
It is RECOMMENDED to negotiate the image size during session renegotiation (e.g., when a user switches devices or connects to an external monitor), using SIP-REFER or SIP-UPDATE methods.
The response MUST NOT include a sar parameter if there is no acceptable value given. Inclusion of sar in the response is interpreted as acceptance; removal is treated as non-acceptance.
The 'send' keyword and corresponding attr-list MUST NOT occur more than once per image attribute. Similarly, the 'recv' keyword and corresponding attr-list MUST NOT occur more than once per image attribute.
When the payload type number differs between offer and answer, the image attribute in the answer MUST be split: use the offer's PT for the send direction and the answer's PT for the recv direction. Using wildcard in either the offer or answer instead MUST NOT be used.
The 'imageattr' SDP attribute is a media-level attribute used in Offer/Answer exchanges to negotiate image attribute parameters including image resolution (x, y), sample aspect ratio (sar), picture aspect ratio (par), and preference (q).
The par (picture aspect ratio) parameter indicates a range of allowed ratios between x and y physical size as 'par=[ratio_min-ratio_max]', used to constrain the set of valid x/y resolution combinations.
The q parameter specifies preference for a given image attribute set, ranging from 0.00 to 1.00 with a default of 0.5. A higher value indicates higher preference for that set.
The sar (sample aspect ratio) parameter is defined as dx/dy where dx and dy are the physical pixel sizes. Square pixels give sar=1.0. In the send direction, sar defines the aspect ratio associated with the given resolution; in the recv direction, sar expresses the receiver's preferred aspect ratio. Default sar value is 1.0 if absent.
The xyrange parameter supports three forms: a bracketed range with optional step '[lower:step:upper]', a bracketed list of discrete values '[v1,v2,...]', or a single value. The step defaults to 1 if omitted. The rightmost xyvalue MUST be higher than the leftmost.
RFC 6236 registers a new SDP attribute 'imageattr' (long form: 'Image attribute') as a media-level attribute not subject to charset, in the SDP attribute registry per RFC 4566 guidelines.
The image attribute parameters (especially image size values) can be set to values that cause memory or CPU exhaustion, either by mistake or by a malicious SDP sender. This is analogous to extreme values in a=fmtp lines. Implementers should also consider DoS attacks not detectable by parameter checking alone.
The 'imageattr' attribute syntax is defined in ABNF: 'imageattr:' PT followed by one or two direction keywords ('send' or 'recv') each with an attr-list. PT is a payload type number (1*DIGIT) or wildcard '*'. Each set is enclosed in brackets with x= and y= xyrange values and optional key-value pairs for sar, par, and q.