Subject: [rtcweb] Bundling vs sending multiple RTP streams per m=line

From: Roman Shpount <[email-masked]>
Date: Thu, 19 Jan 2012 13:08:37 -0500

Switching to a new topic.

On Thu, Jan 19, 2012 at 12:43 PM, Harald Alvestrand <[email-masked]>wrote:

> **
> See draft-westerlund-avtcore-max-ssrc-00 for one discussion of this.
>
> FWIW, Google Hangouts works just fine with a large number of SSRCs per RTP
> session.
>

Just to clarify -- for interop this would be disabled and the system would
fall back to using an m-line per each stream, correct?

What are the benefits of doing this vs bundle?
_____________
Roman Shpount

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 19 Jan 2012 19:13:45 +0100

On 01/19/2012 07:08 PM, Roman Shpount wrote:
> On Thu, Jan 19, 2012 at 12:43 PM, Harald Alvestrand 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     FWIW, Google Hangouts works just fine with a large number of SSRCs
>     per RTP session.
>
>
> Just to clarify -- for interop this would be disabled and the system 
> would fall back to using an m-line per each stream, correct?
So far, the only interop we've been doing from hangouts is with phone 
gateways, and that link uses intermediate servers. 
(https://plus.google.com/u/0/104364547339874244431/posts/gKKyJjTpzj8 for 
the details).
> What are the benefits of doing this vs bundle?
We're planning on doing bundle too, in order to reduce our connections 
from 2 to 1 RTP session per client, but bundle did not exist until 
recently; the hangouts work started a long time ago.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 19 Jan 2012 13:23:08 -0500

> recently; the hangouts work started a long time ago.

So, why won't we just do bundling? This allows for more functionality
(different payload types per SSRC, ability to accept/reject each individual
SSRC, directional attributes) and still allows to reduce number of ICE
setups. Unless there is a strong requirement or benefit of doing just
multiple SSRC without any signaling announcements, bundling just seems a
better solution.
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Thu, 19 Jan 2012 13:55:06 -0500

I think there is value in being able to separate the concept of a source
from a session. For instance, you may want to set the bandwidth for an
overall session, but allow flexibility in how that is distributed between
sources.

RFC 5576 provides the signaling information necessary to perform SSRC
multiplexing; while BUNDLE provides other benefits, we don't need to use it
in this case.

On Thu, Jan 19, 2012 at 1:23 PM, Roman Shpount <[email-masked]> wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 19 Jan 2012 14:05:42 -0500

> multiplexing; while BUNDLE provides other benefits, we don't need to use it
The whole reason  this came about is that in case of bundling we can put
individual participants on hold. In case of SSRC multiplexing, we need to
define something new.

In general, I am cautious of SSRC multiplexing since it does not require a
new signaling interaction when new source is added to removed. An end point
declares that it can take up-to 5 sources and it should take any 5 sources
that are sent to it. No individual direction control, very rough payload
and allowed resolution control. This seems to be completely un-interopable
with anything which does not explicitly supports this. With bundling you
can map each SSRC to an individual remote ip/port on the SBC and still
conduct signaling exchange as normal. SSRC multiplexing does not seem to
map to legacy signaling exchange at all and would need to be disabled to
work with it.

_____________
Roman Shpount

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 19 Jan 2012 15:38:49 -0800

Roman said:

SSRC multiplexing does not seem to map to legacy signaling exchange at all
and would need to be disabled to work with it.

[BA] To date implementations have tended to assume that an MCU is used.
However, for small conferences peer-to-peer interaction is feasible and
advantageous.  So while I'm not a fan of multiplexing audio/video on the
same address/port (it degrades the security assurances provided by ICE),
SSRC multiplexing has significant benefits in small conference scenarios.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 19 Jan 2012 19:29:12 -0500

On Thu, Jan 19, 2012 at 6:38 PM, Bernard Aboba <[email-masked]>wrote:

> *Roman said:*
> * *
> and would need to be disabled to work with it.****
>
> ** **
>
> SSRC multiplexing has significant benefits in small conference scenarios.*
> ***
>
What I am arguing is not MCU vs SSRC multiplexing. I am arguing bundling vs
SSRC multiplexing. We can still do peer-to-peer conferencing and use the
same IP and port to communicate with each party as long as each peer gets
its own signaling exchange. Otherwise there is no way to put each party on
hold or to negotiate payloads and codecs independently for each party.
_____________
Roman Shpount

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 20 Jan 2012 14:00:05 +0100

Hi,

As individual:

Roman, I think you are conflating two aspects in this discussion.

The first one is if one uses one or more RTP sessions. The second is the
number of SSRC a given end-point is capable or willing to send or
receive within the context of a give RTP session.

The Bundle proposal is part SDP signaling and secondly the method for
how multiple media lines in SDP is related to RTP sessions. There is two
proposals on the table.

1. Use multiple media types and thus SDP media lines (due to SDP
restriction) in a single RTP session sent over a single lower layer
transport session (5-tuple).

2. Enable multiple RTP sessions to be identified and handled when using
them over a single lower layer transport session. This requires an
additional multiplexing layer on top of UDP.

Independently of which choice of the above one selects, within a given
RTP session one can have multiple RTP streams, i.e. multiple SSRCs. Yes,
choice 1 forces each end-point to have multiple SSRC in that single RTP
session if both an audio and a video session is to be supported. Choice
2 could avoid this by having multiple RTP sessions. However, I
personally don't want to use that as an argument as there are other
reasons why multiple RTP streams (SSRCs) are reaosonable within a given
RTP session.

The main reasons I have seen so far that is valid in WebRTC context are:
1. End-point has multiple media sources, i.e. several cameras
2. Participating in conferences based on central node receiving each
individual sender and distributing the necessary to the receivers.

Yes, if one take it to the extreme, in both cases each stream could be
mapped to an individual RTP session. However, it appears easier to use
the RTP sessions to gather related stream and deal with multiple SSRCs
in each session, which RTP was designed to handle.

Cheers

Magnus

On 2012-01-20 01:29, Roman Shpount wrote:
> 
> On Thu, Jan 19, 2012 at 6:38 PM, Bernard Aboba
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     *Roman said:____*
> 
>     *__ __*
> 
>     SSRC multiplexing does not seem to map to legacy signaling exchange
>     at all and would need to be disabled to work with it.____
> 
>     __ __
> 
>     [BA] To date implementations have tended to assume that an MCU is
>     used.  However, for small conferences peer-to-peer interaction is
>     feasible and advantageous.  So while I'm not a fan of multiplexing
>     audio/video on the same address/port (it degrades the security
>     assurances provided by ICE), SSRC multiplexing has significant
>     benefits in small conference scenarios.____
> 
> What I am arguing is not MCU vs SSRC multiplexing. I am arguing bundling
> vs SSRC multiplexing. We can still do peer-to-peer conferencing and use
> the same IP and port to communicate with each party as long as each peer
> gets its own signaling exchange. Otherwise there is no way to put each
> party on hold or to negotiate payloads and codecs independently for each
> party.
> _____________
> Roman Shpount

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Roman Shpount <[email-masked]>
Date: Fri, 20 Jan 2012 13:59:13 -0500

I understand the purpose of using multiple SSRC within the single RTP
sessions. My issue with it that without the corresponding media line in
SDP, there is no way to changing signaling parameters per SSRC. For
instance I am receiving video from 3 cameras from the remote party. With
such a setup I cannot signal remote party that I no longer want to receive
video from camera number 2. And there are a lot of different things that
cannot be done since there is no signaling mechanism associated with each
individual source. Individual sources cannot be paused or resumed by the
receiver, there is no way to signal that other encoding options are
desired.

Furthermore, all the proposals that allow multiplexing of several SSRC in
RTP state that signaling is optional when new sources are added or removed.
This creates some interesting problems when mapping appearance of a new
source to the application logic or to UI. Having a signaling exchange with
an option to refuse additional source would allow for better applications.

What I was thinking is that using a separate m= line for each source and
using bundling to reduce the number of RTP ports and ICE setups is a better
solution for the same problem. It does not change what's going to happen on
the RTP side, it would just map it better to signaling (media description).
_____________
Roman Shpount

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 21 Jan 2012 21:28:45 +0100

On 01/20/2012 07:59 PM, Roman Shpount wrote:
> sessions. My issue with it that without the corresponding media line 
> in SDP, there is no way to changing signaling parameters per SSRC. For 
> instance I am receiving video from 3 cameras from the remote party. 
> With such a setup I cannot signal remote party that I no longer want 
> to receive video from camera number 2. And there are a lot of 
> different things that cannot be done since there is no signaling 
> mechanism associated with each individual source. Individual sources 
> cannot be paused or resumed by the receiver, there is no way to signal 
> that other encoding options are desired.
>
> Furthermore, all the proposals that allow multiplexing of several SSRC 
> in RTP state that signaling is optional when new sources are added or 
> removed.
To be precise: draft-alvestrand-rtcweb-msid suggests that if any sources 
(SSRCs) are mentioned explicitly in the SDP, all should be.

I would really appreciate some commentary on that proposal.
> This creates some interesting problems when mapping appearance of a 
> new source to the application logic or to UI. Having a signaling 
> exchange with an option to refuse additional source would allow for 
> better applications.
>
> What I was thinking is that using a separate m= line for each source 
> and using bundling to reduce the number of RTP ports and ICE setups is 
> a better solution for the same problem. It does not change what's 
> going to happen on the RTP side, it would just map it better to 
> signaling (media description).
> _____________
> Roman Shpount
>
>
> On Fri, Jan 20, 2012 at 8:00 AM, Magnus Westerlund 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     As individual:
>
>     On 2012-01-20 01 <tel:2012-01-20%2001>:29, Roman Shpount wrote:
>     >
>     > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     >
>     >     *Roman said:____*
>     >
>     >     *__ __*
>     >
>     <tel:%2B46%2010%207148287>
>     <tel:%2B46%2073%200949079>
>     SE-164 80 Stockholm, Sweden| mailto:
>     [email-masked] <mailto:[email-masked]>