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

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

Fine for me, thanxs Colin

BR
Sergio
On 03/11/2014 16:25, Colin Perkins wrote:
> I would have thought the compatibility arguments offered to support 
> non-BUNDLE media applied here too, but okay. If I change the last 
> paragraph of rtp-usage, section 6.1 to:
>
>    Receivers are REQUIRED to implement support for RTP retransmission
>    packets [RFC4588] sent using SSRC multiplexing, and MAY also support
>    RTP retransmission packets sent using session multiplexing.  Senders
>    MAY send RTP retransmission packets in response to NACKs if support
>    for the RTP retransmission payload format has been negotiated, and if
>    the sender believes it is useful to send a retransmission of the
>    packet(s) referenced in the NACK. Senders do not need to retransmit
>    every NACKed packet.
>
> is this acceptable?
>
> Colin
>
>
>
>
> On 28 Oct 2014, at 03:41, Bernard Aboba <[e-mail] 
> <mailto:[e-mail]>> wrote:
>> 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 <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>
>>
>>     On Mon, Oct 27, 2014 at 12:16 PM, Colin Perkins
>>     <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>         On 27 Oct 2014, at 17:17, Sergio Garcia Murillo
>>         <[e-mail]
>>         <mailto:[e-mail]>> wrote:
>>>         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?
>>
>>         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
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>
>
>
> -- 
> Colin Perkins
> https://csperkins.org/
>
>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb