Re: [MMUSIC] [Technical Errata Reported] RFC5576 (7544)

[Christer Holmberg <[e-mail]>]

>> I am not sure I understand your comment, nor the comment from Philipp.
>> They seem to be related to some implementation, because I have no idea
>> what you refer to when you say "members", "set", "count" and "field"
>> :)
>>
>> Are there implementations that add multiple instance of the same
>> ssrc-id value to the sscr-group attribute?
>
> There was one implementation that crashed when someone sent it an ssrc-group
> with multiple occurences of the same SSRC, yes. Whether this was an attack 
> or a mistake, I don't know.

It would be nice to know WHY it was sent. Perhaps they think it is a valid 
case, which may also have to be dealt with.

Regards,

Christer


> -----Original Message-----
> From: mmusic <[e-mail]> On Behalf Of Harald Alvestrand
> Sent: Monday, 19 June 2023 21.25
> To: [e-mail]
> Subject: Re: [MMUSIC] [Technical Errata Reported] RFC5576 (7544)
>
> The actual case where it did not go well was a case where the members
> were internally represented as a set, but where the count was taken from the 
> field.
>
> The code added two elements, and then removed two elements - when
> removing the second element, there was no such member in the set any more.
>
> (Not the exact code, but illustrates the prinicple)
>
> This violates the Principle of Least Astonishment. We shouldn't violate 
> that.
>
> On 6/16/23 03:18, Christer Holmberg wrote:
>> Why would someone use something like a=ssrc-group:FID 1234 1234? And,
>> even if someone does, what error would it cause?
>>
>> Also, we don't have similar text for e.g., the SDP group attribute.
>>
>> Regards,
>>
>> Christer
>>
>>
>> -----Original Message-----
>> From: mmusic <[e-mail]> On Behalf Of RFC Errata System
>> Sent: Thursday, 15 June 2023 21.37
>> To: [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; Francesca Palombini
>> <[e-mail]>; Bo Burman
>> <[e-mail]>; [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail]
>> Subject: [MMUSIC] [Technical Errata Reported] RFC5576 (7544)
>>
>> The following errata report has been submitted for RFC5576,
>> "Source-Specific Media Attributes in the Session Description Protocol
>> (SDP)".
>>
>> --------------------------------------
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid7544
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Philipp Hancke <[e-mail]>
>>
>> Section: 4.2
>>
>> Original Text
>> -------------
>> Every <ssrc-id> listed in an "ssrc-group" attribute MUST be defined
>> by a corresponding "ssrc:" line in the same media description
>>
>> Corrected Text
>> --------------
>> Every <ssrc-id> listed in an "ssrc-group" attribute MUST be defined
>> by a corresponding "ssrc:" line in the same media description and
>> MUST appear only once in this ssrc-group
>>
>> Notes
>> -----
>> The goal is to clarify that something like
>>     a=ssrc-group:FID 1234 1234
>> is not valid. While this is demuxable (in the BUNDLE sense) it would
>> require chaining of ssrc-demuxing and payload type demuxing which is
>> a lot of complexity.
>> The uniqueness is already implied by the following sentence (emphasis
>> is
>> mine):
>>      The SDP media attribute "ssrc-group" expresses a relationship
>> among
>> *several* sources of an RTP session earlier in the section.
>>
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or rejected.
>> When a decision is reached, the verifying party can log in to change
>> the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC5576 (draft-ietf-mmusic-sdp-source-attributes-02)
>> --------------------------------------
>> Title               : Source-Specific Media Attributes in the Session
>> Description Protocol (SDP)
>> Publication Date    : June 2009
>> Author(s)           : J. Lennox, J. Ott, T. Schierl
>> Category            : PROPOSED STANDARD
>> Source              : Multiparty Multimedia Session Control RAI
>> Area                : Real-time Applications and Infrastructure
>> Stream              : IETF
>> Verifying Party     : IESG
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic