IETF Logo Mail Archive

Re: [MMUSIC] Bundle, TURN and Legacy Interop

worley@ariadne.com (Dale R. Worley) Thu, 14 March 2013 19:30 UTC

Return-Path: <worley@shell01.TheWorld.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 339A311E812C for <mmusic@ietfa.amsl.com>; Thu, 14 Mar 2013 12:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.98
X-Spam-Level:
X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 u74LlXrCsPUU for <mmusic@ietfa.amsl.com>; Thu, 14 Mar 2013 12:30:03 -0700 (PDT)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8481711E80BF for <mmusic@ietf.org>; Thu, 14 Mar 2013 12:30:03 -0700 (PDT)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2EJTtmR013201 for <mmusic@ietf.org>; Thu, 14 Mar 2013 15:29:57 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2EJTtnC431040 for <mmusic@ietf.org>; Thu, 14 Mar 2013 14:29:55 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2EJTtPH441735; Thu, 14 Mar 2013 15:29:55 -0400 (EDT)
Date: Thu, 14 Mar 2013 15:29:55 -0400
Message-Id: <201303141929.r2EJTtPH441735@shell01.TheWorld.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: mmusic@ietf.org
In-reply-to: <9F33F40F6F2CD847824537F3C4E37DDF06899CEF@MCHP04MSX.global-ad.net> (andrew.hutton@siemens-enterprise.com)
References: <9F33F40F6F2CD847824537F3C4E37DDF06899CEF@MCHP04MSX.global-ad.net>
Subject: Re: [MMUSIC] Bundle, TURN and Legacy Interop
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, 14 Mar 2013 19:30:04 -0000

> From: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>
> 
> It seems that one of the motivations of the current bundle-03
> proposal is that the first offer is compatible with a legacy device
> and that a second offer is required for bundle (See
> http://www.ietf.org/proceedings/86/slides/slides-86-mmusic-9.pdf).

It seems to me that this is suboptimal from the point of view of
connection establishment.  It's not difficult to arrange an offer that
is compatible with both a legacy endpoint (except for perhaps TURN ICE
candidates for the fallback "constituent" ports) and with a supporting
endpoint.  The essential thing is to have a separate bundle m= line so
you can in effect offer both the bundle and the constituents
simultaneously.

If the offerer discovers that it is talking to a legacy endpoint, it
can update the offer with TURN ICE candidates for the constituent
ports.  (If the offerer doesn't want to have to reoffer for legacy
endpoints, it can preallocate enough TURN candidates.)

The result is that you can establish communication with supporting
endpoints in one offer/answer cycle, and the offerer chooses between
needing a reoffer for legacy endpoints when TURN is required
vs. preallocating enough TURN relays.

I don't see a reason to optimize the offer/answer technique to slow
down connection to supporting endpoints and speed it up for legacy
endpoints.

Dale

v2.23.0 | Report a Bug | By Email