Re: [rtcweb] A problem with both A and B

[Stefan Håkansson LK <[e-mail]>]

I think this was a good summary.

But regarding "a mechanism for describing the role and intent of each 
RTP stream in the RTP session.", do we really need that? Isn't the 
combination of ssrc and the msid draft sufficient?

Together the clearly identify how ssrc's map into PC-streams and 
PC-tracks, and the application can convey the remaining info (e.g. 
PC-stream xx represents the speaker audio+video, yy the room video etc.) 
needed in any way it likes .

Stefan

On 2013-05-21 22:13, Paul Kyzivat wrote:
> On 5/21/13 3:20 AM, Christer Holmberg wrote:
>> Hi,
>>
>>>> I don't think it's a BUNDLE issue whether adding/removing of streams
>>>> require an O/A exchange or not. It's an SDP, and SDP O/A, issue.
>>>>
>>>> BUNDLE is about sharing a 5-tuple.
>>>
>>> I don't agree.
>>>
>>> RTP is already able to support multiple RTP streams sharing an RTP
>>> session (and 5-tuple).
>>>
>>> What BUNDLE is about is describing that in SDP.
>>> And that includes how SDP O/A works.
>>
>> Multiple RTP streams can already share an RTP session today, using
>> multiple SSRCs per m- line :)
>>
>> If adding a new stream means adding a new m- line, then an SDP O/A is
>> obviously needed - bundle or no bundle.
>>
>> If adding a new stream means adding a new SSRC, within an existing m-,
>> then it is also an SDP O/A issue - bundle or no bundle.
>
> AFAIK there is wide agreement that an RTP *session* can carry multiple
> RTP streams.
>
> An SDP O/A exchange negotiating an RTP m-line pair establishes an RTP
> session. There is disagreement whether it is permissible for the
> resulting RTP session to carry multiple RTP streams. The specs are
> ambiguous on this point. Clearly there are well identified cases where
> they do, and we aren't likely to rule those incorrect. Its also clear
> that some of these cases start out sending a single SSRC, and then later
> "add" another. (It may actually be a substitution.)
>
> So it seems clear to me that you may add an RTP stream to an RTP session
> described by an m-line without doing another O/A exchange.
>
> What is lacking in such cases is a mechanism for describing the role and
> intent of each RTP stream in the RTP session. In some cases it is
> possible to get by without this, by assuming that the two ends have
> consistent *assumptions* about how to infer the role/intent. But there
> are many cases where this isn't enough.
>
> Extra SDP syntax has been defined in an ad hoc way to get at bits and
> pieces of this problem. E.g., the a=ssrc attribute. What has already
> been defined doesn't seem suficient for all the new cases we are no
> discussing.
>
> BUNDLE is *another* proposal for addressing part or all of this problem.
> But BUNDLE brings along another problem: for BUNDLE to be useful, it
> must be possible to associate each RTP packet with one of the bundled
> m-lines. Without BUNDLE we don't have that problem.
>
> To summarize:
>
> - without bundle, we need a mechanism for describing the role/intent
>    of each RTP stream in the RTP session. *If* we choose to describe
>    that with SDP, then we need an O/A exchange each time we add
>    an RTP stream.
>
> - with BUNDLE and Plan A, the assumption is that each m-line in the
>    bundle describes a single RTP stream, and so the other SDP stuff
>    in that media section can be used to describe the role/intent of
>    that RTP stream. By design this requires a new m-line for each
>    RTP stream, so adding one requires an O/A. We then assume that there
>    is enough stuff in each media section to decide which m-line each
>    packet should be associated with.
>
> - with BUNDLE and Plan B, there may be multiple RTP streams per
>    m-line. As in Plan A we need to associate each packet with one of
>    the m-lines. Like the no-bundle case we still need some mechanism
>    to describe the role/intent if the individual RTP streams.
>    In some cases (e.g., a=ssrc) the same info that classifies to
>    an m-line may also specify the role of each stream. That case
>    also leads to an O/A for each stream add.
>
>    If you have a non-SDP way to discover the role/intent of each
>    RTP stream, and you use a way of classifying to one of the
>    bundled m-lines *without* enumerating every RTP stream, then
>    you can perhaps avoid an O/A for each stream add. E.g., if you
>    just bundle one audio and one video m-line, and use PT to
>    distinguish those.
>
> Note: in above I said Plan A uses an m-line for each RTP stream. That
> isn't always the case. There are some cases (at least in clue) where
> each m-line is intended to describe a "flow" (clue capture) that may
> correspond to different RTP streams over time, or that might include
> supporting FEC streams, etc. Depending on your assumptions about this
> case it may start to take on some of the characteristics of Plan B.
>
>      Thanks,
>      Paul
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb