Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections

Eric Rescorla <ekr@rtfm.com> Mon, 27 February 2017 14:33 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 E124C12A022 for <mmusic@ietfa.amsl.com>; Mon, 27 Feb 2017 06:33:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=0.001] 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 svrDOK684Ob7 for <mmusic@ietfa.amsl.com>; Mon, 27 Feb 2017 06:33:43 -0800 (PST)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 89C98129F57 for <mmusic@ietf.org>; Mon, 27 Feb 2017 06:33:35 -0800 (PST)
Received: by mail-yw0-x22a.google.com with SMTP id l138so12512497ywc.0 for <mmusic@ietf.org>; Mon, 27 Feb 2017 06:33:35 -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=pfW3zuIXZbFDaA1TrvzjOgGGicOmsOTdT/+B13KfX9U=; b=aHg2m0TYVBUKuEiTWwmMN8h88UiEQtT4a0ufMDXQYzztr/+uqlk+I9VpiPWHPSjO2F ERcb9AQDgL4BT9bTXJvT0deknXPdfTnga+rgOdbaw69mAfLh/mgQtzTAwHAxv6OZ0pw9 FCONArxfiO9Mq/nvh/fGdTcYdzFHiiIaFgSvTGAfNwYaTZbPGeuypWqSZmAyZjeOf68q pzGuMQn2hvkHZ5jBgDnOlJNkKQV5ghYUmnfQTfB/V5eohOAX2lhRGkqSbKtxRq9v+1N1 a3puYrOmjhLNtdmfwoUX8MG/lpxSCxGNkybukv0Nn2iQTbwQqZOKRceUS6ZfXRPYNbPk ysVg==
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=pfW3zuIXZbFDaA1TrvzjOgGGicOmsOTdT/+B13KfX9U=; b=OczAIk9ZOouYoj4jZK0YHBvkyXCSZouH2fw8Hy+KBsF4v3g7HrP7tZYkF13czoxcJS TzxMufUpxvAWOWNfW64R5QHqJvE06+2zgq4A2Wz8IxLY/zU8rBHdQladXjovo3OIqAIP vVAt5bsd8LcPhXwyuZRAVwezWcowyzt/U9NmGOZhLZeEgB6b7y1hFMkodd3JVNuXXJPM zUmbeflTNxbx6sPr7X08sLIH7xMkuomho/hH8G31TvBoM7/TP92MzBEqAVk8MwufAhb/ WpZY5SLfdAAExIUgQpvKpzslwYJkDPb6BlobRYBOTtqcVTkBcPUeFkVW+WH7UxwFF1be nMUQ==
X-Gm-Message-State: AMke39nzfouQKSnpc+8tzrBQ+bavXKpr70ncpsPQbfG8AGoWncxC0ykAhXBMY0Y3de3cjBk9TPlyCWs/Uwq2SA==
X-Received: by 10.37.224.81 with SMTP id x78mr11292591ybg.80.1488206014626; Mon, 27 Feb 2017 06:33:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.154.210 with HTTP; Mon, 27 Feb 2017 06:32:54 -0800 (PST)
In-Reply-To: <D4D9F202.18680%christer.holmberg@ericsson.com>
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> <CABcZeBO960r4oJmaE9LG9KFWO=+iF+3pCv7Gz7dpKiZO+v3OsA@mail.gmail.com> <7df97f84-613d-2f5c-2290-aca82621f5ba@alum.mit.edu> <CABcZeBMWexaQ37-TOC-6efSCFmXjDOaf2t6Lhzep+X1+gcy5UQ@mail.gmail.com> <D4D9F202.18680%christer.holmberg@ericsson.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 27 Feb 2017 06:32:54 -0800
Message-ID: <CABcZeBNg3cO-ACm9M+sF78mjezzvznHqQ5rKeTjGcYm5O3JXAg@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary=94eb2c087358daec0a054983f683
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/RJFzkYUuc4zDFHS-4Ew1QWqcViA>
Cc: IETF MMUSIC WG <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
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: Mon, 27 Feb 2017 14:33:50 -0000

Yes, I think we do

On Mon, Feb 27, 2017 at 5:10 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
> Do people think we need to discuss this face-to-face in Chicago? Note that
> I have currently NOT requested agenda time for BUNDLE.
>
> As far as document changes are concerned, we would AT LEAST need some
> clarification text in BUNDLE and/or draft-mux-attributes.
>
> Regards,
>
> Christer
>
> From: Eric Rescorla <ekr@rtfm.com>
> Date: Sunday 19 February 2017 at 00:28
> To: "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>
> Cc: Christer Holmberg <christer.holmberg@ericsson.com>om>, Taylor
> Brandstetter <deadbeef@google.com>om>, "mmusic@ietf.org" <mmusic@ietf.org>
>
> Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m=
> sections
>
>
>
> On Sat, Feb 18, 2017 at 1:38 PM, Paul Kyzivat <pkyzivat@alum.mit.edu>
> wrote:
>
>> On 2/18/17 1:45 PM, Eric Rescorla wrote:
>>
>>>
>>>
>>> On Sat, Feb 18, 2017 at 8:09 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
>>> <mailto: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.
>>>
>>
>> They are supposed to span all the m-lines in the bundle that it is
>> meaningful for them to be used with.
>>
>
> Yes, and so it doesn't matter which one they are attached to.
>
>
> The closest thing we currently have to this situation is session-level
>> attributes. Some of those are defined as valid at both session and media
>> level, and that the value at session level is a default for media level.
>> These in some sense need to be evaluated in the context of every m-line,
>> even the ones where they aren't defined.
>>
>> But we have no standard rule for these. Every attribute needs to say if
>> it is defined at session level and if that should be treated as a default
>> for a value at media level. And in the process it is specifying (at least
>> implicitly) which m-lines it applies to.
>>
>> In principle this could also be done for all the attributes that are to
>> be identical in bundles. But that means making all the changes to do that,
>> and maintain it in the future.
>
>
> Huh? We already have a document that analyzes every single attribute and
> tells you how it
> is to be handled (https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-
> attributes-16) and
> tells you how to hoist stuff from one m= line to all of them. And we're
> already handling
> it that way if the m= line associated with the bundle tag is a media
> section. The only
> difference is how it's handled if it's a data section.
>
> -Ekr
>
>     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.
>>>
>>
>> Again, maybe it is possible to craft some words that clearly and
>> precisely state how this is to work, in a general way without taking it one
>> attribute at a time. But I want to see them.
>>
>> Then we can discuss whether that is simpler than what I suggested above.
>>
>>         Thanks,
>>         Paul
>>
>> -Ekr
>>>
>>>
>>>             Thanks,
>>>             Paul
>>>
>>>
>>>         Regards,
>>>
>>>         Christer
>>>
>>>         -----Original Message-----
>>>         From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu
>>>         <mailto:pkyzivat@alum.mit.edu>]
>>>         Sent: 17 February 2017 18:51
>>>         To: Taylor Brandstetter <deadbeef@google.com
>>>         <mailto:deadbeef@google.com>>
>>>         Cc: Christer Holmberg <christer.holmberg@ericsson.com
>>>         <mailto:christer.holmberg@ericsson.com>>; IETF MMUSIC WG
>>>         <mmusic@ietf.org <mailto: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>
>>>             <mailto: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>
>>>                     <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> <mailto:ekr@rtfm.com
>>>             <mailto:ekr@rtfm.com>>>; mmusic
>>>                     WG <mmusic@ietf.org <mailto:mmusic@ietf.org>
>>>             <mailto: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/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>
>>>                         <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>
>>>             <mailto:mmusic@ietf.org <mailto:mmusic@ietf.org>>
>>>                 https://www.ietf.org/mailman/listinfo/mmusic
>>>             <https://www.ietf.org/mailman/listinfo/mmusic>
>>>                 <https://www.ietf.org/mailman/listinfo/mmusic
>>>             <https://www.ietf.org/mailman/listinfo/mmusic>>
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     mmusic mailing list
>>>     mmusic@ietf.org <mailto:mmusic@ietf.org>
>>>     https://www.ietf.org/mailman/listinfo/mmusic
>>>     <https://www.ietf.org/mailman/listinfo/mmusic>
>>>
>>>
>>>
>>
>