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

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

On 27/10/2014 18:10, Colin Perkins wrote:
> On 27 Oct 2014, at 16:51, Sergio Garcia Murillo 
> <[e-mail] 
> <mailto:[e-mail]>> wrote:
>> 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.
>
> 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?

>
>> 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.
>
> I’m perhaps missing something, but it seems that the features needed 
> for session-multiplexed retransmission are required anyway (a=group, 
> plus the ability to send non-BUNDLE media).
>

In current ORTC API, the RTX parameters are configured on the 
RTPReceiver/Sender object used for the media.

Best regards
Sergio