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

Jonathan Lennox <jonathan@vidyo.com> Wed, 13 July 2016 14:14 UTC

Return-Path: <prvs=1002ceae5a=jonathan@vidyo.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 52FEA12D81F; Wed, 13 Jul 2016 07:14:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.83
X-Spam-Level:
X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, 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 ZOWYSdVkgdzi; Wed, 13 Jul 2016 07:14:34 -0700 (PDT)
Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3318A12D825; Wed, 13 Jul 2016 07:14:34 -0700 (PDT)
Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u6DE9tPI001747; Wed, 13 Jul 2016 10:14:31 -0400
Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 241uh6bp6e-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 13 Jul 2016 10:14:30 -0400
Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Wed, 13 Jul 2016 09:14:29 -0500
From: Jonathan Lennox <jonathan@vidyo.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Thread-Topic: [MMUSIC] BUNDLE: a single stream with multiple MIDs?
Thread-Index: AQHR2KAHglPM/iUn/kOx+O/DTOsKb6AOCHGAgAD7UYCABNYRAIABgXGAgAD1V4CAAHOwgA==
Date: Wed, 13 Jul 2016 14:14:28 +0000
Message-ID: <4BA5AF95-3E88-4BA4-8DAD-D29F1195BD8D@vidyo.com>
References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> <CAMRcRGRMp-tehSjwaXh4rzwedsHHjXaxhJ=pd0-9XiSCiLG_2Q@mail.gmail.com> <7E00EB16-72FE-4A1E-A268-66674361FB2B@vidyo.com> <CAJrXDUFpkVegw_hb4hFVP0Bme=6avVC8J3hucuhHDbvOamn-2w@mail.gmail.com> <3BECBA70-B73C-4E87-8A69-55AAA406A8B9@vidyo.com> <D3ABBD5F.BD61%christer.holmberg@ericsson.com>
In-Reply-To: <D3ABBD5F.BD61%christer.holmberg@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [160.79.219.114]
Content-Type: multipart/alternative; boundary="_000_4BA5AF953E884BA48DADD29F1195BD8Dvidyocom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-07-13_04:2016-07-13,2016-07-13,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1603290000 definitions=main-1607130159
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/QqWmnal9mNEkoox3m2e3SajfdoA>
Cc: mmusic <mmusic@ietf.org>, Google-Peter Thatcher <pthatcher@google.com>, IETF AVTCore WG <avt@ietf.org>
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 14:14:38 -0000

On Jul 13, 2016, at 3:20 AM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:


Hi,

A few questions:


Q1:

If an RTP packet is associated with two or more m- lines, which codecs payload type values, SSRC values should it use? Can it pick from any of the associated m- lines, or does one of the MIDs have to be the “primary”, while the others are “secondary”, “temporary”, or whatever we want to call them…

It would have to satisfy all of them — in situations where that's not possible (e.g. if the two m-lines specify non-overlapping codec sets) this couldn’t be used.

a=ssrc would probably not be usable in this model, but it’s probably in general not usable for a loudest-speaker-switching m-line which is switching SSRC (as opposed to CSRC).


Q2:

Currently, draft-bundle says:

   "The RTP MID header extension SHOULD be included in some RTP packets
   at the start of the session and whenever the SSRC changes."

Now, when the “loudest speaker” changes, the SSRC does not change (at least not the SSRC of the “boss”). But, there must still be a “I am no longer also MID Y” indication.

At the same time, if the “loudest speaker” is now associated with another m- line (e.g. “secretary”), there must not be an indication that the “secretary” MID and “loudest speaker” MID are associated.

I think it’s clearer if you interpret “when the SSRC changes” as if it were “whenever the mapping between SSRC and MID changes”.  This means the same thing if there’s only one MID per SSRC, but if you have multiple MID values for an SSRC you have to re-send the whole (new) set whenever the set changes.


Regards,

Christer













From: mmusic <mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org>> on behalf of Jonathan Lennox <jonathan@vidyo.com<mailto:jonathan@vidyo.com>>
Date: Tuesday 12 July 2016 at 19:42
To: "pthatcher@google.com<mailto:pthatcher@google.com>" <pthatcher@google.com<mailto:pthatcher@google.com>>
Cc: "avt@ietf.org<mailto:avt@ietf.org>" <avt@ietf.org<mailto:avt@ietf.org>>, "mmusic@ietf.org<mailto:mmusic@ietf.org>" <mmusic@ietf.org<mailto:mmusic@ietf.org>>
Subject: Re: [MMUSIC] BUNDLE: a single stream with multiple MIDs?


On Jul 11, 2016, at 1:42 PM, Peter Thatcher <pthatcher@google.com<mailto:pthatcher@google.com>> wrote:

Basically what your're asking for is header extension that says "Not only am I MID X, but I'm also, temporarily, MID Y"?   Why not just have a second, separate, header extension for "I'm also temporarily MID Y"?   Then the existing semantics of BUNDLE and MID (and RIDs, which are scoped to MIDs) need not change, but you get the information you need (I think).

The thing is, all MID values are, conceptually, temporary — they can change at any time.  So is it really meaningful to distinguish short-term temporary from long-term temporary?  Where do you draw the line?

On Fri, Jul 8, 2016 at 8:51 AM, Jonathan Lennox <jonathan@vidyo.com<mailto:jonathan@vidyo.com>> wrote:
The intention of my proposal is that these could indeed be (temporarily) the same RTP media source, even though they’re two separate m-lines.

On Jul 7, 2016, at 8:52 PM, Suhas Nandakumar <suhasietf@gmail.com<mailto:suhasietf@gmail.com>> wrote:

Hi Jonathan

  Clarification question :

   if we have 2 m=lines

m = ...
a=mid1
<manager>

m=...
a=mid2
<loudest speaker>

does these 2 correspond to same media source ? It felt so from the duplicate design you mentioned but wanted to confirm

Thanks
Suhas



On Fri, Jul 8, 2016 at 4:06 AM, Jonathan Lennox <jonathan@vidyo.com<mailto:jonathan@vidyo.com>> wrote:
Hi, all —

(This was an issue I raised in AVTCORE in Buenos Aires — I promised to send e-mail to the list but hadn’t remembered to get around to it until now.)

When finishing up the CLUE RTP mapping draft, I realized that one of CLUE’s RTP requirements didn’t actually end up getting satisfied by BUNDLE (which is the solution CLUE converged on).  This isn’t a CLUE-specific issue, so I’m raising it here.

The issue is whether we want to support a use case, in BUNDLE, where a single RTP stream corresponds to more than media description (and thus has more than one MID value)?

The use case is where one m-line has a semantic of “always view this person” (my boss, say, or my customer); and another m-line has a semantic of “the current loudest speaker”. (In CLUE, these would be a single content capture in the former case, and a switched capture for the latter.)  Whenever the boss *is* the current loudest speaker, the same content would be sent for both m-lines.

A naive implementation would simply duplicate all the packets for the two m-lines, with different MID values, but this has two problems.  First off all, it obviously wastes bandwidth.  Potentially more seriously, it precludes any RTP middlebox topology which doesn’t rewrite SSRC values, since the same content (arriving with a single SSRC value at the middlebox) would need to be sent with two different SSRC values down from the middlebox.  If PERC goes with its current consensus of no SSRC rewriting, this will particularly be a problem for PERC.

I certainly don’t think this is something that should block BUNDLE’s completion, but I think it could be a pretty easy extension.

(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.)

What do people think — is this worth working on?  Is there interest in discussing it in Berlin, and if so, in what venue?
_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic



_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic