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

Justin said:

"I don't think the WG ever explicitly signed up for session-multiplexing of
RTX data"

[BA] I agree, and in addition would say the same thing with respect to FEC
- one of the fundamental objections to RFC 5109 is that it only support
session-multiplexing, not SSRC multiplexing.

On Mon, Oct 27, 2014 at 5:18 PM, Justin Uberti <juberti@google.com> wrote:

>
>
> On Mon, Oct 27, 2014 at 12:16 PM, Colin Perkins <csp@csperkins.org> wrote:
>
>> On 27 Oct 2014, at 17:17, Sergio Garcia Murillo <
>> sergio.garcia.murillo@gmail.com> wrote:
>>
>>  On 27/10/2014 18:10, Colin Perkins wrote:
>>
>> On 27 Oct 2014, at 16:51, Sergio Garcia Murillo <
>> sergio.garcia.murillo@gmail.com> wrote:
>>
>>  On 27/10/2014 17:45, Colin Perkins wrote:
>>
>> On 27 Oct 2014, at 16:40, Sergio Garcia Murillo <
>> sergio.garcia.murillo@gmail.com> wrote:
>>
>>  On 27/10/2014 17:36, Colin Perkins wrote:
>>
>>  On 21 Oct 2014, at 19:58, Sergio Garcia Murillo <
>> sergio.garcia.murillo@gmail.com> 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.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>