Re: [rtcweb] Plan A, respun

[Eric Rescorla <[e-mail]>]

On Thu, May 16, 2013 at 11:31 PM, Harald Alvestrand <[e-mail]>wrote:

>  On 05/17/2013 01:28 AM, Eric Rescorla wrote:
>
>
>
> On Thu, May 16, 2013 at 12:15 PM, Harald Alvestrand <[e-mail]>wrote:
>>
>>   If the true limit at which one has to change allocation strategy were
>>>> to become 96, not 32, it actually strengthens my "falling off a cliff"
>>>> argument
>>>>
>>>
>>> And, to be clear, it's not a cliff. For any given session (without
>>> a=ssrc:), you have to allocate ceiling(streams/96) ports. It's not like you
>>> go from using one port to using 97 ports when you add the 97th stream. You
>>> go from one port to two, which will handle 192 streams.
>>>
>>
>>  Going from one port to two ports is a cliff.
>> We may have differing opinions on how tall it is.
>
>
>  Harald,
>
>  I am not following how this is a discriminating factor between Plan A and
> Plan B.
>
>  In both Plan A and Plan B, any media stream which is intended to be
> independently processable by a legacy endpoint must appear on its
> own m-line. That means it must also have its own independent ports,
> even if you are hoping to eventually be able to mux it via BUNDLE.
>
>
> I agree with this characterization - the two proposals have the same
> number of ports in the initial offer.
>
> I quibble about the characterization "any media stream which is intended
> to be
> independently processable by a legacy endpoint must appear on its
> own m-line." As Bernard has said, the field of deployed applications is
> diverse enough to make this question confusing - both "independently
> processable" and "legacy endpoint" may need further qualification in order
> to make that statement unequivocally true.
>

Well, to the extent to which there are many legacy endpoints which assume
that
each renderable entity must be on its own m-line, then presumably you
need to follow this rule to ensure interop, no?

 In both Plan A and Plan B, it is possible to indicate additional media
> streams that are not processable by a legacy endpoint but that
> will be processable by a new endpoint:
>
>  - In Plan A, this is done by marking them bundle-only
> - In Plan B, this is done by having them be additional SSRCs on one
>   of the extant m-lines.
>
>
>
>  Regardless of Plan A versus Plan B, bundle contemplates having
> multiple media flows on the same media 5-tuple. Thus, it must
> be possible to demux the flows somehow. As I read Plan A,
> it proposes using both PT and SSRC to demux whereas plan B
> only wants to use SSRC? So, the implication is that a Plan A
> endpoint must:
>
>  1. Demux on both PT and SSRC (this is trivial, I think you will agree)
>
>
> The demuxing is trivial. In fact, I don't think it's even necessary to
> describe it as "demux on PT"; you can't allow SSRC collision between two
> tracks with different PT anyway.
>

This seems to me to be true only in the trivial sense.  I.e., demuxing is
not
just a matter of separation but also of assignment. So, as Cullen has
observed, if the two m-lines use distinct PTs, the offerer can properly
demux and display the streams even before receiving the answer.


>  2. When acting as offerer, either always offer SSRC or conditionally
> offer SSRC when the # of PTs is excessive.
>
>  I don't understand why you think that plan A means more ports than
> plan B. Presumably we can simply specify that bundle requires
> SSRC muxing, in which case plan A and plan B behave identically.
>
>  What am I missing?
>
>
> This particular issue is about what happens when you run out of payload
> types to multiplex on.
>
> In Plan A as I currently understand Adam, any application that needs less
> than 96 M-lines (Adam's number) can use a single port, and use the payload
> type to indicate the M-line.
>
> If there are 97 M-lines, if I've understood Adam correctly, one could use
> two ports and two bundles, with some subset of the M-lines being allocated
> to one bundle and another subset of the M-lines allocated to the other
> bundle.
>

Yes, one could. But one could also use one port, one bundle, and demux on
SSRC.


 In Plan B, there is no difference in the mechanism used to multiplex 96
> SSRCs from the mechanism used to multiplex 97 SSRCs, and it does not matter
> for the multiplexing how many M-lines they are distributed over.
>

I would say rather that plan B *only* allows SSRC multiplexing whereas plan
A allows you to use other forms of multiplexing beside SSRC, but only under
limited circumstances.

However, I'm not sure why this is a big issue. The requirement for distinct
PTs isn't new to plan A. In fact, it's in Section 7.2 of BUNDLE:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-03#section-7.2
This seems to me to be a question the working group needs to resolve
for BUNDLE and then it can just be inherited by either Plan A or Plan B.

-Ekr