Re: [MMUSIC] 10 BUNDLE questions: Is there any way, in a single PeerConnection, to unBUNDLE m= lines that were previously BUNDLEd?

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 25 April 2013 10:57 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DB621F937B for <mmusic@ietfa.amsl.com>; Thu, 25 Apr 2013 03:57:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.107
X-Spam-Level:
X-Spam-Status: No, score=-6.107 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 YWLgAWa6Bh+W for <mmusic@ietfa.amsl.com>; Thu, 25 Apr 2013 03:57:18 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8C90C21F92C0 for <mmusic@ietf.org>; Thu, 25 Apr 2013 03:57:17 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f316d0000028db-f9-51790c0c9a15
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A2.5E.10459.C0C09715; Thu, 25 Apr 2013 12:57:16 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Thu, 25 Apr 2013 12:57:16 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] 10 BUNDLE questions: Is there any way, in a single PeerConnection, to unBUNDLE m= lines that were previously BUNDLEd?
Thread-Index: Ac5BoMU7D+du+vhxRBeyo6SZqShpVw==
Date: Thu, 25 Apr 2013 10:57:15 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C35F1AC@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.20]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+JvrS4PT2WgwbptchZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxr3lR5kK2gQq/j04xtzAeIG/i5GTQ0LARGL643NsELaYxIV7 64FsLg4hgcOMEu3L2pkhnCWMEvMer2LvYuTgYBOwkOj+pw3SICKgLvF1bw8ziC0s0Mso0Xyr GKReRKCPUeLnyiNMEEV6EqvuNrKC2CwCqhIH3m5kBLF5BXwlTt2/ChZnBNr8/dQasHpmAXGJ W0/mM0FcJCCxZM95ZghbVOLl43+sELaixNXpy5lA7mEW0JRYv0sfolVRYkr3Q3aI8YISJ2c+ YZnAKDwLydRZCB2zkHTMQtKxgJFlFSN7bmJmTnq54SZGYBAf3PJbdwfjqXMihxilOViUxHll 2SoDhQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDWt+4Iq8oW8Gg9abL2JVP/oavBK85F8h1O UXh5S87nRvFRh1VTrl9fvr6wml/PVkPFZ9dfgW2fpWffaQivK+uaNtXV6sNqx2Cmy8/yjgQd EzsUXL3VS1Z5erzmkY/C6U2bHx62vCwecPbiPpO3J+c5lM757M06aenvTvYJdfHvY7b+Ef3G 1N6ixFKckWioxVxUnAgAW0TZ6zACAAA=
Subject: Re: [MMUSIC] 10 BUNDLE questions: Is there any way, in a single PeerConnection, to unBUNDLE m= lines that were previously BUNDLEd?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Apr 2013 10:57:18 -0000

Hi,

>10. Is there any way, in a single PeerConnection, to unBUNDLE m= lines that were previously BUNDLEd (assume no)

Well, what is possible to do in a PeerConnection is outside the scope of BUNDLE, but we of course need to decided whether BUNDLE itself allows the "unbundling" of previously BUNDLEd m- lines. 

(In SDP O/A language that would mean sending an offer where the unBUNDLEd m= lines are no longer associated with a BUNDLE group.)

There has been indications that it would be needed for some 3pcc cases.

Others have said that it would mess up things, because you would have to be able to, during the SDP O/A "transition", simultaneously do stuff according to the old (e.g. BUNDLEd) negotiated SDP and the new (e.g. unBUNDLEd) SDP.

Regarding having to be able to do things simultaneously, that is a generic SDP O/A problem, not related to BUNDLE as such. But, of course, BUNDLE increases the things you have to be able to simultaneously handle during the transition. 

But, are existing products really able to do things simultaneously during a transition, or are we discussing things which won't work in real life deployments anyway?

Another suggestion was to, instead of modifying the existing m- lines, simply add new m- lines, representing e.g. the user to whom a call has been transferred.

I think we'll need a little more time to think about this, so won't suggest any conclusion at this point, but instead list it as an OPEN ISSUE.

Regards,

Christer