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

Jonathan Lennox <jonathan@vidyo.com> Mon, 25 July 2016 18:16 UTC

Return-Path: <prvs=1014604314=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 AC58C12D961; Mon, 25 Jul 2016 11:16:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 cBJ6XdO3H5jc; Mon, 25 Jul 2016 11:16:47 -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 AD0D612D966; Mon, 25 Jul 2016 11:16:45 -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 u6PIGeKh022950; Mon, 25 Jul 2016 14:16:40 -0400
Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 241uh6m4gq-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 25 Jul 2016 14:16:40 -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; Mon, 25 Jul 2016 13:16:39 -0500
From: Jonathan Lennox <jonathan@vidyo.com>
To: Miguel París Díaz <mparisdiaz@gmail.com>
Thread-Topic: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs?
Thread-Index: AQHR3bAS2iXZNVjDUESNYXQcq89uRqAYBL8AgABgnYCAAAGkAIAJJ36AgABFx4CAApMIgIAFcoMA
Date: Mon, 25 Jul 2016 18:16:39 +0000
Message-ID: <B01B64DD-F99D-4876-A545-D608068ADE3D@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> <CAJrXDUETxAbt4pP2ShAKuYSaDdRk5u_c1antpVATE+NinAaiVA@mail.gmail.com> <D3AD2F4A.BEE3%christer.holmberg@ericsson.com> <CALiegf=VCCK0SYysZ3VbP7WRrGFE_3P-Fn2BYouVE4faX1JMzw@mail.gmail.com> <D3AD3CF3.BEFB%christer.holmberg@ericsson.com> <CAMRcRGTjXK_vK3JAoiMY332WjZuf2+GxmFcODCOA6=pnArG+Dw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B476AA914@ESESSMB208.ericsson.se> <CAEn+E3ie69kZqDx6cNOnJ-AvcfVOqA0AwhJ5_R5LwgvEtzm7tw@mail.gmail.com> <9245E2F8-C683-438F-BD16-0BEA27D813EE@vidyo.com> <CAEn+E3gHbc6ObgSAyMj6x-UbP4Tc=LLaj6rrSWLO9gY0KaMLkQ@mail.gmail.com>
In-Reply-To: <CAEn+E3gHbc6ObgSAyMj6x-UbP4Tc=LLaj6rrSWLO9gY0KaMLkQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [160.79.220.24]
Content-Type: multipart/alternative; boundary="_000_B01B64DDF99D4876A545D608068ADE3Dvidyocom_"
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-25_14:2016-07-25,2016-07-25,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-1607250210
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/aCpfBJyYeWmRRpqqmSRdpWt4v2s>
Cc: mmusic <mmusic@ietf.org>, 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: Mon, 25 Jul 2016 18:16:50 -0000

On Jul 22, 2016, at 3:05 AM, Miguel París Díaz <mparisdiaz@gmail.com<mailto:mparisdiaz@gmail.com>> wrote:

Hello Jonathan,
Do you mean to add MID SDES Item [1] using SDES header extensions [2] and also extends that to provide the "version"?
If we use this approach, RTP MID Header Extension [3] would be useless, wouldn't it?

The plan is to update the definition of the MID Header Extension in BUNDLE to use the SDES header extensions draft.  This isn’t a change to the bits on the wire or in the signaling, just in how it’s specified.

Anyway, could you expand your idea to show how would you solve the race condition problem?

Since SDES is sent periodically, even if packet reordering causes endpoint confusion (which is unlikely, since MID is only supposed to be sent “early” in a stream), the endpoint should resynchronize pretty quickly.


Best!!

Refs
[1] https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-31#section-14.2
[2] https://tools.ietf.org/html/draft-ietf-avtext-sdes-hdr-ext-07
[3] https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-31#section-14.3


2016-07-20 17:46 GMT+02:00 Jonathan Lennox <jonathan@vidyo.com<mailto:jonathan@vidyo.com>>:
draft-ietf-avtext-sdes-hdr-ext discusses ways to notice reordering of packets carrying SDES header extensions (of which MID is an instance).  Is that text sufficient?

On Jul 20, 2016, at 1:36 PM, Miguel París Díaz <mparisdiaz@gmail.com<mailto:mparisdiaz@gmail.com>> wrote:

Hello,
thinking a bit about that idea, if we support that different RTP streams have the same MID, we should provide a kind of version to deal with race conditions.

Taking the example of “the current loudest speaker” (LS) , if the middle box switches many times Alice <-> Bob streams the endpoint receiving the RTP streams may show the incorrect loudest-speaker due to processing an RTP stream before the other one (network, race condition into the endpoint, etc.)

Imagine that case:
MidleBox side: Alice LS -> Bob LS -> Alice LS
Endpoint side: Process Alice as LS -> Process Alice LS -> Process Bob LS

At the end the endpoint would render Bob as LS, but it is wrong.

To fix this race condition problem I propose adding a version:
MidleBox side: Alice LS-0 -> Bob LS-1 -> Alice LS-2
Endpoint side: Process Alice as LS-0 -> Process Alice LS-2 -> Process Bob LS-1 (discarded because 1<2)

What do you think about that?

Best regards!!


2016-07-14 17:49 GMT+02:00 Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>:
Hi,

You don't need a common logic. You can define an application layer protocol (e.g. CLUE) to define/configure/negotiate these kind of things.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Suhas Nandakumar<mailto:suhasietf@gmail.com>
Sent: ‎14/‎07/‎2016 18:43
To: Christer Holmberg<mailto:christer.holmberg@ericsson.com>
Cc: Iñaki Baz Castillo<mailto:ibc@aliax.net>; Jonathan Lennox<mailto:jonathan@vidyo.com>; mmusic<mailto:mmusic@ietf.org>; IETF AVTCore WG<mailto:avt@ietf.org>
Subject: Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs?



On Thu, Jul 14, 2016 at 3:27 PM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:

>...
>
>The current proposal breaks that. Please let's MID to be a single,
>unique and mandatory attribute per m-line.


Šand let each RTP packet be associated with one, and only one, of those
MIDs/m-lines.


You can then have application logic saying e.g. ³If no Œloudest-speaker¹
media is received, then duplicate the Œboss¹ media on the screen
associated with the loudest speaker². It¹s much more flexible, and without
any of the constraints mentioned earlier.


I agree it brings in flexibility and it scares me a bit as well .. Each application needs to define their own logic or need a common logic across all applications ..



Regards,

Christer

_______________________________________________
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




--
Miguel París Díaz
------------------------------------------------------------------------
Computer/Software engineer.
Researcher and architect in http://www.kurento.org<http://www.kurento.org/>
http://twitter.com/mparisdiaz
------------------------------------------------------------------------




--
Miguel París Díaz
------------------------------------------------------------------------
Computer/Software engineer.
Researcher and architect in http://www.kurento.org<http://www.kurento.org/>
http://twitter.com/mparisdiaz
------------------------------------------------------------------------