[MMUSIC] 10 BUNDLE questions

Justin Uberti <juberti@google.com> Fri, 15 March 2013 20:51 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 826DF21F86A8 for <mmusic@ietfa.amsl.com>; Fri, 15 Mar 2013 13:51:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.975
X-Spam-Level:
X-Spam-Status: No, score=-102.975 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 0S3XwgL0OinB for <mmusic@ietfa.amsl.com>; Fri, 15 Mar 2013 13:51:34 -0700 (PDT)
Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4243321F8667 for <mmusic@ietf.org>; Fri, 15 Mar 2013 13:51:34 -0700 (PDT)
Received: by mail-qe0-f44.google.com with SMTP id x7so2193332qeu.17 for <mmusic@ietf.org>; Fri, 15 Mar 2013 13:51:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=/Jjr1T/FoPPcc7Bj6D6uVYJuQPta/69lZgoEn3edFIo=; b=cdr1ndzlZ+ICF3qW9G5X9jC7vEG2OdkkS68uOoCLXw4cN9dUAJZBPBE1Ss9eOKta+q Tz+t4AgKTm/2z3SHaY0REQ7ao7YS42kZLJcsWaLbNBcYua/xBkvarHoBCyNVaWl+B1i8 et0b99uISGt4Xfp7x0zJeDJqJ26K8llGfZdrugwyEtyZJa88xsf/0kNSLXvdEB17n6ip 0ptD9F3S8NrfkoipjvOD9KbVJrGr5BqMvKW1AMVIgtlx98bpL6KTJ1YqCXSaR+jUH+px 5b3WYmQ7hfbtY1z0GQ67y9gDTi21gxGnVvhQY8rvjch/X33HLLOHjucKEg4hgLoKRz6T Q2rw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=/Jjr1T/FoPPcc7Bj6D6uVYJuQPta/69lZgoEn3edFIo=; b=RGDuE2FxkMhWyVRv0SjbwWSFz67Tr5gYHZwipvWPwxV0AEi4xqHfobplDehSCyOVDL kXll0/kHTU2p6DnziJyD8djxSzrwAAgPuQCPIiNTODlaNF8A2Nr6VyNN/uk6Ql9mFvrU 36MiOXqMI5tXaKnKRy60Gq8BqCTXOZc7KsQiLpj5ycUFM7CiCgm9MTCK3b5U060oEuA+ KekW+F3BzxjdTRs7HyBdvNn2mOBT/Zj0jjWMCvgzNzsQDAsHdrUPqEKvX9ZeLGIleXy5 CEXi66bvG2kzxoyrC3MK+R9Qu3FP8lCSweZthNeYj7qR1HENK7VOpjNljAQUH82zQcNq z/WA==
X-Received: by 10.224.176.70 with SMTP id bd6mr7954347qab.26.1363380687863; Fri, 15 Mar 2013 13:51:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.138.3 with HTTP; Fri, 15 Mar 2013 13:51:04 -0700 (PDT)
From: Justin Uberti <juberti@google.com>
Date: Fri, 15 Mar 2013 13:51:04 -0700
Message-ID: <CAOJ7v-0tr6_HAPwOnLD_De-LkNCsj1EfLhZL=G_B=k5tz9Hkwg@mail.gmail.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary=20cf302ef790981d5904d7fccd89
X-Gm-Message-State: ALoCoQnHTQ1sEA6pPDgiUdKyV93tQAs/YoWVZ61U+PFGlSIQsfyAOl/75ahzm08pwU5cWaaA/rLx7N5s1v4lluHPh/8FrQU17T78Gx1OiVgV2zVOEL6m447wVDgLPRk8NuE7A0UANbVvNr07T/EzGIxVnx0gUplOVZFKC7QgxBYH7BJsegB9ew8Cdk2awcxY8Sj7wDyDcWTO
Subject: [MMUSIC] 10 BUNDLE questions
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, 15 Mar 2013 20:51:40 -0000

The list below is a set of questions (some marked as OPEN ISSUE already)
regarding the new BUNDLE proposal. If you agree with my suggested answers,
I'm willing to contribute text accordingly.

   1. Can you create a BUNDLE with a single m= line? (assuming yes)
   2. Can you create multiple BUNDLEs? (assuming yes)
   3. When creating an initial offer, how should we deal with the case
   where a "null" port is to be used with trickle ICE (since 6.1:1 indicates
   the ports MUST be different)
   4. From 6.1, list 1 - are conditions 2, 5, 7 really necessary? (MUST use
   same c=, add rtcp-mux, same a=fingerprint)
   5. From 6.1, list 2 - is condition 6 right? Why would we use different
   SDES keys for a single RTP session?
   6. If you start with a m= line with one SDES config (e.g. 32-bit MAC),
   and then BUNDLE with another SDES line with a different (non overlapping)
   SDES config (e.g. 80-bit MAC), what happens? (assume fail)
   7. If the BUNDLE mids in the answer doesn't match the BUNDLE mids in the
   offer, what happens? (assume fail)
   8. If you add a m= line to an existing BUNDLE, can the recipient reject
   that BUNDLEing (assume no)
   9. If m= lines are rejected, should their mids show up in the BUNDLE
   answer? (assume yes?)
      1. If not, how does remote side indicate BUNDLE support if it rejects
      the m= lines that are BUNDLEd?
   10. Is there any way, in a single PeerConnection, to unBUNDLE m= lines
   that were previously BUNDLEd (assume no)