Re: [MMUSIC] Extremely drafty minutes
Ted Hardie <ted.ietf@gmail.com> Tue, 05 March 2013 21:26 UTC
Return-Path: <ted.ietf@gmail.com>
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 CEC0421F881D; Tue, 5 Mar 2013 13:26:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpU-Yt34AG4C; Tue, 5 Mar 2013 13:26:26 -0800 (PST)
Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA9A21F87FF; Tue, 5 Mar 2013 13:26:25 -0800 (PST)
Received: by mail-ia0-f169.google.com with SMTP id j5so6775091iaf.0 for <multiple recipients>; Tue, 05 Mar 2013 13:26:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=BB7LyMd/ANd7ImshFunJznsj57UMxQPNpd3XUKjfXoU=; b=dZWJxmqkj3PbfBFbUQpKjBxSg8cf+QAtx04077xx8cNgk9RRRVR9q6SMd6vnva1jdJ VFRyheg6G3G2A0CYgIclc4soESFz1V8c7M/pEQ0ViQnf0TozgqfQyfyYMLah3F7kEqcH 0k/W04bzCPZuGeRwXDgN4exLmrGByR7ZPXN9tbjF6JL4Te+eXLSbr6ma+DRfTYIBJr10 D/e97oFpzfW2zJErAx+OdWBvdtUvcYy43+U8FUfrol4m1o+j/IJBCYZ6yz+zEbj9/BBh ytSyk3mtJzSAARZ6a4rm6Z55aGc7EUHbe6INhka6iceBtxIMPQ4yVkqK1P+ew1WUFpln +8nA==
MIME-Version: 1.0
X-Received: by 10.50.36.169 with SMTP id r9mr7814974igj.96.1362518784931; Tue, 05 Mar 2013 13:26:24 -0800 (PST)
Received: by 10.43.135.202 with HTTP; Tue, 5 Mar 2013 13:26:24 -0800 (PST)
In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828047C706E@xmb-aln-x08.cisco.com>
References: <CA+9kkMATtoDi+xhNtSTPyEJg2h+e8jL8sdn0P=36eC+zij7YLQ@mail.gmail.com> <92B7E61ADAC1BB4F941F943788C08828047C706E@xmb-aln-x08.cisco.com>
Date: Tue, 05 Mar 2013 13:26:24 -0800
Message-ID: <CA+9kkMBmdc09uxj=Vb9TphdxHpF_rmnff2=UZHSDdCwDZP3_mg@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, Harald Tveit Alvestrand <hta@google.com>
Subject: Re: [MMUSIC] Extremely drafty minutes
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: Tue, 05 Mar 2013 21:26:26 -0000
On Tue, Mar 5, 2013 at 9:06 AM, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote: > One question I have is in regard to the following point from the Feb 5 summary. > > " All SSRCs related to a single peer connection (which could encompasses more than one MediaStreams having more than one track) would come from a single SSRC space. " > > Is this a restatement of an opinion expressed at the mic, or does it carry some weight as a working group consensus? I recall discussion in this area, but I did not think consensus was reached that this is the way to go. If that is the case, I think the notes should mention that more discussion is needed. > My understanding of this is that it was expressed as a requirement by WebRTC on the work of RTCWEB, needed as part of the mechanics of how to plumb connections via the API. The base requirement is "a consistent identifer space for all the media that will be plumbed"; the SSRCs are the identifiers available. I may be mis-stating this, though, so it might be helpful if Stefan or Harald commented, as I think it was one of them that actually expressed it. As context for those who might be able to add their own understanding here, this is the relevant part of the draft minutes: For signaling, among the points raised: CLUE and RTCWEB likely have two different usage patterns. For CLUE, multiple media sources will be common, multiple encodings per media source will be the norm, multiple endpoints may be visible even in unicast transport, and there may be one or more RTP session. For RTCWEB, the current theory is that there is a single RTP session per media type, if not a single RTP session full stop. All SSRCs related to a single peer connection (which could encompasses more than one MediaStreams having more than one track) would come from a single SSRC space. regards, Ted
- [MMUSIC] Extremely drafty minutes Ted Hardie
- Re: [MMUSIC] Extremely drafty minutes Charles Eckel (eckelcu)
- Re: [MMUSIC] Extremely drafty minutes Ted Hardie