Re: [rtcweb] m=section recycling and a=mid

Harald Alvestrand <harald@alvestrand.no> Thu, 19 September 2013 22:22 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3580721F8948 for <rtcweb@ietfa.amsl.com>; Thu, 19 Sep 2013 15:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.698
X-Spam-Level:
X-Spam-Status: No, score=-108.698 tagged_above=-999 required=5 tests=[AWL=-1.700, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 Aq2j9SVqkCmN for <rtcweb@ietfa.amsl.com>; Thu, 19 Sep 2013 15:22:34 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B795C21F893E for <rtcweb@ietf.org>; Thu, 19 Sep 2013 15:22:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EFD3D39E1B7 for <rtcweb@ietf.org>; Fri, 20 Sep 2013 00:22:31 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MratdqsbNtLJ for <rtcweb@ietf.org>; Fri, 20 Sep 2013 00:22:30 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:903a:6934:230b:9fc1] (unknown [IPv6:2001:470:de0a:27:903a:6934:230b:9fc1]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 903A639E04F for <rtcweb@ietf.org>; Fri, 20 Sep 2013 00:22:30 +0200 (CEST)
Message-ID: <523B797C.7040603@alvestrand.no>
Date: Fri, 20 Sep 2013 00:23:56 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CAMRcRGRUufCBRg77DEEcqSvJ8uP2o2HU2GoJ23xu6wKPc9G3zA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C4A7F29@ESESSMB209.ericsson.se>, <CAMRcRGT5T6FQSxgot4HObMW2r+z9id+BsXd0O8ZEauZunNmtzw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C4A800E@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4A800E@ESESSMB209.ericsson.se>
Content-Type: multipart/alternative; boundary="------------080704040205040904050802"
Subject: Re: [rtcweb] m=section recycling and a=mid
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Sep 2013 22:22:38 -0000

I suggest that changing the MID value can be very painful, since it 
modifies the mapping between m-line index and MID.

Is there any other spec that describes changing the MID value?

If not, I'd suggest that we explicitly forbid changing the MID value. If 
we want to add or remove an M-line from a bundle, we should update the 
bundles instead.


On 09/19/2013 08:52 PM, Christer Holmberg wrote:
>
> Correct.
>
> Regards,
>
> Christer
>
> ------------------------------------------------------------------------
> *From:* Suhas Nandakumar [suhasietf@gmail.com]
> *Sent:* Thursday, 19 September 2013 9:48 PM
> *To:* Christer Holmberg
> *Cc:* rtcweb@ietf.org
> *Subject:* Re: [rtcweb] m=section recycling and a=mid
>
> Hello Christer
>
>   Completely agree with you
>
> My point with the above examples was
>
>   "recycling of m=line should take into account its existing BUNDLE 
> membership and JS user's preference on requiring the added media track 
> to be BUNDLED or not"
>
> This would imply, as suggested by you,
>
>   - remove the mid from a=group:BUNDLE line if the JS user doesn't 
> want the new track to be BUNDLEd
>
>  - or if the mid value is changed, then add the new mid value to the 
> BUNDLE group if the JS user want's the new track to be BUNDLED
>
> - or just retain the mid value and its BUNDLE membership for the new 
> track, if it is going to be BUNDLEd
>
>
> Cheers
> Suhas
>
>
>
>
>
>
>
> On Thu, Sep 19, 2013 at 9:24 AM, Christer Holmberg 
> <christer.holmberg@ericsson.com 
> <mailto:christer.holmberg@ericsson.com>> wrote:
>
>     Hi Suhas,
>
>     The mid attribute itself does not add an m- line to a BUNDLE
>     group. The attribute value also needs to be listed in the
>     group:BUNDLE attribute mid list.
>
>     So, if you want to re-use an m- line and mid attribute, but you
>     don't want the m- line to be in the BUNDLE group, simply remove
>     the mid from the mid list.
>
>     Regards,
>
>     Christer
>
>     ------------------------------------------------------------------------
>     *From:* rtcweb-bounces@ietf.org <mailto:rtcweb-bounces@ietf.org>
>     [rtcweb-bounces@ietf.org <mailto:rtcweb-bounces@ietf.org>] on
>     behalf of Suhas Nandakumar [suhasietf@gmail.com
>     <mailto:suhasietf@gmail.com>]
>     *Sent:* Wednesday, 18 September 2013 7:44 PM
>     *To:* rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>     *Subject:* [rtcweb] m=section recycling and a=mid
>
>     After thinking about it a bit, I think there are some side effects
>     associated with changing/not changing mid attribute of a re-cycled
>     m= section and it being part of a BUNDLE group or not..
>
>     example
>
>     say , we have these video m=section part of BUNDLE group as below
>     a=group:BUNDLE 1, 2
>
>     m=video .....
>     a=mid:1
>     a=inactive
>
>     m=video .....
>     a=mid:2
>     a=sendrecv
>
>     Now If JS user adds a new video track and he wants it to be out of
>     BUNDLE. If we recycle first video m=section and dont change mid
>     attribute,  we end up BUNDLing even if the user dint want to
>
>     On the other hand, if we allowed mid value to be changed, we might
>     end up UNBundling a video stream , when the user did want to
>     BUNDLE them
>
>     So allowing a mid value to be changed or not should be tied to
>     what the JS API is asking on behalf of the user
>
>
>     Any thoughts ?
>
>     Cheers
>     Suhas
>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb