AMWA-TV / sdpoker

A patched version of Streampunk/sdpoker with additional source-filter testing and bug fixes, used by AMWA-TV/nmos-testing
Apache License 2.0
12 stars 8 forks source link

checkST2110: Add stricter a=mid position verification #12

Open kierank opened 2 years ago

garethsb commented 2 years ago

Hey, Kieran. Attribute lines have to appear at the end of the media description, but as far as I know there is no ordering requirement for the mid attribute within the attributes.

kierank commented 2 years ago

I believe this positioning is required by RFC 5888 section 6: https://datatracker.ietf.org/doc/html/rfc5888#section-6 Also section 3.

garethsb commented 2 years ago

I must be missing something as I can't see anything in section 6 or section 3 that says the mid attribute has to be last.

kierank commented 2 years ago

I don't think it's clear in any RFC or SMPTE documents but if the definition of a group contains the values between a=group...XXX...a=mid:1...XXX...a=mid:2, any new "m=" lines must therefore have a=group or a=mid preceding such lines.

SMPTE RP 2110-23 does seem to try and explain this actually.

kierank commented 2 years ago

You are right though, some people are saying the group is defined as all the lines between m= and the next m=, but some are using the a:mid lines as the boundaries for a group.

garethsb commented 2 years ago

if the definition of a group contains the values between a=group...XXX...a=mid:1...XXX...a=mid:2

I think this interpretation is incorrect. One media description is all the lines between one m= line and the next/end, and each media description has zero or more a= lines at the end that define attributes of that media description. That's specified by RFC 4566 section 5 (or the newer RFC 8866 section 5).

kierank commented 2 years ago

I agree that the RFC wants delimitation via "m=". However SMPTE RP 2110-23 says use "a:mid=" and this appears to be what many vendors are doing.

garethsb commented 2 years ago

Oh, good grief, you're right, SMPTE RP 2110-23:2019 Section 5.3 is indeed a truly horrible misrepresentation of the underlying SDP spec.

image

(The examples are also flawed as they don't at least call out that the blank lines included are not actually permitted in SDP data and the SSN format-specific parameter values are quoted, with U+201D RIGHT DOUBLE QUOTATION MARK, which I don't believe is valid.)