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

[Emil Ivov <[e-mail]>]

Hey Bernard,

On 19.07.13, 04:28, Bernard Aboba wrote:
> 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.

I agree that this is where things seem to be headed. The text was mostly 
referring to "legacy" SIP devices. Most of which are probably unable to 
handle video at all. Many of the SIP hardphones that do handle video 
simply don't have the user interface that would allow showing a second 
flow. From what I've seen such devices often simply ignore the SSRC 
field which leads to weird results with multiple video flows.

> 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  <http://tools.ietf.org/html/draft-ivov-mmusic-multiple-sources-00#ref-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.

Completely agreed. That's what the text above is actually trying to say. 
MAX-SSRC may need further syntax/semantics or at least text that would 
properly address the difference between multiple independent streams 
(e.g. a video conf call) from multiple related streams (e.g. layers or 
FEC ).

> Section 5
>
>     Another approach could be a combination of RTCP and RTP header
>     extensions [RFC5285  <http://tools.ietf.org/html/rfc5285>] in a way similar to the one employed by the
>     Rapid Synchronisation of RTP Flows [RFC6051  <http://tools.ietf.org/html/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.

Agreed.

Emil

-- 
https://jitsi.org