[MMUSIC] Some comments on draft-ivov-mmusic-multiple-sources

[Bernard Aboba <[e-mail]>]

Overall, I like this draft quite a bit.  Some thoughts: 

Section 1
   Yet, Offer/Answer implementations in SIP
   applications have most often used them as an envelope for a maximum
   of two RTP streams (SSRCs) at a time: one in each direction.  The
   most common reason for this has been the fact these applications
   could not meaningfully render multiple SSRCs simultaneously.

[BA] While the above is probably true of legacy O/A implementations, video 
implementations today frequently can and do render multiple SSRCs simultaneously.  
In particular, implementations supporting more than "point-to-point" calls, often
go beyond "video switching" to rendering of multiple streams, all declared on
the same m-line. 

In particular, where there are multiple layers as well as multiple sources going
into a mixer, you may see multiple SSRCs coming out of the mixer.  This
could happen because a single SSRC is used for all the layers from a given source
(but distinct SSRCs are used for different sources), or because you have each
layer from a given source using a distinct SSRC. 

Section 2

   In cases where endpoints need to be able to detect this from the SDP
   Offer/Answer they could use the "max-send-ssrc" and "max-recv-ssrc"
   attributes defined in [MAX-SSRC].  It has to be noted however that
   this mechanism is still a work in progress and as such it would still
   need to be extended to provide ways of distinguishing between
   independent flows and complementary ones such as layered FEC and RTX.

[BA] Keep in mind that if you don't use a single SSRC per source, then the semantics
of max-send-ssrc and max-recv-ssrc become ambiguous.  So you need to be able to 
express the maximum send and receive sources as well as the maximum sent and
received layers. 

Section 5

   Another approach could be a combination of RTCP and RTP header
   extensions [RFC5285] in a way similar to the one employed by the
   Rapid Synchronisation of RTP Flows [RFC6051].  While such a mechanism
   is not currently defined by the IETF, specifying it could be
   relatively straightforward:

[BA] Not sure about the "straightforward" part but there are advantages to using
RTP and RTCP extensions.  RTP extensions allow RTP parsing to be bypassed which
is convenient if SRTP is used (since otherwise unless SSRCs are pre-declared
you might have to decrypt and parse the RTP packet to figure out what layer
it corresponds to).  Today there are commonly used RTP configurations that can't
easily be expressed in SDP (e.g. sending individual codec layers with distinct
SSRCs, but within the same RTP session) but that an RTP extension could help
with.  The argument on the other side is that SDP O/A is reliable, whereas
an RTP extension or RTCP SDES would not be.  However, if the endgame is WebRTC
without SDP, then I think we need to look for RTP/RTCP solutions for these issues,
rather than requiring an SDP dependency.