Re: [MMUSIC] RFC 5576 is da answah

[Christer Holmberg <[e-mail]>]

Hi,

> Are you seeing the canyon as being in-SDP signalling vs out-of-SDP signalling?
> If CLUE goes with multiple streams per m-line, and in-SDP signalling, it needs RFC 5576.
> If out-of-band signalling needs to refer to SSRCs, we need unique identifiers (SRCNAME or MSID) that out-of-band 
> signalling can use to refer to the flows. Those will likely use RFC 5576 too.
>
> If RFC 5576 is to be "the answah", then MMUSIC needs to fill in the details of how the SDP negotiation works. 

Agree. The same issues apply for both CLUE and RTCWEB, so it needs to be described on a general level.

> Alternatively, if the negotiation is to occur outside SDP (as advocated in CLUE), then we need an explicit statement of where 
> the boundaries lie.  The middle path (pursuing neither with conviction) doesn't seem viable to me. 

CLUE has not yet decided what goes in SDP, and what goes into the CLUE channel.

My suggestion has been that "CLUE application specific data" (e.g. spatial relationship information) goes into the CLUE channel, while "transport data" (especially data which might be needed by intermediaries etc) goes into SDP. 

Now, there ARE some gray areas, where it can be discussed whether specific data is "CLUE app" or "transport". BUT, I would be concerned about CLUE putting data in the CLUE channel as a workaround, simply because it doesn't "fit" into SDP - even if the data as such would belong SDP.

Regards,

Christer