[MMUSIC] bundle-11: Bundle Address Synchronization (BAS)

"Stach, Thomas" <thomas.stach@unify.com> Thu, 09 October 2014 15:08 UTC

Return-Path: <thomas.stach@unify.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF551A1B07 for <mmusic@ietfa.amsl.com>; Thu, 9 Oct 2014 08:08:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.685
X-Spam-Level:
X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham
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 490Lh7VY_4vO for <mmusic@ietfa.amsl.com>; Thu, 9 Oct 2014 08:08:14 -0700 (PDT)
Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id DEADA1A1AFE for <mmusic@ietf.org>; Thu, 9 Oct 2014 08:08:13 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 17C8323F04BB; Thu, 9 Oct 2014 17:08:13 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 17:08:12 +0200
From: "Stach, Thomas" <thomas.stach@unify.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Harald Alvestrand <harald@alvestrand.no>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Thread-Topic: bundle-11: Bundle Address Synchronization (BAS)
Thread-Index: Ac/j0tcu2NruXxDsTEC0KS+v/a6o+A==
Date: Thu, 09 Oct 2014 15:08:11 +0000
Message-ID: <F81CEE99482EFE438DAE2A652361EE121E229227@MCHP04MSX.global-ad.net>
Accept-Language: de-AT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.29.42.225]
Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE121E229227MCHP04MSXglobal_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/r_Qh_8j-FnxScYK1zQlJJ1V_D4Q
Cc: mmusic <mmusic@ietf.org>
Subject: [MMUSIC] bundle-11: Bundle Address Synchronization (BAS)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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, 09 Oct 2014 15:08:16 -0000

Christer, Cullen, Harald, all

Bundle Address Synchronization (BAS) is motivated by almost the same arguments that led to the ICE updated offer/answer in 5245.

Now, at IETF 90 the updated offer/answer procedures for ICE were discussed and the consensus was to change the existing behavior to:
" you do it (i.e. the updated offer/answer) or don't do it, but you indicate in the o/a if you're going to do it. Basically want to have option to never do the updated O/A exchange, with an indication in the signaling that you will not be doing it. Of course can always initiate a new O/A exchange whenever you want to."

I think the same discussion and obviously  its result also applies to BUNDLE and BAS.
Otherwise, if you use BUNDLE together with ICE, the updated offer/answer cycle is back.
If the WG agrees, this would require some additional parameter/attribute in the offer that indicates if BAS will be performed or not.

Some common approach for the updated offer/answer issue might also be justified.
An obvious thought  would be if re-using the same "thing" for ICE and BUNDLE would be appropriate.
... and for CapNeg albeit its lack of deployment
Thoughts

Regards
Thomas