[MMUSIC] MMT bandwidth limits (Re: comments on draft-holmberg-mmusic-sdp-mmt-negotiation-00)

Harald Alvestrand <harald@alvestrand.no> Mon, 05 November 2012 21:24 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F54E21F8643 for <mmusic@ietfa.amsl.com>; Mon, 5 Nov 2012 13:24:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.695
X-Spam-Level:
X-Spam-Status: No, score=-108.695 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lER8y1ZaEO9C for <mmusic@ietfa.amsl.com>; Mon, 5 Nov 2012 13:24:07 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5F40E21F862C for <mmusic@ietf.org>; Mon, 5 Nov 2012 13:24:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8F9E239E197 for <mmusic@ietf.org>; Mon, 5 Nov 2012 22:23:58 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4c4rZf5KvjQQ for <mmusic@ietf.org>; Mon, 5 Nov 2012 22:23:57 +0100 (CET)
Received: from [IPv6:2001:df8:0:16:ed78:3a9f:6634:b011] (unknown [IPv6:2001:df8:0:16:ed78:3a9f:6634:b011]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0982439E091 for <mmusic@ietf.org>; Mon, 5 Nov 2012 22:23:56 +0100 (CET)
Message-ID: <50982E6B.1010904@alvestrand.no>
Date: Mon, 05 Nov 2012 22:23:55 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <92B7E61ADAC1BB4F941F943788C088281074BD@xmb-aln-x08.cisco.com> <7594FB04B1934943A5C02806D1A2204B024E1B@ESESSMB209.ericsson.se> <92B7E61ADAC1BB4F941F943788C0882810758B@xmb-aln-x08.cisco.com>
In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882810758B@xmb-aln-x08.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [MMUSIC] MMT bandwidth limits (Re: comments on draft-holmberg-mmusic-sdp-mmt-negotiation-00)
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: Mon, 05 Nov 2012 21:24:08 -0000

On 11/05/2012 04:29 AM, Charles Eckel (eckelcu) wrote:
> In the case of multiple m-lines, you can assign a bandwidth per m-line and have the session bandwidth cap the total bandwidth for the session. With anymedia and a single m-line, you lose the granularity you previously had at the m-line level and are left with specifying the bandwidth for the anymedia line as a whole.
> For example, today I might offer the following for a video call with content sharing:
>
> v=0 	
> o=anonymous 1240218157 1240218157 IN IP4 10.193.128.35
> s=-
> i=myUserAgent
> c=IN IP4 10.193.128.35
> b=TIAS:512000
> t=0 0
> m=audio 6000 RTP/AVP 0 18 101
> a=rtpmap:0 PCMU/8000
> a=rtpmap:18 G729/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
> m=video 6002 RTP/AVP 96
> b=TIAS:512000
> a=rtpmap:96 H264/90000
> a=fmtp:96 profile-level-id=428014
> a=content:main
> m=video 6002 RTP/AVP 96
> b=TIAS:256000
> a=rtpmap:96 H264/90000
> a=fmtp:96 profile-level-id=428014
> a=content:slides
>
> In this case, depending on the answer, the audio will take between 8k and 64k, the main video can take the remainder of the 512k until content sharing starts, and once content sharing starts, the main video could drop down a bit to free some bandwidth for the content .
> With mmt, all I can specify is 512k for the total. I cannot subdivide it per media stream as above. To do so, I would need to specify some new SDP and/or encode the SSRC values I plan to use in SDP.
I'm curious - if I send this in an offer, is there any part of the SDP 
description that says that the respondent, when sending, should cut down 
on his video bandwidth if video + audio would otherwise be > 512K?

I don't see any "priority" flags in there.

(another thing that confuses me a bit is how b= represents bandwidth in 
the 2 directions for a point-to-point session - if A sends an offer with 
session b=TIAS:512K, and B sends A an answer with session b=TIAS:512K, 
and they both start sending video at 300K, are they below the cap or 
above the cap?

Again, it's probably clear to those who've been around here for a while)

                 Harald