Re: [rtcweb] Drop RFC 4588 RTX session multiplexing support requirement from RTP USAGE

[Justin Uberti <[e-mail]>]

On Mon, Oct 27, 2014 at 12:16 PM, Colin Perkins <[e-mail]> wrote:

> On 27 Oct 2014, at 17:17, Sergio Garcia Murillo <
> [e-mail]> wrote:
>
>  On 27/10/2014 18:10, Colin Perkins wrote:
>
> On 27 Oct 2014, at 16:51, Sergio Garcia Murillo <
> [e-mail]> wrote:
>
>  On 27/10/2014 17:45, Colin Perkins wrote:
>
> On 27 Oct 2014, at 16:40, Sergio Garcia Murillo <
> [e-mail]> wrote:
>
>  On 27/10/2014 17:36, Colin Perkins wrote:
>
>  On 21 Oct 2014, at 19:58, Sergio Garcia Murillo <
> [e-mail]> wrote:
>
> Not sure if it is done on pourpose, but according to the RTP usage draft,
> it may seem that full RFC 4588 is mandated at the recevier side:
>
>     Receivers are REQUIRED to implement support for RTP retransmission
>     packets [RFC4588 <https://tools.ietf.org/html/rfc4588>].
>
>
> That would include both modes, session and ssrc multiplexing. Given the
> extensive usage of bundle and current implementations, session multiplexing
> support doesn't make much sense.
>
> Should we drop it, and state that only ssrc-multiplexing shall be
> supported at the receiving end?
>
>
>  I don’t see any advantage to doing so, given that support for non-BUNDLE
> sessions is REQUIRED. You need to implement the signalling needed for
> session-multiplexing of retransmission packet anyway, so disallowing it
> buys you nothing.
>
>
> You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, what I
> don't see is how to do session multiplexing with BUNDLE sessions.
>
>
>  You can’t do session multiplexing for BUNDLE sessions; by definition
> they use SSRC multiplexing. You could do non-BUNDLE sessions, with
> retransmission sent on a separate RTP session though.
>
>   So, you are saying exactly the same than me. SSRC multiplexing supports
> both BUNDLE and NON-BUNDLE. So, why require support for session
> multiplexing at all? As a developer, I don't see why I would have to
> implement something that would be rarely used and provide no extra benefit.
>
>
>  Non-BUNDLE is session multiplexing. It uses a separate RTP session for
> the retransmissions.
>
> Maybe I am the missing something, if you don't use bundle to send the
> audio/video on same rtpsession, you can still send rtx+video on same
> session. That's it non-bundle with ssrc-multiplexing. Are we referring to
> different things?
>
>
> Sure, but that doesn’t alter the fact that the group decided that
> non-BUNDLE media needs to be supported. Sending retransmission on a
> separate RTP session is as needed for interoperability with legacy systems
> as sending audio and video on separate RTP sessions (and shouldn’t be hard
> to support, since it uses the same mechanisms).
>
> Non-BUNDLE media needs to be supported, but I don't think the WG ever
explicitly signed up for session-multiplexing of RTX data. Unified plan is
quite clear in its assertion that the primary, RTX, and FEC flows for a
given media stream should all be represented by a single m= line, e.g.
SSRC-multiplexed.