Subject: [rtcweb] JSEP: simulcast reception not supported?

From: Bernard Aboba <[email-masked]>
Date: Thu, 16 Jun 2016 08:44:46 -0400

JSEP Section 5.2.1 talks about the initial offer and simulcasting in an
RtpSender. However Section 5.3.1 (Initial Answers) does not describe
simulcast in an RtpReceiver.  Also, Section 5.9 (Applying an  Answer) only
talks about sending of simulcast streams, not receiving.

Are we to conclude that JSEP only supports sending of simulcast, but that
an  RtpReceiver should only expect to receive a single RTP stream?

---

From: Emil Ivov <[email-masked]>
Date: Thu, 16 Jun 2016 06:04:24 -0700

Are there specs that would actually allow JSEP to operate with
simulcast in reception? Do we have anything that says how SSRCs should
be sort-of ignored in the presence of an incoming RID and tells us
what to do with sequence numbers in such scenarios?

On Thu, Jun 16, 2016 at 5:44 AM, Bernard Aboba <[email-masked]> wrote:
> Are we to conclude that JSEP only supports sending of simulcast, but that an
> RtpReceiver should only expect to receive a single RTP stream?
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

-- 
https://jitsi.org

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 16 Jun 2016 12:39:10 -0700

> an  RtpReceiver should only expect to receive a single RTP stream?
​Yes.  The working group(s) decided that receiving simulcast was out of
scope for WebRTC 1.0.​

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 16 Jun 2016 12:41:45 -0700

ORTC allows it, so perhaps WebRTC NV will, but through direct method calls,
which has nothing to do with JSEP.

---

From: Miguel París Díaz <[email-masked]>
Date: Sun, 19 Jun 2016 20:42:07 +0200

Hello everybody,
from my point of view if the spec talks about sending simulcast, it should
talk about receiving simulcast.

Probably, for browsers it makes no sense in most of use cases, but the API
could be implemented (for example) by Media Servers, and here having the
notion of receiving simulcast is quite useful for developers.

Best regards!!

2016-06-16 21:41 GMT+02:00 Peter Thatcher <[email-masked]>:

> ORTC allows it, so perhaps WebRTC NV will, but through direct method
> calls, which has nothing to do with JSEP.
>
>

-- 
Miguel París Díaz
------------------------------------------------------------------------
Computer/Software engineer.
Researcher and architect in http://www.kurento.org
http://twitter.com/mparisdiaz
------------------------------------------------------------------------

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 20 Jun 2016 22:19:22 +0200

> notion of receiving simulcast is quite useful for developers.

A WebRTC server must just choose a single encoding (up to the server
logic), signal it to the receiver and just route such an encoding to
the receiver.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Luis López Fernández <[email-masked]>
Date: Tue, 21 Jun 2016 09:46:20 +0200

> El 20 jun 2016, a las 22:19, Iñaki Baz Castillo <[email-masked]> escribió:
> 

You are assuming that the WebRTC server can only mediate between two clients. But a WebRTC server can also be mediating between a client and another WebRTC server when I need very large scalability. For example, if I want to create very large distribution trees (broadcasting) using WebRTC, I need servers to communicate to other servers so that such servers exchange all the simulcast encodings. Only the end servers (i.e. the servers on the leaves of the tree that are serving to the final clients) can route to the client the appropriate encoding adapted to the client available bandwidth.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 21 Jun 2016 09:52:56 +0200

> You are assuming that the WebRTC server can only mediate between two clients.

Not at all. What I say above also applies to SFUs.

>But a WebRTC server can also be mediating between a client and another WebRTC server when I need very large scalability. For example, if I want to create very large distribution trees (broadcasting) using WebRTC, I need servers to communicate to other servers so that such servers exchange all the simulcast encodings. Only the end servers (i.e. the servers on the leaves of the tree that are serving to the final clients) can route to the client the appropriate encoding adapted to the client available bandwidth.

Easy: let the first server route all the encodings to the end-server,
and let the end-server decide which want to route to the receiver
peer.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Luis López Fernández <[email-masked]>
Date: Tue, 21 Jun 2016 10:01:38 +0200

> and let the end-server decide which want to route to the receiver

Yes, and this supports that it might make sense on the spec to talk about receiving simulcast, and not only sending simulcast (as the original mail on this thread was asking for), as it makes sense (as you recognize) to receive simulcast on some server-side scenarios.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 21 Jun 2016 10:05:09 +0200

2016-06-21 10:01 GMT+02:00 Luis López Fernández <[email-masked]>:
> Yes, and this supports that it might make sense on the spec to talk about
> receiving simulcast, and not only sending simulcast (as the original mail on
> this thread was asking for), as it makes sense (as you recognize) to receive
> simulcast on some server-side scenarios.

I agree that a spec describing that would be useful. However, JSEP is
about WebRTC endpoints implementing the spec API:

> This document describes the mechanisms for allowing a Javascript
   application to control the signaling plane of a multimedia session
   via the interface specified in the W3C RTCPeerConnection API, and
   discusses how this relates to existing signaling protocols.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Luis López Fernández <[email-masked]>
Date: Tue, 21 Jun 2016 10:29:06 +0200

> about WebRTC endpoints implementing the spec API:

Nothing avoids a WebRTC server to implement a WebRTC endpoint complying with spec API. In fact, at Kurento we have a full implementation of such endpoint with the complete API as it is specified. This is why we have discovered that receiving simulcast (which is a feature we need and others might need) is not covered by the spec and it might be covered (if there are no other reasons avoiding it) for completeness. It is true that the spec introduction assumes a browser-to-browser scenario, but IMO this is a somehow “artificial” restriction that could be avoided if there is the appropriate consensus. Perhaps, fragmenting too much the specs is not always the best option. This is basically the point of this thread and this is why we wanted to gather opinions on this topic.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 21 Jun 2016 10:40:36 +0200

2016-06-21 10:29 GMT+02:00 Luis López Fernández <[email-masked]>:
> Nothing avoids a WebRTC server to implement a WebRTC endpoint complying with
> spec API. In fact, at Kurento we have a full implementation of such endpoint
> with the complete API as it is specified. This is why we have discovered
> that receiving simulcast (which is a feature we need and others might need)
> is not covered by the spec and it might be covered (if there are no other
> reasons avoiding it) for completeness. It is true that the spec introduction
> assumes a browser-to-browser scenario, but IMO this is a somehow
> “artificial” restriction that could be avoided if there is the appropriate
> consensus. Perhaps, fragmenting too much the specs is not always the best
> option. This is basically the point of this thread and this is why we wanted
> to gather opinions on this topic.

Again, I agree with you. However, I think that receiving simulcast is
not present in the spec because it's hard to define it in concrete
terms. Basically a server may do whatever it wants and it's so hard to
document a concrete set of features.

It comes to my mind a similar scenario regarding SIP and B2BUA
servers. There is no one RFC defining what a B2BUA is or what it must
be, nor how it must behave.

Coming back to the original topic, the spec cannot easily define
receiving simulcast (in browsers) because it "breaks" the current API:
a RtpReceiver is supposed to have a single associated
MediaStreamTrack. However, if multiple encoding are received at the
same time, it's hard to figure out how to deal with that without
generating multiple MediaStreamTracks (which would break the spec).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Tue, 21 Jun 2016 10:57:43 +0000

On 16/06/16 14:45, Bernard Aboba wrote:
> simulcast in an RtpReceiver.  Also, Section 5.9 (Applying an  Answer)
> only talks about sending of simulcast streams, not receiving.
>
> Are we to conclude that JSEP only supports sending of simulcast, but
> that an  RtpReceiver should only expect to receive a single RTP stream?

FWIW,

simulcast was discussed a bit at TPAC last fall, and there it was 
proposed to leave simulcast reception out of scope for WebRTC 1.0 (and 
no one expressed a different opinion). See minutes [1] and slides [2] 
(simulcast reception was discussed last).

[1] https://www.w3.org/2015/10/28-webrtc-minutes#item07
[2] 
https://www.w3.org/2011/04/webrtc/wiki/images/e/e3/Simulcast_at_TPAC_2015.pdf

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 22 Jun 2016 18:45:26 +0000

> (simulcast reception was discussed last).

Yes that was the decision and if I remember correctly we talked very vaguely about simulcast reception being possibly something for WebRTC NV which I guess it could still be.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 22 Jun 2016 18:06:41 -0700

Stefan said:

"it was proposed to leave simulcast reception out of scope for WebRTC 1.0"

[BA] That is my recollection as well.  However, currently in the WebRTC 1.0
API spec in Section 5.1 addTransceiver() it says:

'When setRemoteDescription is called with a corresponding remote
description that is able to receive multiple RTP encodings as defined in
[JSEP], the RTCRtpSender may send multiple RTP encodings and the parameters
retrieved via the transceiver’s sender.getParameters() will reflect the
encodings negotiated.'

So there is an expectation that JSEP will describe "a corresponding remote
description that is able to receive multiple RTP encodings".  Currently,
that is not something one will find in JSEP, but rather
in draft-ietf-mmusic-rid, perhaps because such a remote description would
most likely be created by an SFU rather than a browser.

Is it possible to add such material to JSEP that can be referenced in
WebRTC 1.0 API without confusing the issue of whether a WebRTC 1.0 browser
would emit an Answer indicating the ability to receive multiple RTP
encodings?