Subject: Re: [MMUSIC] More thoughts on multiple media streams in a single m= line - requirements for "fumble"!!!

From: "Roni Even" <[email-masked]>
Date: Sat, 16 Feb 2013 14:03:43 +0200

Hi,
The second topology brings the following requirement that I assume also
relate to what is called "fumble"

"it should be possible to support receipt of multiple RTP sources without
explicit per-source signaling or negotiation."

Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Magnus Westerlund
Sent: 14 February, 2013 4:01 PM
To: Adam Roach
Cc: [email-masked]
Subject: Re: [MMUSIC] More thoughts on multiple media streams in a single m=
line

On 2013-02-05 16:25, Adam Roach wrote:
> On 2/4/13 02:45, Justin Uberti wrote:
>> Sorry for the short lead time, but here's a quick read for the plane.
> 
> I addressed several of the assertions made in this draft in my 
> previous response (e.g. the need for glare resolution regardless of 
> which solution we select). Some additional thoughts:
> 
>>    o  Adding or removing a source requires sending a full list of all
>>       sources, which doesn't scale well to 10s or 100s of sources,
>>       especially when they are added or removed frequently.
> 
> Realistically, this isn't how multiparty conferences are handled. It's 
> unrealistic to think that my DSL connection is going to be sucking 
> down hundreds of video streams just because I'm in a video conference 
> with hundreds of people.
> 
> In practice, the way existing conferencing systems handle this is to 
> send a small, manageable number of streams to each participant, 
> changing them out as necessary to have a reasonable user experience 
> (either under the control of the user, its own algorithms, or a
combination of the two).
> 
> Which is to say: even with hundreds of source streams being fed into a 
> conference system, you're really looking at a realistic upper bound on 
> m= sections of a dozen or two, simply because you can't reasonably 
> expect recipients to receive more than that many streams simultaneously.
> 

Hi,

I definitely want to comment on this from an RTP usage perspective that
might be very relevant to remember. Even with a centralized conference
solution there is two very distinct solutions in RTP how to transmit a
session where you have total of 100 participants and you receive 5 video
streams.

A) Central point with conceptual sources In this case the central entity
creates conceptual RTP streams that carries all the media intended for a
specific usage, for example main video, thumbnail one, thumbnail two,
thumbnail three, thumbnail four.

B) Central point doing source projection In this case there exist 100
potential RTP streams and SSRC from the central point down to the receiver.
However, at any point no more than five will actually have RTP packets. But
as activity changes and which is most relevant for the receiver the SSRCs in
use will switch.

For a solution where each SSRC requires its own m= line A) is definitely
preferable as it will not require renegotiating the properties for these
five conceptual streams. However, B will require a large number of m= lines
and dynamic updates as participants comes and go.

IF one had a single m= line per RTP session and media type, the amount of
updates/renegotiation depends on the amount of meta data about streams that
you have put in the SDP. They solutions A) and B) can be identical from an
SDP perspective.

The above two cases I am quite certain we did discuss in the CLUE interim
meeting in Stockholm when discussing topologies and also the relation ship
between RTP streams (SSRC) and their origin, i.e. media source/capture.

Cheers

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

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

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 16 Feb 2013 13:07:07 -0800

[BA]  If A/V multiplexing is negotiated, then the only RTP de-multiplexing points you have left are the SSRC and the Payload type.  If you rule out "explicit per-source signaling", that rules out SSRC de-multiplexing, which leaves you only with Payload Type.  Am I missing something? 

I do agree that without A/V multiplexing, it is possible to avoid explicit per-source signaling, since we can use the RTP session to de-multiplex, so that we're still ok.  But then we're not talking about Bundle/Grumble/Fumble/Humble, right?

---

From: "Roni Even" <[email-masked]>
Date: Sun, 17 Feb 2013 10:37:57 +0200

Hi,

The SSRCs will still be unique in the RTP session, I assume that what you
are asking is how do you know what this SSRC is. It is not only if it is
audio or video but may also apply to what is this audio and video is. For
example, in a video conferencing systems with three monitors and cameras,
how do we know where this SSRC should go. 

In CLUE we use a Capture ID that can be defined for each SSRC but can also
be carried as a RTP header extension to provide the information. So when a
new RTP stream with an SSRC that was not in the SDP it will have an RTP
header extension with the CaptureID allowing the receiver to know what the
stream is for.

Roni Even

From: Bernard Aboba [mailto:[email-masked]] 
Sent: 16 February, 2013 11:07 PM
To: Roni Even
Cc: [email-masked]
Subject: RE: [MMUSIC] More thoughts on multiple media streams in a single m=
line - requirements for "fumble"!!!

[BA]  If A/V multiplexing is negotiated, then the only RTP de-multiplexing
points you have left are the SSRC and the Payload type.  If you rule out
"explicit per-source signaling", that rules out SSRC de-multiplexing, which
leaves you only with Payload Type.  Am I missing something? 

I do agree that without A/V multiplexing, it is possible to avoid explicit
per-source signaling, since we can use the RTP session to de-multiplex, so
that we're still ok.  But then we're not talking about
Bundle/Grumble/Fumble/Humble, right?