Message-ID: <1350080115.2197.3.camel@TesterTop4>
From: Olivier =?ISO-8859-1?Q?Cr=EAte?= <olivier.crete@collabora.com>
To: mmusic@ietf.org
Date: Fri, 12 Oct 2012 18:15:15 -0400
In-Reply-To: <CABkgnnWSTDok4-48g-vFGM_zk0ykU-BvrOWfpffAfJeZd41EGA@mail.gmail.com>
References: <CABkgnnWSTDok4-48g-vFGM_zk0ykU-BvrOWfpffAfJeZd41EGA@mail.gmail.com>
Organization: Collabora
Content-Type: multipart/signed; micalg="pgp-sha1";
 protocol="application/pgp-signature"; boundary="=-ra9vdk16Ybx69vnOwRC+"
Mime-Version: 1.0
Subject: Re: [MMUSIC] The floodgates are open
Precedence: list

--=-ra9vdk16Ybx69vnOwRC+
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-10-12 at 14:59 -0700, Martin Thomson wrote:
> The consent that ICE provides is strictly Boolean.
>=20
> There is no way to distinguish between consent to receive 4kbps audio
> and 5Mbps video.  This creates an exposure for services and endpoints
> that support receipt of media, in particular contact centres and other
> services that are necessarily open to incoming sessions by default.
>=20
> This working group has an analogous problem.  The consent to entertain
> modifications to ICE did not stipulate any constraints on volume.
> Looking to exploit that shortcoming, Bernard and I have submitted a
> draft that addresses the protocol shortcoming:
>=20
> http://tools.ietf.org/html/draft-thomson-mmusic-rtcweb-bw-consent-00

I really think you're trying to put this in the wrong layer. SDP already
has b=3D lines. And WebRTC should also include a congestion control
mechanism which you can probably also use to control/share bandwidth
more dynamically.

--=20
Olivier Cr=C3=AAte
olivier.crete@collabora.com

--=-ra9vdk16Ybx69vnOwRC+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlB4lnMACgkQHTiOWk7Zors9uwCfYNtPtzqYosefrqI10BnLU9Dp
LNkAniwBJNy9o4y4OADCvb+rWgtB1h6A
=2I5o
-----END PGP SIGNATURE-----

--=-ra9vdk16Ybx69vnOwRC+--