[rtcweb] m=section recycling and a=mid

Suhas Nandakumar <suhasietf@gmail.com> Wed, 18 September 2013 16:44 UTC

Return-Path: <suhasietf@gmail.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 B0C6711E8273 for <rtcweb@ietfa.amsl.com>; Wed, 18 Sep 2013 09:44:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, NO_RELAYS=-0.001]
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 nbw-KlE4pqos for <rtcweb@ietfa.amsl.com>; Wed, 18 Sep 2013 09:44:05 -0700 (PDT)
Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 075C011E826E for <rtcweb@ietf.org>; Wed, 18 Sep 2013 09:44:04 -0700 (PDT)
Received: by mail-wg0-f47.google.com with SMTP id f12so6626556wgh.26 for <rtcweb@ietf.org>; Wed, 18 Sep 2013 09:44:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EpY8t2+aOQjdBXlG5FTbDo4t2LqsB0W59p13q1CYYXU=; b=FqRyzGUxjKEtUl6j1Gg2G7cX0zpff8CTn5c0CTRGnY8hA20syuw9ENcpVBx/CZUpvt +GYBoLO7Jy6kWEPa/jL7FQtF7/YijIPmkadWWNyhBKNBtB9wFL3U9H79cIJw0jjtxicX OvMjbCkMpCRTvFIcXQ//ZHYBWlMkFHAdwuNtgMtt/qgRo+eSPxSxXZFLxu4j9D4AX1II mwgq+IcsmteExq9aPw9IH22Do8J4TahE41ez6A4R3FjPbPbe4WafZJPEMBYi0CZjJ8uK fCwQ9p5T7OBZP/jpgghMWIbAHFvbW7qcRVWpuEJqHd5rMf9iE+nnKpJVoJz9Eqr/gDp5 KGOQ==
MIME-Version: 1.0
X-Received: by 10.194.77.2 with SMTP id o2mr2209790wjw.57.1379522644148; Wed, 18 Sep 2013 09:44:04 -0700 (PDT)
Received: by 10.194.178.231 with HTTP; Wed, 18 Sep 2013 09:44:04 -0700 (PDT)
Date: Wed, 18 Sep 2013 09:44:04 -0700
Message-ID: <CAMRcRGRUufCBRg77DEEcqSvJ8uP2o2HU2GoJ23xu6wKPc9G3zA@mail.gmail.com>
From: Suhas Nandakumar <suhasietf@gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="047d7bfced9c2a08e704e6ab25a3"
Subject: [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: Wed, 18 Sep 2013 16:44:05 -0000

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