[MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32 (Part I)
Eric Rescorla <ekr@rtfm.com> Sat, 27 August 2016 16:58 UTC
Return-Path: <ekr@rtfm.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 E0BCC12D0CB for <mmusic@ietfa.amsl.com>; Sat, 27 Aug 2016 09:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 Wux9oPyXSq4d for <mmusic@ietfa.amsl.com>; Sat, 27 Aug 2016 09:58:57 -0700 (PDT)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED64F12B008 for <mmusic@ietf.org>; Sat, 27 Aug 2016 09:58:56 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id z8so65466361ywa.1 for <mmusic@ietf.org>; Sat, 27 Aug 2016 09:58:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=lGT4H7FpzWmVdPioiu6TY9b92Doxl8TnHcH8Deg3GIE=; b=O75NrAK8snSlaCGRsoR9GWPIYvWl5G3s651Tt2eIg1rI4pcPiWG5rEidvKF1mNnx+2 zKXZR+eymNjwFG6caXntAKIycRJUM4GkyYUnKqrz+z1OOa8iZIwoAtfIb4kLadEBxYmL D8WfDU0/MLaaMBEdTNCBYck358TPdRUemjwKQTkaAsnNWelJAQL0IA61/TT+RoDd+Ub8 DjMpqqDhlCceg2NtYM6rvj/vISjGw7eiqPUo/7/LkLKY7+IBT0I35i+kxnqenWmcWhNI sFaDWsso/l+TKsUeH8Dr9f7fHNB3imwNWXlZe375JAIASPVkMLjbd4OLt93K9IbnUUcl u2pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=lGT4H7FpzWmVdPioiu6TY9b92Doxl8TnHcH8Deg3GIE=; b=JxMB6ifyD7KDyKQHC6WobCeOlFCsJHsu1JuI2rCTXRNZoSzETdnWoIWGQ195g/OavX jJjIgTWkiwaFMo2GniDQJIhjw84HbtKfzTBk/NcofhRW0PKfnE0f7xRnyqgF9meuKwp2 dKiyDzHG9Q8loo2wC1LzA8Zkqly8ldUKkCfOvukjfk5+LKw5xF+bOyLg9Tn75FxSeSgB Fsj0D1/qkQLXzrD4AH33Dhy+8cb7G907+bN9kMQ15OYH13i7JJret2vGlQKcV3wmcX3M +Vb+UhrsiaXDtQuLqZLHXUiNOu6NpV6MrIodTZM7n1GNgQ02MhxB/t01pXwIcSmHQSC/ 46dg==
X-Gm-Message-State: AE9vXwOD+l93xxW38J7gLMcqqRd/yE7oN95yiPGNhDAH1UkYDK9f4iU5c7vqN9aQEGYux1xONcGHTKMWwKTkBg==
X-Received: by 10.13.221.198 with SMTP id g189mr8281035ywe.93.1472317135907; Sat, 27 Aug 2016 09:58:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.48.193 with HTTP; Sat, 27 Aug 2016 09:58:15 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 27 Aug 2016 09:58:15 -0700
Message-ID: <CABcZeBPpdyxiFbiHsqj=XwxFvOs4=z+R0zK0zoxbpixa25k3zQ@mail.gmail.com>
To: mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0779cee222fb053b108bd7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/gL6-jGZ2tYnSS_ai7J1d97BlBVM>
Subject: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32 (Part I)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 27 Aug 2016 16:58:59 -0000
I have reviewed the first half of this document (up through the examples). The following comments apply only to that. OVERALL The overall framing of this document as being about attaching multiple m= sections to a single "shared address" is extremely problematic, for two reasons: - With ICE there isn't actually any notion of a shared address except in some vague sense. I suppose you could argue that because with ICE you are required to specify a port on the m= line then you still have a concept of an address, but that's not true in trickle ICE, where the port is 9, so all m= lines share the same address/port. So, actually when you use trickle a whole bunch of the statements in this document are wrong. - A lot more is being overloaded here than addresses. In fact, a whole pile of semantics are being overloaded, so the way to think about this is actually as gluing a whole bunch of m= lines together at the transport level. I think the right concept here is not "shared address" but "bundle group" and the document should be written in that way, namely that there are a bunch of m= lines in a bundle group and the one with the bundle tag is the one that sets all the shared parameters. The document is badly in need of some overall framing that explains what we are trying to accomplish and the rationale for why any particular m= section property needs to be the same for all members of a bundle group and why other ones do not. I'm not saying it's necessarily bad to be explicit in (for instance Sections 11 and 12) but it would be better if it were clear where these rules come from. One way to deal with this would be to simply defer this to the mux-attributes draft. I'll just note again that I find the overloading of "associated" makes this document very hard to read. At minimum it would be best to talk about an m= line as "belonging" to a BUNDLE group. If others agree I would be happy to provide a PR that cleans this up. MAJOR TECHNICAL Maybe I missed this, but I don't see any requirement that m= lines appear in the a=group:BUNDLE line in the order they appear in the SDP. That would make life a lot easier. DETAILED COMMENTS (MIXED EDITORIAL/TECHNICAL) S 1. This really needs some explanation of why you would want this feature. S 2; Initial offer. "The first offer, within" . This comma is superfluous. S 5. The first three grafs of this section seem to duplicate the intro and the abstract. Also, this claim about sharing a 5-tuple is not quite right with ICE because ICE can switch 5-tuples during aggressive nomination. S 6. The usage of the 'bundle-only' attribute is only defined for a bundled "m=" line with a zero port value, within an offer. Other usage is unspecified. It would probably be better to actually forbid this, because it seems like an interop problem if you somehow were to introduce it later. S 8. Nit: List the forward references in section order. S 8.1. This seems like a key concept: there are a number of different categories of attributes and some are shared with all members of a bundle group and some are not. To what extent is this draft just duplicative of those listed in the mux-attributes draft? S 8.2 and following Really would be useful to have some examples here to make it less abstract. S 8.3.3. It seems like the implication here is that an answerer cannot debundle something that was bundled in a previous o/a transaction. Can you make that point clearly? S 8.5. How does this interact with ICE Restart? S 8.5.2 When you say "extend" do you mean "add to the end"? S 10.1 In this first bullet is "if" "iff"? S 10.3.1.1. When an offerer generates an initial offer, the offerer MUST associate either an SDP 'rtcp-mux' attribute [RFC5761] or an SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] with each bundled RTP-based "m=" line in the offer. The offerer MUST associate an SDP 'rtcp-mux-only' attribute with each bundle-only "m=" line. If the offerer associates a 'rtcp-mux-only' attribute with an "m=" line, the offerer may also associate a 'rtcp-mux' attribute with the same "m=" line, as described in [I-D.ietf-mmusic-mux-exclusive]. This is a particularly egregious case of associate disease that could be easily solved by using "add" when referring to the attributes you put in the m= section. S 11.1 When an offerer associates a unique address with a bundled "m=" line (excluding any bundle-only "m=" line), the offerer MUST associate SDP 'candidate' attributes (and other applicable ICE-related media-level SDP attributes), containing unique ICE properties (candidates etc), with the "m=" line, according to the procedures in [I-D.ietf-mmusic-ice-sip-sdp]. Here is an example of where the "address" framing doesn't work, if you are using trickle.
- [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-n… Eric Rescorla
- Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bund… Christer Holmberg
- Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bund… Flemming Andreasen
- Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bund… Eric Rescorla
- Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bund… Christer Holmberg
- Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bund… Eric Rescorla
- Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bund… Christer Holmberg
- Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bund… Eric Rescorla
- Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bund… Christer Holmberg
- [MMUSIC] Bundle and "m=" line terminology [Re: Re… Flemming Andreasen
- Re: [MMUSIC] Bundle and "m=" line terminology [Re… Eric Rescorla
- Re: [MMUSIC] Bundle and "m=" line terminology [Re… Christer Holmberg
- Re: [MMUSIC] Bundle and "m=" line terminology [Re… Eric Rescorla
- Re: [MMUSIC] Bundle and "m=" line terminology [Re… Flemming Andreasen
- Re: [MMUSIC] Bundle and "m=" line terminology [Re… Christer Holmberg