Re: [MMUSIC] ICE tiebreaker - session-level or media-level?

Marc Petit-Huguenin <petithug@acm.org> Fri, 12 October 2012 13:37 UTC

Return-Path: <petithug@acm.org>
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 79B7D21F855F for <mmusic@ietfa.amsl.com>; Fri, 12 Oct 2012 06:37:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.431
X-Spam-Level:
X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xO6eKjc8WbO for <mmusic@ietfa.amsl.com>; Fri, 12 Oct 2012 06:37:31 -0700 (PDT)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 9650021F854F for <mmusic@ietf.org>; Fri, 12 Oct 2012 06:37:31 -0700 (PDT)
Received: from [IPv6:2601:9:4b80:32:9cd4:c894:b643:d270] (unknown [IPv6:2601:9:4b80:32:9cd4:c894:b643:d270]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 3EEB0204A4; Fri, 12 Oct 2012 13:37:28 +0000 (UTC)
Message-ID: <50781D16.5050804@acm.org>
Date: Fri, 12 Oct 2012 06:37:26 -0700
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.7) Gecko/20120922 Icedove/10.0.7
MIME-Version: 1.0
To: Justin Uberti <juberti@google.com>
References: <CAOJ7v-3P7ym=ASXn-_we6BwBsj3KthzbgY5Vu=+9o-2xSBpuFQ@mail.gmail.com>
In-Reply-To: <CAOJ7v-3P7ym=ASXn-_we6BwBsj3KthzbgY5Vu=+9o-2xSBpuFQ@mail.gmail.com>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] ICE tiebreaker - session-level or media-level?
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: Fri, 12 Oct 2012 13:37:32 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 10/11/2012 11:25 PM, Justin Uberti wrote:
> Reviewing the handling of role conflicts, a question came up: in the event 
> different systems handle different media in a session, do they have to
> share the same ICE tiebreaker?
> 
> Section 5.2 of RFC 5245 indicates that the ICE Agent chooses the
> tiebreaker, indicating that this is a session-level value.
> 
> To resolve this, each agent MUST select a random number, called the
> tie-breaker, uniformly distributed between 0 and (2**64) - 1 (that is, a
> 64-bit positive integer).  This number is used in connectivity checks to
> detect and repair this case, as described in Section 7.1.2.2
> <http://tools.ietf.org/html/rfc5245#section-7.1.2.2>.
> 
> 
> Or am I misreading, and each m= line corresponds to its own ICE Agent, with
> its own tiebreaker value?
> 

Well, it is obvious that ICE was not designed with an Agent per m= line, see
draft-petithuguenin-mmusic-ice-attributes-level.  Work on rfc5245bis will
start after the Atlanta meeting, so this will be a good time to fix this.
Meanwhile, is there any interoperability problem when implementing an ICE
Agent per m= line?

- -- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJQeB0UAAoJECnERZXWan7EWIgP/RLC8qLCwh/kDn4qv5URBRuj
Lt8rVosig9UwsizNW/Quex6WwyepE1pM+eewINMK43grfLgYFMc1gcpxFn1RUj/i
sNzaVd5V3kz0s0DKLv7xsnf/bbt/teZPso2SW4yRGum/Z+tDOwA/mQTS4INZhUUe
6Dm5t0zW9K+Z0OIUjTVJKokzUcFy5DUGQHjWfibrOUkzgQ1ZK2fTtx2RQNCLIzFG
VkMwWXMzO60bDCTNGmYbZQWBLNpu2H4Dc0vqBtYydQPDCJh+ReLPJ3MWxzm6DhfG
76EbSfyUBDyJxfsklSJVrFmyCX2wW+YoLiUCt5yk07vJ1nYM3KhGTWvG4EJ4CR5F
lv/9KOKjEIGQCbH8dncChKvcXHRj0hl0yGzdvaDnvPv0RLjmLSHWAc4JyKXOU1/0
bSXYSAHfdpt79GTw2OQe4gM78GPrplTi6J3DfwN28qiKv7cG7CEXagizGTKJIXzU
q7r1YfyCNSimJjaqeJwBH5MGad+BEbmD6g8+HADh/BLJUgmrlC+oOETuPX893Ia3
djONWWFWNGhXIEj7fB5AmRa9ejXcF+RAUmK1pI2rdZQK616IzDYU0cWpc4uLlrJL
i8S7MPXM9ebFKydB6DcEa6B+MtZ/qwBrQxs7JD4P0ZEM0LpCqGVK62JAeHNt6ygy
2ZPwo64WxOHDRUisHgif
=6WhM
-----END PGP SIGNATURE-----