I've been assigned as ART reviewer for this draft. I am no expert in RTP payload, so this review did not verify the validity of the technical solution, if is sound or not, etc., while I did read it with the most diligence I could.

with the i18n eye, since no user/generic strings seems to be used, don't see any i18n issues.

Comments (not really substantive to the protocol):
- section 7.3.2.1: "An implementation SHOULD be able to understand all media type parameters (including all optional media type parameters), even if it doesn't support the functionality related to the parameter. ". This sentence seems weird to me. If a new media type parameter is defined and the implementation is already used in the field, then there is no way that the implementation will be able to understand that parameter. Maybe I’m not understanding the context here. 
- section 9: "the RTP packet is RECOMMENDED but NOT REQUIRED based on the thoughts". Should this be rephrased using SHOULD and MUST NOT to use RFC2119 wording?
- section 9: "For example, it would be a bad and insecure implementation practice to forward any JavaScript a decoder implementation detects to a web browser.". Cannot parse this sentence. Maybe it is missing a « to » or something. Or it is me.
- section 10: Congestion Control. is after the Security section. Typically, Security is the last section before IANA. No big issue here. Maybe RTP docs do ordering differently. More an observation than real issue.

Nits:
- s/MPGEG-2/MPEG-2/ (unless MPGEG is something I don't know)
- section 7.3.2.1, figure 11: the values "O" and "X" are not used in the table. maybe remove them?

Orthography suggestions (also depends on UK vs US orthographies):
- s/neighbor/neighbour/
- s/signaled/signalled/
- s/signaling/signalling/
- s/behavior/behaviour/