Subject: [MMUSIC] A High level view of multiple m= blocks

From: Magnus Westerlund <[email-masked]>
Date: Wed, 5 Jun 2013 11:41:25 +0200

MMUSIC WG,

I wanted to share my personal view of how I look at the problems around
SDP that has arisen due to bundle and multi-stream (multiple SSRCs)
usage of RTP that is coming from use cases not only in WebRTC but also
in CLUE. Bundle introduces multiple m= blocks that configures a single
RTP session. So without killing Bundle we have to sort this out.
Preferably this can be done in a reasonably timely manner.

A really important aspect of using multiple m= blocks for a single RTP
session is that we need to decide when one should use multiple m= blocks
and when not. There are multiple different reasons listed in the
contributions and from my perspective we need to decide in each case if
that warrants to use different m= blocks or not. This is really a scale,
a scale between two extremes.

A) Different media types (audio, video, text) are the only reason to use
different m= blocks.

B) Each individual RTP stream (SSRC) shall have its own m= block to
describe it.

Considering the arguments I have heard so far, I think we are ending up
somewhere in the middle between these extremes. That requires us to
write rules and guidance on when it is expected to create different m=
block and when it is not.

I am proposing that people consider what reasons exist to create
different m= blocks. Also when different m= blocks cannot be applied. By
looking at individual reasons, the issue can be split up into individual
questions. That way we might get individual questions we actually can
discuss and agree on one after one. Not requiring people to accept the
grand plans, this only results in people wanting a slight variation.
Divide and conquer the problem into something we can make progress on.

Some individual questions that I believe needs to be considered are:

- Different sets of acceptable resolutions for video
- Different allowed bandwidth spans between media streams
- Different usages in application, i.e. main video, thumbnails,
  document camera
- Simulcast versions
- Layered encoding versions
- Different rendering screens
- Retransmission or FEC usage

I would also note that there are questions that are separable from this
general question if one should apply different m= lines to the issue or
not. These questions and issues must also be identified and treated
separately. Such a question for example is how to deal with dynamic
behaviors from media streams, where stream is frequently coming and
going, or changes role in the application.

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