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

From: Colin Perkins <[email-masked]>
Date: Mon, 3 Nov 2014 15:25:05 +0000

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 <[email-masked]> 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 <[email-masked]> wrote:
> 
> 
> On Mon, Oct 27, 2014 at 12:16 PM, Colin Perkins <[email-masked]> wrote:
> On 27 Oct 2014, at 17:17, Sergio Garcia Murillo <[email-masked]> wrote:
>> On 27/10/2014 18:10, Colin Perkins wrote:
>>> On 27 Oct 2014, at 16:51, Sergio Garcia Murillo <[email-masked]> wrote:
>>>> On 27/10/2014 17:45, Colin Perkins wrote:
>>>>> On 27 Oct 2014, at 16:40, Sergio Garcia Murillo <[email-masked]> wrote:
>>>>>> On 27/10/2014 17:36, Colin Perkins wrote:
>>>>>>> On 21 Oct 2014, at 19:58, Sergio Garcia Murillo <[email-masked]> 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].
>>>>>>>> 
>>>>>>>> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 

-- 
Colin Perkins
https://csperkins.org/

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 03 Nov 2014 16:35:03 +0100

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:
>
> On 28 Oct 2014, at 03:41, Bernard Aboba <[email-masked] 
> <mailto:[email-masked]>> wrote:
>> Justin said:
>>
>> [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 <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>>
>>     On Mon, Oct 27, 2014 at 12:16 PM, Colin Perkins
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         On 27 Oct 2014, at 17:17, Sergio Garcia Murillo
>>         <[email-masked]
>>         <mailto:[email-masked]>> wrote:
>>>>         On 27 Oct 2014, at 16:51, Sergio Garcia Murillo
>>>>         <[email-masked]
>>>>         <mailto:[email-masked]>> wrote:
>>>>>>         On 27 Oct 2014, at 16:40, Sergio Garcia Murillo
>>>>>>         <[email-masked]
>>>>>>         <mailto:[email-masked]>> wrote:
>>>>>>>>         On 21 Oct 2014, at 19:58, Sergio Garcia Murillo
>>>>>>>>         <[email-masked]
>>>>>>>>         <mailto:[email-masked]>> 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:
>>>>>>>>>
>>>>>>>>>              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.
>>>>
>>>         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.
>>
>>     [email-masked] <mailto:[email-masked]>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 3 Nov 2014 10:08:44 -0800

Fine with me too.

> On Nov 3, 2014, at 7:35 AM, Sergio Garcia Murillo <[email-masked]> wrote:
>

---

From: Colin Perkins <[email-masked]>
Date: Mon, 3 Nov 2014 19:01:14 +0000

Okay, I’ll submit an update with this change once submissions reopen.
Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Mon, 10 Nov 2014 14:55:15 +0000

I just submitted draft-ietf-rtcweb-rtp-usage-20, that makes this change.

Colin

On 3 Nov 2014, at 19:15, Varun Singh <[email-masked]> wrote:
> +1 as well.
> 
> On 3 Nov 2014 07:25, "Colin Perkins" <[email-masked]> wrote:

-- 
Colin Perkins
https://csperkins.org/