IETF Logo Mail Archive

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

"Stach, Thomas" <thomas.stach@unify.com> Mon, 13 October 2014 08:31 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 4BF1D1A0043 for <mmusic@ietfa.amsl.com>; Mon, 13 Oct 2014 01:31:54 -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 RdyoJxsUlWG1 for <mmusic@ietfa.amsl.com>; Mon, 13 Oct 2014 01:31:52 -0700 (PDT)
Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7F71A02A0 for <mmusic@ietf.org>; Mon, 13 Oct 2014 01:31:52 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 72FE91EB848A; Mon, 13 Oct 2014 10:31:51 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Mon, 13 Oct 2014 10:31:48 +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+AAHL98QAAFETAAAN7eEAAB5Wg4w
Date: Mon, 13 Oct 2014 08:31:47 +0000
Message-ID: <F81CEE99482EFE438DAE2A652361EE121E22A5CD@MCHP04MSX.global-ad.net>
References: <F81CEE99482EFE438DAE2A652361EE121E229227@MCHP04MSX.global-ad.net> <7594FB04B1934943A5C02806D1A2204B1D47124E@ESESSMB209.ericsson.se> <F81CEE99482EFE438DAE2A652361EE121E229362@MCHP04MSX.global-ad.net> <7594FB04B1934943A5C02806D1A2204B1D475A98@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D475A98@ESESSMB209.ericsson.se>
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_F81CEE99482EFE438DAE2A652361EE121E22A5CDMCHP04MSXglobal_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/StwVW2fl7NUCDqDqS888e_kGUhI
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [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: Mon, 13 Oct 2014 08:31:54 -0000

inline

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Freitag, 10. Oktober 2014 23:47
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: Bundle Address Synchronization (BAS)

Hi,

In general, I prefer a negotiation model, rather than the sender indicating that it is going to do something - without the receiver being able to impact that.
[TS] I wouldn't necessarily object to having such a negotiation but it adds complexity.
Apart from the additional complexity, the question to answer in that model however is: "What is the fallback if negotiation fails?"
Is it "do the extra offer/answer" or "omit the additional offer/answer"?
My preference would be omitting. Therefore, I can live quite well with the IETF 90 outcome.
Others might prefer doing the extra offer/answer.

Because, in case of the updated offer (no matter whether it's ICE or BAS), it is often the receiver (or some intermediary) - not the sender - that knows whether it's needed or not.
[TS] Well, the receiver is free to send a new offer anytime. However, I have issues with intermediaries that interfere in such a negotiation.
Consider the case where you have two of them and both have different preferences.

It is the receiver, not the sender, that possible needs the second offer. So, while I agree a negotiation may not be needed, I think we should at least let the receiver decided whether the offerer should send it or not.
[TS] I think it is crucial having this aligned for BUNDLE and ICE.
However, for ICE the consensus on updated offer/answer handling was different and I think it is the better approach.
Both sides, sender and receiver, might have their reasons why they want to send the update or omit the update.
Prescribing what the other end must do can easily conflict with these reasons and lead to unwanted side effects.
Thus I still prefer this approach as discussed in IETF90 "The offerer/sender  says what is does". The sender can then react as it needs.
Regards
Thomas

Regards,

Christer

v2.23.0 | Report a Bug | By Email