Re: [MMUSIC] Simulcast: Short timelines, draft impending

Flemming Andreasen <fandreas@cisco.com> Tue, 06 October 2015 11:42 UTC

Return-Path: <fandreas@cisco.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 093051B3FC0 for <mmusic@ietfa.amsl.com>; Tue, 6 Oct 2015 04:42:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 Vcl937G1myLC for <mmusic@ietfa.amsl.com>; Tue, 6 Oct 2015 04:42:42 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A591B3FBC for <mmusic@ietf.org>; Tue, 6 Oct 2015 04:42:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12274; q=dns/txt; s=iport; t=1444131762; x=1445341362; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=C0T0A5dEGn9tOH9AXkvqOZAWvOqEdslbKUAzQImtfOQ=; b=RXys2YcGPomg82y8ORvGMzHULKQxiMd0xJTi5fmwTQIqVHaDvSHi7nsG 8BzWr9ITo2+eOW5SEhVo1TN8hkEGYU0w4s4+fftO9gMBl7tyNUwYA0L7o 6eqo7X0zsUHVlUWPVG+vlZNmstg/h5BFGuIYjWToKmhz+gPvzVDC89L7q k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AKAgDishNW/4oNJK1egydUbr4kAQ2BWhcBC4UtSgKBOjgUAQEBAQEBAYEKhCUBAQQBAQFrBQUBEAsYCRYIBwkDAgECARUfEQYBDAYCAQEXiBMNvl8BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIZzhH6EKhEBUQeELgWWBIUYh3+BV4Q5gwCKFoRZg28fAQFCghEdgXAiM4Z/gUABAQE
X-IronPort-AV: E=Sophos; i="5.17,643,1437436800"; d="scan'208,217"; a="38712641"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Oct 2015 11:42:41 +0000
Received: from [10.98.149.197] (bxb-fandreas-8814.cisco.com [10.98.149.197]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t96BgeSU013349; Tue, 6 Oct 2015 11:42:40 GMT
To: Suhas Nandakumar <suhasietf@gmail.com>, Adam Roach <adam@nostrum.com>
References: <5604B29B.9070005@nostrum.com> <CAMRcRGQngExyrL0doFidea19D8QAvCAgwjoaS=DO+upNGXxL0w@mail.gmail.com>
From: Flemming Andreasen <fandreas@cisco.com>
Message-ID: <5613B3B4.7020107@cisco.com>
Date: Tue, 6 Oct 2015 07:42:44 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <CAMRcRGQngExyrL0doFidea19D8QAvCAgwjoaS=DO+upNGXxL0w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------040606010809050709000403"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/UoPm4QkYiBCpbyfVckTs2vIHTv4>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Simulcast: Short timelines, draft impending
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: Tue, 06 Oct 2015 11:42:45 -0000

Thank you for submitting the draft. Will there be an update to the 
simulcast draft as well before the Interim meeting next week ?

-- Flemming

On 10/2/15 6:48 PM, Suhas Nandakumar wrote:
> Hello All
>
>    As indicated by Adam in his email , we have submitted the draft 
> defining "RID".
>
>    The draft can be found here: 
> https://datatracker.ietf.org/doc/draft-pthatcher-mmusic-rid/?include_text=1
>
>    Please provide your feedback on the same.
>
> Thanks
> Suhas
>
> On Thu, Sep 24, 2015 at 7:34 PM, Adam Roach <adam@nostrum.com 
> <mailto:adam@nostrum.com>> wrote:
>
>     At the W3C WebRTC interim meeting a couple of weeks ago, one of
>     the issues that the group was not able to resolve was how to
>     enable the use of simulcast for WebRTC browser implementations. A
>     key point of contention was the use of unique payload types for
>     each simulcast encoding in the current MMUSIC document
>     (draft-ietf-mmusic-sdp-simulcast-01). Combined with the other
>     features planned for WebRTC, there is concern that such an
>     approach may lead to PT exhaustion within a session under certain
>     reasonably expected circumstances.
>
>
>     As important context: the WebRTC 1.0 specification is rapidly
>     approaching finalization, and the working group hopes to leave the
>     TPAC meeting at the end of October with all of the loose ends tied
>     up. Simulcast is one of the more important and one of the most
>     loose ends in the specification at the moment. As a result, we
>     sincerely hope that we can come to consensus on a viable approach
>     in MMUSIC over the next few weeks. To be explicit: the TPAC
>     meeting is the week before the Yokohama IETF meeting, so we cannot
>     afford to wait for the ordinary meeting-driven work schedule to
>     push simulcast along. We hope to foster a useful and productive
>     conversation on the mailing list well ahead of IETF 94.
>
>
>     While there were some “hallway discussions” in Prague to discuss
>     potential approaches that would address these concerns, none of
>     these have yet been documented and shared with the mailing list.
>
>
>     After significant conversations both at and after the interim
>     WebRTC meeting, and considering information about the type of
>     solutions that interested parties are likely to find acceptable, a
>     number of the WebRTC participants have come up with a tentative
>     proposal that we believe is likely to be simple, flexible, and
>     satisfactory to everyone involved. At a high level:
>
>
>      *
>
>        The current behavior described in the MMUSIC simulcast draft
>     remains
>        valid.
>
>      *
>
>        Additionally, we define a new attribute type (provisionally called
>        “RID”, for “RTP Stream ID”) that can be used to define additional
>        codec-independent constraints on PTs (e.g., max-fps, max-bps,
>        max-width, max-height).
>
>      *
>
>        RIDs can be defined to be unidirectional, so as to allow
>        implementations to signal the ability to send a different number of
>        encodings than they can receive.
>
>      *
>
>        The values for each constraint can be specified to be different in
>        each direction.
>
>      *
>
>        When used, the RID value is encoded as part of the RTP packet,
>     in an
>        extension header.
>
>      *
>
>        The values (that is, identifiers) used for RID are proposed by the
>        offerer in a session, and are symmetric. The RID values in an
>     answer
>        must be a subset of those present in the offer.
>
>      *
>
>        The parameters associated with a RID can be made more restrictive
>        (i.e., resolution decreased, bandwidth decreased), but not less
>        restrictive, in an answer.
>
>      *
>
>        For those sessions that use RIDs, the “a=simulcast” parameter is
>        enhanced to be able to carry RIDs instead of PTs.
>
>
>     We hope to have an internet-draft that describes this approach in
>     more detail by the end of next week.
>
>     /a
>
>     _______________________________________________
>     mmusic mailing list
>     mmusic@ietf.org <mailto:mmusic@ietf.org>
>     https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic