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

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 20 September 2013 06:47 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 46FC821F8790 for <rtcweb@ietfa.amsl.com>; Thu, 19 Sep 2013 23:47:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.235
X-Spam-Level:
X-Spam-Status: No, score=-4.235 tagged_above=-999 required=5 tests=[AWL=-0.987, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4]
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 X0naLYaFmXwC for <rtcweb@ietfa.amsl.com>; Thu, 19 Sep 2013 23:47:42 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5323021F8443 for <rtcweb@ietf.org>; Thu, 19 Sep 2013 23:47:41 -0700 (PDT)
X-AuditID: c1b4fb30-b7f9a8e000005620-49-523bef8b40b0
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 32.A2.22048.B8FEB325; Fri, 20 Sep 2013 08:47:40 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Fri, 20 Sep 2013 08:47:38 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Suhas Nandakumar <suhasietf@gmail.com>, Harald Alvestrand <harald@alvestrand.no>
Thread-Topic: [rtcweb] m=section recycling and a=mid
Thread-Index: AQHOtI5OlzgN5l68MU+Yf86f9mtTsJnNP/0ZgAAG7ICAACKcC4AAGbIAgAAAV4CAAK3l0A==
Date: Fri, 20 Sep 2013 06:47:37 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4A82DF@ESESSMB209.ericsson.se>
References: <CAMRcRGRUufCBRg77DEEcqSvJ8uP2o2HU2GoJ23xu6wKPc9G3zA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C4A7F29@ESESSMB209.ericsson.se> <CAMRcRGT5T6FQSxgot4HObMW2r+z9id+BsXd0O8ZEauZunNmtzw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C4A800E@ESESSMB209.ericsson.se> <523B797C.7040603@alvestrand.no> <CAMRcRGSVwTfCK_znni5K29e3UEP_r7COPTyB23mSJ5vzWhLOAw@mail.gmail.com>
In-Reply-To: <CAMRcRGSVwTfCK_znni5K29e3UEP_r7COPTyB23mSJ5vzWhLOAw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4A82DFESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+JvjW7Pe+sgg+dtPBbH+rrYLNb+a2e3 2Dm3g9mB2ePKhCusHjtn3WX3WLLkJ1MAcxSXTUpqTmZZapG+XQJXxtrLUgWrJjNW/Pmh38C4 s4Gxi5GTQ0LAROLs/XssELaYxIV769m6GLk4hAQOM0rsbX/PBOEsYZRY9PI7excjBwebgIVE 9z9tkAYRgTCJzncb2EBsZgF1iTuLz7GD2MICxhILn/1igagxkdg1dw0bTH3/sU1gi1kEVCU6 Dj5kArF5BXwlDi/dCrW4k1ni1qqnYM2cAoESHXtmgg1lBLru+6k1TBDLxCVuPZnPBHG1gMSS PeeZIWxRiZeP/7GC3CkhoCixvF8Oojxf4uP5JSwQuwQlTs58wjKBUXQWkkmzkJTNQlIGEdeR WLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzGy5yZm5qSXm29iBMbZwS2/DXYwbrovdohRmoNF SZx3s96ZQCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MDPpvzqjo/fR5F57vHey43r5EceFH xpjdf9VnxXoFlil8uSWYLtBlq1Af5823WnSRituyGimf6ypv1h1rWZeZvrglyFuC29o3YPq5 uJ/2n48e37k29xZ3zLczvAbBXQlrggOv34mTuGwg0CNYNF/lNbPu5kMXyk7MWh/D0Zxc+69X +ufX5xJKLMUZiYZazEXFiQBDHg8EgQIAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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: Fri, 20 Sep 2013 06:47:47 -0000

+1

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Suhas Nandakumar
Sent: 20. syyskuuta 2013 1:25
To: Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] m=section recycling and a=mid

+1

On Thu, Sep 19, 2013 at 3:23 PM, Harald Alvestrand <harald@alvestrand.no<mailto:harald@alvestrand.no>> wrote:
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<mailto:suhasietf@gmail.com>]
Sent: Thursday, 19 September 2013 9:48 PM
To: Christer Holmberg
Cc: rtcweb@ietf.org<mailto: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<mailto:rtcweb@ietf.org>

https://www.ietf.org/mailman/listinfo/rtcweb


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