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

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 21 Oct 2014 20:58:32 +0200

Hi all,

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?

Best regards
Sergio

---

From: Colin Perkins <[email-masked]>
Date: Mon, 27 Oct 2014 16:36:26 +0000

Hi,

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:
> 
>     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.

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

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 27 Oct 2014 17:40:38 +0100

On 27/10/2014 17:36, Colin Perkins wrote:
> Hi,
>
> On 21 Oct 2014, at 19:58, Sergio Garcia Murillo 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>> That would include both modes, session and ssrc multiplexing. Given 
>> the extensive usage of bundle and current implementations, session 
> 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.

Best regards
Sergio

---

From: Colin Perkins <[email-masked]>
Date: Mon, 27 Oct 2014 16:45:01 +0000

On 27 Oct 2014, at 16:40, Sergio Garcia Murillo <[email-masked]> wrote:
> 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.

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

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 27 Oct 2014 17:51:41 +0100

On 27/10/2014 17:45, Colin Perkins wrote:
> On 27 Oct 2014, at 16:40, Sergio Garcia Murillo 
>>> 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

---

From: Colin Perkins <[email-masked]>
Date: Mon, 27 Oct 2014 17:10:45 +0000

On 27 Oct 2014, at 16:51, Sergio Garcia Murillo <[email-masked]> wrote:
> 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. 

> 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). 

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

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 27 Oct 2014 18:17:31 +0100

On 27/10/2014 18:10, Colin Perkins wrote:
> On 27 Oct 2014, at 16:51, Sergio Garcia Murillo 
>>>>>> 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:
>>>>>>
>>>>>> 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.
>>>>>>
>>>>> signalling needed for session-multiplexing of retransmission 
>>>>> packet anyway, so disallowing it buys you nothing.
>>>>
>> 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?

>
>> 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

---

From: Colin Perkins <[email-masked]>
Date: Mon, 27 Oct 2014 19:16:38 +0000

On 27 Oct 2014, at 17:17, Sergio Garcia Murillo <[email-masked]> wrote:
> 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).

Colin

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

---

From: Justin Uberti <[email-masked]>
Date: Mon, 27 Oct 2014 17:18:07 -0700

On Mon, Oct 27, 2014 at 12:16 PM, Colin Perkins <[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:
>
> extensive usage of bundle and current implementations, session multiplexing
> support doesn't make much sense.
>
>  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.
>
>
> 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.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 27 Oct 2014 20:41:12 -0700

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:

>> supports both BUNDLE and NON-BUNDLE. So, why require support for session
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 28 Oct 2014 10:10:14 +0100

On 28/10/2014 4:41, Bernard Aboba 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.
>

+1
Sergio