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

Peter Thatcher <pthatcher@google.com> Wed, 21 October 2015 15:32 UTC

Return-Path: <pthatcher@google.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15161A8AD0 for <mmusic@ietfa.amsl.com>; Wed, 21 Oct 2015 08:32:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNX97y_BtIk9 for <mmusic@ietfa.amsl.com>; Wed, 21 Oct 2015 08:32:52 -0700 (PDT)
Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70FD51A8AC0 for <mmusic@ietf.org>; Wed, 21 Oct 2015 08:32:52 -0700 (PDT)
Received: by obctp1 with SMTP id tp1so17495508obc.2 for <mmusic@ietf.org>; Wed, 21 Oct 2015 08:32:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=g+cM2L+VNTOCZVe+671AJdOmSCR5rrNDPot0yLM+NgE=; b=Pn9dS5ovtCAerwOi6Nwg6a1LHZt3OmZeYXDv9vFE563UWug8IyihOCUnN5p+KHB32/ SBuhtK4PsiWJ2n2iCcEVb68jP8VI2ShBwbJzxl/7SOkyb6z9Ted27FAIK5G+voE0QvXw mz8NAZuW2GrM6thR8l57do0/vbG/aLR8zYzzMTc0435cOF2CaPHD+ZfYWPZI8qldUaF4 GDDeAB62Ep4uvK++CeEy4xboVdvNxfdbgX3bjDNUoA/vU06rxH/EjP8u/hMy1yr9hJPb HgdnZ9ErG59IKpt6qOehxJ+LqcO5RlCeog+mdxDcIh+TsCgatSsvR7E/y1vW21GG3lNY JyfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=g+cM2L+VNTOCZVe+671AJdOmSCR5rrNDPot0yLM+NgE=; b=E0XhnauK8QJJpRyKrQU1inwvoVOq1CBvYhuNJm0GLN+1BlKLP7zHBRvzGx3QUWC5eE eG/GPuy0yWDg7HEtl2rN2ohbmalzNOuwnEeSlJWCdQRsoI9HQfVKD1VMQvi0ZSpZu11q zBdGePZjkE5iudZkaYuQL6bTenF9FSRcdKg1Uqh4QUjO/M4PCvqf6mEKhtiu4GgRj3oX Aa82eulF+BL3Ti0ELtffDAMKDhTlNmKu+SAzW9E8HUto01dxC51qS2N83z+iHKCIDI2D eVzpCeD8kW7XzG8m9RZl2//GC7k53fRJQS9jEj0paE3nVk0DTenAgwW69mczH0b5Udbi F1ZQ==
X-Gm-Message-State: ALoCoQlHZ+CG0k2pgZgrKUZ+tRPsucpLY17fCEMZQkAcLWR+8+dlNjIiHTjs6+Mx+B1HxbHFkOjk
X-Received: by 10.182.186.34 with SMTP id fh2mr6586963obc.65.1445441571579; Wed, 21 Oct 2015 08:32:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.79.19 with HTTP; Wed, 21 Oct 2015 08:32:12 -0700 (PDT)
In-Reply-To: <562799B8.9080609@alvestrand.no>
References: <562799B8.9080609@alvestrand.no>
From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 21 Oct 2015 08:32:12 -0700
Message-ID: <CAJrXDUGGfmuFydCr-kEEXEVT3MgWE5gpOyb3ObVwdmxfQLSVdw@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: multipart/alternative; boundary=089e014953e26b2e7705229f1769
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/8_cPFmkkkp0U1sWs3yu7h8PugWA>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [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 15:32:54 -0000

I can think of some more alternatives:

Alternative 4.  Offer doesn't constrain max-goats until it know the
answerer supports and then does a re-offer with max-goats constrained:

offer 1:

a=rid:1 recv max-goats;max-fr=50
a=rid:2 recv max-goats;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

answer 1:

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

offer 2:

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

Problem: You'd probably need a re-offer for all recv lines doing this,
since all attributes are optional.




Alternative 5.  Accept all RIDs, drop constraints it does not understand,
*but remove the problematic RIDS from the simulcast line*.

Offer 1:

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

Answer 1:

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
a=simulcast: recv rid=3;4

Offer 2:

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


Alternative 6.  Mark constraints as optional

Offer 1:

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

Basically, have a marker for "I'd prefer this be the max, but if you don't
support this kind of max, at least send me something".  Notice the "?".







On Wed, Oct 21, 2015 at 6:57 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> I'm worried about the extensibility of the constraints model in the RID
> language.
> 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.
>
> Alternatives:
>
> 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:
>
> 1:
>
> a=simulcast:
>
> doesn't look good. You're not going to simulcast today.
>
> 2:
>
> 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.
>
> 3:
>
> 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?
>
>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>