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

[Sergio Garcia Murillo <[e-mail]>]

On 27/10/2014 17:45, Colin Perkins wrote:
> On 27 Oct 2014, at 16:40, Sergio Garcia Murillo 
> <[e-mail] 
> <mailto:[e-mail]>> wrote:
>> On 27/10/2014 17:36, Colin Perkins wrote:
>>> On 21 Oct 2014, at 19:58, Sergio Garcia Murillo 
>>> <[e-mail] 
>>> <mailto:[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.

Also, the original discussion came from the ORTC list, as ORTC API only 
supports ssrc-multiplexing RTX. If we require both modes on WebRTC "just 
for fun", then ORTC API will not be able to comply with the RTP usage draft.

Best regards
Sergio