Re: [MMUSIC] Thoughts on m= lines and media streams

[Justin Uberti <[e-mail]>]

The prior commenters captured some of my concerns already, but here's a
quick summary of issues I noticed while reading over this draft:

1) "1a" and "2", as described, have fatal problems if the receiver rejects
the m= line that contains all the attributes (e.g. a=ice-ufrag, a=crypto,
etc)

2) In "1b", it's not clear what the purpose of the "a=group:MMT foo bar
zoe" line is.

3) Proposal "2" does not include the needed a=ssrc lines for demultiplexing
the received streams. IOW, proposal 2 requires RFC 5576 just like 1a and 1b.

4) The codec selection argument in Section 2.3.1 feels like a "Red Herring"
to me. Practically speaking, I think there are few, if any, real-world
settings where one might want to use a codec prioritization mechanism to
ask for a low-bitrate codec for stream A and a high-bitrate codec for
stream B (where the codecs used are different). A more realistic example
would be where one might want a lower bitrate  for a specific multi-rate
codec (e.g. Opus) to be used for stream A, and higher bitrate for stream B.
This of course can be handled with the per-ssrc fmtp attributes that are
specified in RFC 5576. However, I think in almost all cases, the receiver
is in a much worse position to make these decisions that the sender; the
sender, aware of the estimated bandwidth to the receiver, and the relative
value/complexity of its streams, can make more informed decisions about
bandwidth allocation, and perform them without any signaling delay.

5) The directional attribute discussion in Section 4 omits one important
consequence of the fact that a=ssrc indications are unidirectional, namely
that streams could be added or removed by both endpoints simultaneously
without causing a glare condition. m= lines, on the other hand, since they
are identified by their index, do not have this property; if both sides
decide to add a m= line at the same time, bad things happen.

6) The legacy interop argument in Section 4 feels a bit hand-wavy. Aside
from the one case of having video + presentation streams, I have not yet
heard of widely deployed equipment that uses multiple audio or video m=
lines, and certainly any such equipment will not understand BUNDLE or MMT.
Therefore a gateway is required, and any gateway that was performing BUNDLE
or MMT could certainly do the minor additional work to package the SDP as 1
m= line (remember, it already needs to add the a=ssrc attributes). Ergo, I
don't agree that the general case of N m= lines needs to be handled by all
RTCWEB implementations.

In summary, I see option "2" as a "1b" variant that comes with a more
verbose and redundant syntax, several shortcomings (#1 and #5 above), and
questionable upside.

-j-




On Thu, Jan 31, 2013 at 11:48 PM, Stach, Thomas <
[e-mail]> wrote:

>
> Adam,
>
> thanks for analysing the various proposals and putting the draft together.
> From a quick read I have some issues with backward compatibility of your
> proposal to include
> "common" attributes only in the first m-section.
> Assuming that the examples in the draft are offers, an answerer that
> didn't implement any of the mechanisms would probably show the
> following behavior.
>
> Alternativ 1a and 2 have ICE candidates only for the first m-section.
> An answerer that doesn't understand the grouping semantics could -
> dependent on the network topology - end up having audio, but no video
> connectivity.
> With having other attributes only in the first m-section we could get
> other issues.
>
>
> Alternative 1b doesn't have this problem, but the offer would most likely
> be rejected resulting in no media at all.
> I preferred the original mmt proposal as it had additional m-sections,
> that could be accepted by a legacy answerer without the need for a GW that
> performs complex SDP operations.
>
>
> Regards
> Thomas
>
>
> Adam Roach wrote:
> > Based on the conversations we've had so far, I've put together the
> > following summary of my thoughts on the topic of whether we
> > want to put
> > multiple media streams in a single m= line.
> >
> > http://www.ietf.org/id/draft-roach-mmusic-mlines-00.txt
> >
> > Sorry for the relatively short lead time before next week's
> > meeting -- I
> > had meant to put this kind of summary together a week or two ago, but
> > have been far busier than I anticipated.
> >
> > /a
> > _______________________________________________
> > mmusic mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>