[MMUSIC] Simulcast worries: Fallback in the a=rid language

Harald Alvestrand <harald@alvestrand.no> Wed, 21 October 2015 13:57 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 11A351A883E for <mmusic@ietfa.amsl.com>; Wed, 21 Oct 2015 06:57:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xYWLaEfY0nVB for <mmusic@ietfa.amsl.com>; Wed, 21 Oct 2015 06:57:15 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no []) by ietfa.amsl.com (Postfix) with ESMTP id D86F61A883C for <mmusic@ietf.org>; Wed, 21 Oct 2015 06:57:14 -0700 (PDT)
Received: from localhost (localhost []) by mork.alvestrand.no (Postfix) with ESMTP id 263087C0AEB for <mmusic@ietf.org>; Wed, 21 Oct 2015 15:57:14 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([]) by localhost (mork.alvestrand.no []) (amavisd-new, port 10024) with ESMTP id gi2PMoUMRyfJ for <mmusic@ietf.org>; Wed, 21 Oct 2015 15:57:13 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:1:2cac:97a8:89fe:113e] (unknown [IPv6:2001:470:de0a:1:2cac:97a8:89fe:113e]) by mork.alvestrand.no (Postfix) with ESMTPSA id 636BC7C0AEA for <mmusic@ietf.org>; Wed, 21 Oct 2015 15:57:13 +0200 (CEST)
To: "mmusic@ietf.org" <mmusic@ietf.org>
From: Harald Alvestrand <harald@alvestrand.no>
X-Enigmail-Draft-Status: N1110
Message-ID: <562799B8.9080609@alvestrand.no>
Date: Wed, 21 Oct 2015 15:57:12 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/Q0OkzhVhGcFLyKZMYT15Vvjrzic>
Subject: [MMUSIC] Simulcast worries: Fallback in the a=rid language
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Oct 2015 13:57:16 -0000

I'm worried about the extensibility of the constraints model in the RID
Consider for instance this situation:

- A knows about a new constraint "max-goats"
- B doesn't know about it

A sends:

a=rid:1 recv max-goats=47;max-fr=50
a=rid:2 recv max-goats=22;max-fr=20
a=rid:3 send max-goats=44;max-fr=20
a=rid:4 send max-goats=22;max-fr=10
a=simulcast: send rid=3;4 recv rid=1;2

This indicates that A offers two simulcast layers and is willing to
receive two.

B does not know about "max-goats". It's willing to do simulcast and obey
the FR constraint, but it has no way of knowing whether the streams it
generates will violate the goats restriction or not.


1 - Toss all RIDs that it cannot parse fully
2 - Accept all send RIDs that it can promise to handle, toss all receive
RIDs that it cannot promise to restrict itself to (because it doesn't
understand the restriction).
3 - Accept all RIDs, drop constraints it does not understand.

Resulting SDP would be:



doesn't look good. You're not going to simulcast today.


a=simulcast:recv rid=3;4
a=rid:3 recv max-fr=20
a=rid:4 recv max-fr=10

Works for incoming simulcast to B, but the ability to simulcast to A has
been lost: Expanding the language at A has created failure modes that
lead to lost functionality.


a=simulcast: recv rid=3;4 send rid=1;2
a=rid:1 send max-fr=50
a=rid:2 send max-fr=20
a=rid:3 recv max-fr=20
a=rid:4 recv max-fr=10

We keep simulcast capability, but if the goats restrictions were
important to A, it will now have to detect that capabilities were
dropped, and will have to do another offer/answer in order to prevent
itself being overrun by goats from B.

What's the USEFUL semantics to support on extensibility?