Re: [AVTCORE] [MMUSIC] BUNDLE: a single stream with multiple MIDs?

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 13 July 2016 09:29 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3453112D69F; Wed, 13 Jul 2016 02:29:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 XSj1nHpfuVwD; Wed, 13 Jul 2016 02:29:25 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A95BD12D5D6; Wed, 13 Jul 2016 02:29:24 -0700 (PDT)
X-AuditID: c1b4fb3a-f79386d00000467b-ea-578609f29b4d
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B0.16.18043.2F906875; Wed, 13 Jul 2016 11:29:23 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.294.0; Wed, 13 Jul 2016 11:29:22 +0200
To: Jonathan Lennox <jonathan@vidyo.com>, IETF AVTCore WG <avt@ietf.org>, mmusic <mmusic@ietf.org>
References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <3c392b30-e5a1-9cba-d6a8-e3d2c64da7e0@ericsson.com>
Date: Wed, 13 Jul 2016 11:29:20 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyM2K7k+5nzrZwg5dz2S1e9qxkt9i/+Dyz xdTlj1kcmD2WLPnJ5NH27A57AFMUl01Kak5mWWqRvl0CV8afl2uZCg4KVuxoFWhg/M/bxcjJ ISFgIvH542xWCFtM4sK99WxdjFwcQgJHGCVeHLsO5SxnlHj57BE7SJWwgKPE8/k72EBsEYEU iY73c8HiQgI2ErN/bQWbxCZgIXHzRyNYDa+AvUT3369gNSwCqhJ/1q1h7GLk4BAViJFY35cA USIocXLmExYQm1PAVuLp37VMIDYz0JiZ888zQtjyEs1bZzNDrNKWaGjqYJ3AKDALSfssJC2z kLQsYGRexShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYnge3/LbawXjwueMhRgEORiUeXgWD 1nAh1sSy4srcQ4wSHMxKIrxB7G3hQrwpiZVVqUX58UWlOanFhxilOViUxHn9XyqGCwmkJ5ak ZqemFqQWwWSZODilGhjLUh+tftBzUjvitsSKFUILWZfOZpt0wPn0ZcdjW5c8ffGBj2OeurK3 xNkds3/NkXY5t1h4UcykjRfXbGBZWOgUMX3rPXWbrgZNdac906InnV7Q8GBDK89y1d1Vfa92 rlzUOW9dQbco38fDBZkcizZbnW6r4b9seUVu2/vv8Rs88o9cF9+kp3blvxJLcUaioRZzUXEi AF23oX1LAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/W_92Zvu1cLiN_RfMYDd8wbP0_ak>
Subject: Re: [AVTCORE] [MMUSIC] BUNDLE: a single stream with multiple MIDs?
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jul 2016 09:29:26 -0000

Den 2016-07-08 kl. 00:36, skrev Jonathan Lennox:

> (My initial design proposal was to allow multiple SDES values of the
> same type, and multiple SDES header extensions items of the same
> type, to be sent simultaneously in RTP — protocol-syntactically this
> is trivial, you’d just need to negotiate that you support it.  But
> I’m not wedded to this solution.)
>

So, if one is going to enable multiple concurrent values for SDES items 
that clearly needs an RTP extension which defines how one does. It also 
needs to discuss which SDES items of the existing that can be used in 
this way and what it means. There also needs to be clear procedures for 
how one deals with updates of the current set. Clearly this needs to be 
a signalled extension as you say.

I think this is clearly work belonging to the AVTCORE WG.

> What do people think — is this worth working on?  Is there interest
> in discussing it in Berlin, and if so, in what venue?

I think this is worth some more thinking. My review of the RID drafts 
mad it clear to me that we might not have sufficiently thought through 
how the scoping and interactions are between the different new 
labellings we have for RTP stream. And this also points at another 
aspect, the expectations of what is produced from a media description. 
For media source that are what I call conceptual, like the "current 
speaker" or role based like "meeting chair", there clearly need to be 
understanding how this interacts in the signalling solutions.

I am sorry to say that I have lost track of where CLUE has ended up and 
the interaction between SDP and the CLUE layer.

I don't want to commit to anything, but I am happy to continue 
discussing this.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------