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

Paul Kyzivat <pkyzivat@alum.mit.edu> Sat, 18 February 2017 21:38 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 0AEBB129622 for <mmusic@ietfa.amsl.com>; Sat, 18 Feb 2017 13:38:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
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 bILDaCPpEwl1 for <mmusic@ietfa.amsl.com>; Sat, 18 Feb 2017 13:38:33 -0800 (PST)
Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BAAC129621 for <mmusic@ietf.org>; Sat, 18 Feb 2017 13:38:33 -0800 (PST)
Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by resqmta-po-08v.sys.comcast.net with SMTP id fChecosxJq9PlfCi8cPAHW; Sat, 18 Feb 2017 21:38:32 +0000
Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-04v.sys.comcast.net with SMTP id fCi7cgTRB4o4TfCi8cjK8E; Sat, 18 Feb 2017 21:38:32 +0000
To: Eric Rescorla <ekr@rtfm.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>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <7df97f84-613d-2f5c-2290-aca82621f5ba@alum.mit.edu>
Date: Sat, 18 Feb 2017 16:38:31 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <CABcZeBO960r4oJmaE9LG9KFWO=+iF+3pCv7Gz7dpKiZO+v3OsA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfLTFpI5xfSPQZ/UR5Ze4CePAW/sU3/6Y/oeHSis3tnNCFbE+ejE/AbLn+7txVMnG9i0z/Qo3XzHSZ6S1Xm+vCyxY9egAIGIfaioraP0mRzKkwr1CcL1R UwyZDyE33vyU7Cwc8Y61mcEq0NfpIvOGIlc3TPjHvOh8I/wzrv1xal2nMwC/PeQQuaX4Wu6ZtAIa7vY2Oe/5+ES8SDJdQ5WSwjhq6PIwG0pLY7fbQ1Drqc9N ECrlBQs+xSYqc8WJbhoOpHIKdukKYI+kVlI6HzASac0=
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/HjoeRpnctK0YEh5SD05QNVlvFNU>
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 21:38:35 -0000

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.

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.

>     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>
>
>