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

[Paul Kyzivat <[e-mail]>]

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