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

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 05 June 2013 09:40 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 23BA121F99F0 for <mmusic@ietfa.amsl.com>; Wed, 5 Jun 2013 02:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.099
X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id GQuFLN1s1hIg for <mmusic@ietfa.amsl.com>; Wed, 5 Jun 2013 02:40:34 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se []) by ietfa.amsl.com (Postfix) with ESMTP id 6DA7021F941F for <mmusic@ietf.org>; Wed, 5 Jun 2013 02:40:34 -0700 (PDT)
X-AuditID: c1b4fb25-b7f4c6d000004656-10-51af0790ef99
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain []) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 61.EB.18006.0970FA15; Wed, 5 Jun 2013 11:40:32 +0200 (CEST)
Received: from [] ( by esessmw0191.eemea.ericsson.se ( with Microsoft SMTP Server id; Wed, 5 Jun 2013 11:40:32 +0200
Message-ID: <51AF07C5.2010907@ericsson.com>
Date: Wed, 5 Jun 2013 11:41:25 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "mmusic (E-mail)" <mmusic@ietf.org>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMJMWRmVeSWpSXmKPExsUyM+Jvre4E9vWBBjsWmVlMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGU9v32Qu2CNecfbfO9YGxnbhLkZODgkBE4mtr/awQ9hiEhfu rWfrYuTiEBI4xSjxcvcjRghnGaPE+obTjCBVvALaEvee9IB1sAioSGzZv5sVxGYTsJC4+aOR DcQWFQiWOLJ9MwtEvaDEyZlPwGwRAXWJ1s19YPXCAgYS/a/mQm2WlNjyoh3MZhbQk5hytYUR wpaXaN46mxnEFgLa29DUwTqBkX8WkrGzkLTMQtKygJF5FSN7bmJmTnq50SZGYEAd3PJbdQfj nXMihxilOViUxHn1eBcHCgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCccex6gklUQ8WVUJHz e8KmhB7Y2BNokxf3T8tP9MujeF5frp+V/peCpDL2TDqmeuON26SQ+l9LJzBfZsm0Vdmne9F/ T7npFwfdvK8PP776d8t+15HXnLsOzec4mi2srNsiVOi65LOgmeiNC/VbD7NntzGmsi6LMpuj Lez+7/+tedxXM+ZtVjigxFKckWioxVxUnAgAGvCKqvYBAAA=
Subject: [MMUSIC] A High level view of multiple m= blocks
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jun 2013 09:40:41 -0000


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.


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: magnus.westerlund@ericsson.com