Re: [MMUSIC] BUNDLE DISCUSION Q6: Do we always mandate 2 Offer/Answers during session establishment?

Justin Uberti <juberti@google.com> Sat, 07 September 2013 00:15 UTC

Return-Path: <juberti@google.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 1366C21E80C7 for <mmusic@ietfa.amsl.com>; Fri, 6 Sep 2013 17:15:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.561
X-Spam-Level:
X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 0XGy+gkQQLML for <mmusic@ietfa.amsl.com>; Fri, 6 Sep 2013 17:15:03 -0700 (PDT)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAEB21E80BD for <mmusic@ietf.org>; Fri, 6 Sep 2013 17:15:01 -0700 (PDT)
Received: by mail-ie0-f178.google.com with SMTP id f4so8115863iea.23 for <mmusic@ietf.org>; Fri, 06 Sep 2013 17:15:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vcA634xnD5QpUQ99Kc0KZhQNh04szav/3mOlPC9AGOo=; b=eU9nDa0aL4L3t0omYsJ3Qj8bc6tYMIKQaGQEpNQRmmuNS4AhTy4rA4DPByODZEZpDO DcD4a1Yaht/3ixcIh4uanaLMV3We6hRJEnDP2V9/EYzrYBph1gYuF6Fqzgc/VwOVER/I i6SOe737Jfxn1To9ahvIZLVwyBD79SLQx0jflXz06/ju91hUOEfLcCJMTjhNXkf3kfql Qvxoanlw88KaPefBAOt7u+8Gg9KvKWeVQFnogiOKfzzvS5kfKR7qCORd3PL+oAA9K5L6 yWHbkgAWsJa+oZNnP7QeoYmUImwqUI5JZcfhf2Qey7QSrI+Qaek7CaUGYSLDIoCp6Ik0 bLtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vcA634xnD5QpUQ99Kc0KZhQNh04szav/3mOlPC9AGOo=; b=DbUyQUmpQ1nMtBZskswP1dkM1bCU8Vs4zBDfBjKq+Y/IqWxIMJSVPOmsoYvIsOkrO0 9oILYuVfcNobDqiQkDWyYHhKllPdfiq6T/giCFc27F8z0QIDHqB6GarPfbabcsT+c+fD qmdNnypyr8Va+C6mLTu/L1ICtwmcw3KcVymbbYBBYHitiVlrFksyVmwzEIxEutufgwwd JWFbCeVeBc+l1xqlEVllgQprj8Bors8pt9kOgVp2QJtIzg0UxhcuZqcZGHnnmKSqPIYn OdTQsCt/tMQJRLdYbA6x30R+/bAqUN1KV63VC4uetflCd0Ti10D5W1IVw+ncGfAfqdNH 5MkA==
X-Gm-Message-State: ALoCoQkYupm/gftqm7RLw3kS5DeYxAFaPJuSOVYl+/pMXtpc8ljxIt22d4yyNiVF0dW54qma9T5SSQtxVqzOT7f8YrfsNvySyFWmGm+lRl5+6hT305pXIfd/modXb/AmzvNctMT54v+zhB5NgE3OGuNVqFn725ebamfnTU2P8yMGK4CYXG+GvA24PYTiOG9YpuNbqHRCxMOl
X-Received: by 10.50.29.39 with SMTP id g7mr438200igh.16.1378512900946; Fri, 06 Sep 2013 17:15:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.68.45 with HTTP; Fri, 6 Sep 2013 17:14:40 -0700 (PDT)
In-Reply-To: <CABkgnnXBQobdfqVzrr=Mq9P9iDcZN=5TJze+Ld=HpN=iuhp6gQ@mail.gmail.com>
References: <7594FB04B1934943A5C02806D1A2204B1C483C45@ESESSMB209.ericsson.se> <5224F4BB.8000904@alum.mit.edu> <CAOJ7v-20smCmAYG_be_4g2PwDigXKJu+x6yRkAzPXJ_YHWse-Q@mail.gmail.com> <522A27AB.1020102@alum.mit.edu> <CABkgnnWA7n7jy9T7cROTZSKrKAc9jCwb=68Whqt7qvVMgCQ8yA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C499BB7@ESESSMB209.ericsson.se> <CABkgnnXBQobdfqVzrr=Mq9P9iDcZN=5TJze+Ld=HpN=iuhp6gQ@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Fri, 06 Sep 2013 17:14:40 -0700
Message-ID: <CAOJ7v-1gjeD0gfbCOfubbEZo80ZH+p8d5gKO==UdyQx_jjY5bw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="047d7bd758ccc797a304e5c00bb2"
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] BUNDLE DISCUSION Q6: Do we always mandate 2 Offer/Answers during session establishment?
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: Sat, 07 Sep 2013 00:15:04 -0000

That's what I thought we were talking about. This has the benefit that you
don't need to gather STUN/TURN for the other addresses that you know you
are going to discard.

Regarding intermediaries, I expect that even for less-well-provisioned
WebRTC app providers, there typically won't be any intermediaries, at least
none who have access to the signaling traffic.


On Fri, Sep 6, 2013 at 1:09 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 6 September 2013 12:46, Christer Holmberg
> <christer.holmberg@ericsson.com> wrote:
> > If you know that the other end supports BUNDLE, then why can't you
> assign the shared address to each "m=" line already in the FIRST Offer? Why
> assign unique addresses?
>
> Exactly.  That's what I'd do.
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>