Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections
Eric Rescorla <ekr@rtfm.com> Sat, 18 February 2017 18:45 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 CD5FF1295AF for <mmusic@ietfa.amsl.com>; Sat, 18 Feb 2017 10:45:56 -0800 (PST)
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 YQOmUjUGNM2r for <mmusic@ietfa.amsl.com>; Sat, 18 Feb 2017 10:45:55 -0800 (PST)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 0D532128E19 for <mmusic@ietf.org>; Sat, 18 Feb 2017 10:45:55 -0800 (PST)
Received: by mail-yw0-x230.google.com with SMTP id l19so35886546ywc.2 for <mmusic@ietf.org>; Sat, 18 Feb 2017 10:45:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YgdM0KYghY5ndz4JBT+nYCuuuDPHqiKYUrO/P4zD9hE=; b=f4TKDdh/5oQiCC0YjOyrWuB+OHezlsh1H9A9Tp06uH3zvEs+NkAnP5Ubz055h00mp+ dbXGeEcFLhiscnLNwRTojJ27pD6sQgYnirvLQtlPa71VFjQz39Xtu9t7OBISSQxyzPpD IMlbJNT19RbiUtB3CsSmR9W4z69ko4AVDsc/uTVK+V6OymHgznAYcXHYsJnogldG7OpL CXEdGaHaiwYSrm7tGLv5dlvoWceD/ccvSWixO72gK6Ejehb3QSbNAj0fE6HNrW5xASOw qgG14By1qFmSIZYNi/dIb4EwUBXDI9c7urC1FblGKaoW9qGmMxRLLBu/0FHa+4Qn0GC8 nEPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YgdM0KYghY5ndz4JBT+nYCuuuDPHqiKYUrO/P4zD9hE=; b=OEACxtKajE+9+tKBY7uW5tDkgUL0Az4tP01bBiVwsoj/snatG57++djaIDYAmVMV+U m7WYjW3WM2I6kK17cgfLSMc3uh/hHbvLKAvZF4+Ghln2NSsarlq/Fns0kCEHz7nxCq8Z 2Sib7ZCmnzpoLWcs2xkxTtlkJauWby6IPaqVZz2NfphtwS4tYPLFop/y8rU6KX71v/4x +7Z+V00jM7mh/0ImzlkgxSdCBNz0U/exP1ZNtJb9lsmu/YqWiY4SZqWeHjjpmDE0Ad9c hZIHCozIWUxDYWnIpPY3Y5inLSP7IPH4w5bfdoTWQWiawCOWPzYL6lRklgb/fXPMkV0T +AeQ==
X-Gm-Message-State: AMke39mjcOY0YOPPcJInOUhZ/fLcEA41Q1OTWRZB02cSI8bDs+H9864fYYi32nE8i6tnppHrH6mJHpBiliARiw==
X-Received: by 10.129.125.84 with SMTP id y81mr10034150ywc.120.1487443554189; Sat, 18 Feb 2017 10:45:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.153.200 with HTTP; Sat, 18 Feb 2017 10:45:13 -0800 (PST)
In-Reply-To: <66341809-4c3e-2989-5039-a3369c0fa503@alum.mit.edu>
References: <CABcZeBP-XL9snCaghp5Hxn5pNxpmSSodWd93Qa-hCL8yDi97gw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4C0045CB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0045FE@ESESSMB209.ericsson.se> <d76c840d-e2cd-5d04-45d8-d66a7a576aab@alum.mit.edu> <CAK35n0anO17UVUda+CvgB0cQpbTzjme7gP0cmGBTyqNJqTqmGQ@mail.gmail.com> <b53cbe73-e36c-de5b-764c-d0d0d022d33a@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4C0076FE@ESESSMB209.ericsson.se> <66341809-4c3e-2989-5039-a3369c0fa503@alum.mit.edu>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 18 Feb 2017 10:45:13 -0800
Message-ID: <CABcZeBO960r4oJmaE9LG9KFWO=+iF+3pCv7Gz7dpKiZO+v3OsA@mail.gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary="001a114928baabf4ea0548d27000"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/bxaG1n-6IvIn8024yiucE4kKYBw>
Cc: IETF MMUSIC WG <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections
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, 18 Feb 2017 18:45:57 -0000
On Sat, Feb 18, 2017 at 8:09 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote: > On 2/18/17 4:35 AM, Christer Holmberg wrote: > >> Hi, >> >> I invite anyone who has a suggestion on text that needs to be >> modified/added/removed to provide a pull request (or send text to the list) >> to do so; in draft-bundle, draft-mux-attributes, and/or any other >> specification... >> > > IMO it doesn't make sense to put attributes on one bundled m-line that > only apply to some other bundled m-line - current or future. > Why? The whole principle is that they are supposed to span all the m= lines. > As an alternative, how about picking the first tag in the bundle attribute > that identifies an m-line of an appropriate type to carry the attribute? > Seems much more complicated to implement and specify. To conserve e-mails, responding to Christer as well here: I don't think we need to update any of the relevant RFCs (other than potentially putting them in some useless Updates: line at the top of the doc). The idea here is that BUNDLE overrides them for cases where it applies. -Ekr > Thanks, > Paul > > > Regards, >> >> Christer >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 17 February 2017 18:51 >> To: Taylor Brandstetter <deadbeef@google.com> >> Cc: Christer Holmberg <christer.holmberg@ericsson.com>; IETF MMUSIC WG < >> mmusic@ietf.org> >> Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= >> sections >> >> On 2/16/17 9:27 PM, Taylor Brandstetter wrote: >> >>> So, to make this work I think it will be necessary to ammend the >>> definitions of the particular attributes to specify this usage. And >>> then future new attributes that pertain to RTP would also need to >>> address this. >>> >>> >>> sdp-mux-attributes already amends the definitions of these attributes, >>> such that a TRANSPORT attribute in m= section "A" can be used for >>> media described by m= section "B". So, I don't see why it couldn't go >>> a step further, and explicitly allow TRANSPORT and IDENTICAL category >>> attributes to appear in m= sections with proto values not normally >>> used with those attributes. >>> >> >> I will reserve judgement until I see specific text. >> >> Thanks, >> Paul >> >> On Thu, Feb 16, 2017 at 3:50 PM, Paul Kyzivat <pkyzivat@alum.mit.edu >>> <mailto:pkyzivat@alum.mit.edu>> wrote: >>> >>> On 2/16/17 12:10 PM, Christer Holmberg wrote: >>> >>> Hi Paul, >>> >>> I assume you have an opinion on this :) >>> >>> The suggestion is to allow RTP-specific parameters (SDP rtcp-mux >>> attributes etc) in non-RTP m= lines (e.g., data channel). >>> >>> >>> This is a nasty issue. >>> >>> The problem with allowing this is: what do these parameters *mean* >>> when so attached? And where do I look to find out? >>> >>> I'm not certain if they are currently permitted or not. AFAIK there >>> is no *general* mechanism for specifying with which proto values a >>> particular attribute may be used. I haven't studied the definitions >>> of the "RTP-related" attributes to see if they make a specific >>> statement about this. My guess is that they don't, but that they >>> only define the meaning in the context of an RTP session. >>> >>> If that is so, perhaps the rule that unknown attributes are to be >>> ignored should apply to those attributes when used with a non-RTP >>> media section. But if that rule were to apply, then we would expect >>> that with O/A the rules for how these attributes in an offer affect >>> what goes in the answer would not apply. I guess that won't be >>> sufficient here. >>> >>> So, to make this work I think it will be necessary to ammend the >>> definitions of the particular attributes to specify this usage. And >>> then future new attributes that pertain to RTP would also need to >>> address this. >>> >>> IMO this is a can of worms. So my opinion is that these should *not* >>> be used with non-RTP m-lines, with or without bundle. >>> >>> Note that data channel is a special case. While we have agreed not >>> to consider it for now, it is possible, in principle, to run RTP >>> over a data channel. If that were defined then these attributes >>> would also be needed. But then they would not be used as media-level >>> attributes. Instead, they would be dcsa attributes. >>> >>> Thanks, >>> Paul >>> >>> *From:*mmusic [mailto:mmusic-bounces@ietf.org >>> <mailto:mmusic-bounces@ietf.org>] *On Behalf Of *Christer >>> Holmberg >>> *Sent:* 16 February 2017 19:07 >>> *To:* Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>>; mmusic >>> WG <mmusic@ietf.org <mailto:mmusic@ietf.org>> >>> *Subject:* Re: [MMUSIC] Issue #27: Allow RTP attributes in >>> non-media m= >>> sections >>> >>> >>> >>> Hi, >>> >>> * * >>> >>> *>*See: >>> >>> https://github.com/cdh4u/draft-sdp-bundle/issues/27 >>> <https://github.com/cdh4u/draft-sdp-bundle/issues/27> >>> >>> >>> https://github.com/rtcweb-wg/jsep/issues/528 >>> <https://github.com/rtcweb-wg/jsep/issues/528> >>> >>> >>> >>> >>> The basic issue is that it's possible to have a situation >>> where you >>> >>> have both >>> >>> media and data m= sections but the BUNDLE tag is associated >>> with the data >>> >>> >>> m= section and now you need to put the TRANSPORT and >>> IDENTICAL >>> >>> >>> attributes somewhere. The JSEP editors discussed this and >>> came to the >>> >>> >>> conclusion that it should go with the BUNDLE tag (i.e., in >>> the data m= >>> >>> section) >>> >>> and that BUNDLE should forbid this, but it requires a change >>> to BUNDLE. >>> >>> >>> >>> >>> Did you mean to say that BUNDLE should NOT forbid this? >>> >>> >>> >>> Based on your GitHub discussion, my understanding is that you >>> want to >>> allow to include RTP-specific parameters (‘rtcp-mux’, ‘rtcp’, >>> ‘rtcp-mux-only’ attributes etc) in the data m= section. >>> >>> >>> >>> To repeat what I said on GitHub: >>> >>> >>> >>> This has been discussed in the past, and the outcome has been to >>> now >>> allow RTP-specific parameters in non-RTP m= sections. >>> >>> >>> >>> A solution would be to simply change the bundle tag when the RTP >>> m= >>> sections are added. >>> >>> >>> >>> …OR, we change the mux category for the RTP-specific parameters. >>> But, >>> that of course means they have to be added to every RTP m= >>> section. >>> >>> >>> >>> Regards, >>> >>> >>> >>> Christer >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org <mailto:mmusic@ietf.org> >>> https://www.ietf.org/mailman/listinfo/mmusic >>> <https://www.ietf.org/mailman/listinfo/mmusic> >>> >>> >>> >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >
- [MMUSIC] Issue #27: Allow RTP attributes in non-m… Eric Rescorla
- Re: [MMUSIC] Issue #27: Allow RTP attributes in n… Christer Holmberg
- Re: [MMUSIC] Issue #27: Allow RTP attributes in n… Eric Rescorla
- Re: [MMUSIC] Issue #27: Allow RTP attributes in n… Christer Holmberg
- Re: [MMUSIC] Issue #27: Allow RTP attributes in n… Taylor Brandstetter
- Re: [MMUSIC] Issue #27: Allow RTP attributes in n… Christer Holmberg
- Re: [MMUSIC] FW: Issue #27: Allow RTP attributes … Paul Kyzivat
- Re: [MMUSIC] FW: Issue #27: Allow RTP attributes … Taylor Brandstetter
- Re: [MMUSIC] FW: Issue #27: Allow RTP attributes … Christer Holmberg
- Re: [MMUSIC] FW: Issue #27: Allow RTP attributes … Paul Kyzivat
- Re: [MMUSIC] FW: Issue #27: Allow RTP attributes … Christer Holmberg
- Re: [MMUSIC] FW: Issue #27: Allow RTP attributes … Paul Kyzivat
- Re: [MMUSIC] FW: Issue #27: Allow RTP attributes … Eric Rescorla
- Re: [MMUSIC] FW: Issue #27: Allow RTP attributes … Paul Kyzivat
- Re: [MMUSIC] FW: Issue #27: Allow RTP attributes … Eric Rescorla
- Re: [MMUSIC] FW: Issue #27: Allow RTP attributes … Christer Holmberg
- Re: [MMUSIC] FW: Issue #27: Allow RTP attributes … Eric Rescorla
- Re: [MMUSIC] FW: Issue #27: Allow RTP attributes … Paul Kyzivat
- Re: [MMUSIC] FW: Issue #27: Allow RTP attributes … Christer Holmberg