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

Christer Holmberg <christer.holmberg@ericsson.com> Sat, 18 February 2017 09:35 UTC

Return-Path: <christer.holmberg@ericsson.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 DE1DE1294F9 for <mmusic@ietfa.amsl.com>; Sat, 18 Feb 2017 01:35:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham 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 lngg4duUiwzj for <mmusic@ietfa.amsl.com>; Sat, 18 Feb 2017 01:35:43 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 1304B1294D3 for <mmusic@ietf.org>; Sat, 18 Feb 2017 01:35:42 -0800 (PST)
X-AuditID: c1b4fb30-e97ff70000002c77-bf-58a8156c4d3d
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id EA.00.11383.C6518A85; Sat, 18 Feb 2017 10:35:41 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0319.002; Sat, 18 Feb 2017 10:35:40 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Taylor Brandstetter <deadbeef@google.com>
Thread-Topic: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections
Thread-Index: AQHSiMV0wsnKqkRmGEuVhuugjvh/xaFtWdeAgAEo62A=
Date: Sat, 18 Feb 2017 09:35:40 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4C0076FE@ESESSMB209.ericsson.se>
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>
In-Reply-To: <b53cbe73-e36c-de5b-764c-d0d0d022d33a@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbHdWzdXdEWEwfOlshaXVzxktZi6/DGL xYoNB1gdmD3+vv/A5LFgU6nHkiU/mQKYo7hsUlJzMstSi/TtErgy5i0/zFKww7HiVc8D1gbG B/ZdjJwcEgImEgdffGbqYuTiEBJYxygxe+YUNghnMaPEvQ2NQBkODjYBC4nuf9ogDSICoRJ/ /t1gA7GZBVQkXp2+zApiCwuESPRPmMsIUg5Ss+VIJUS5lcSH1RPASlgEVCXmPJnHDGLzCvhK bD12FWpVN7PE3F+TGEESnAIOEuv27GQCsRkFxCS+n1rDBLFLXOLWk/lMEEcLSCzZc54ZwhaV ePn4HyuErSSxYvslsBuYBTQl1u/Sh2hVlJjS/ZAdYq+gxMmZT1gmMIrOQjJ1FkLHLCQds5B0 LGBkWcUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGDUHt/w22MH48rnjIUYBDkYlHt4P/Msj hFgTy4orcw8xSnAwK4nwThBYESHEm5JYWZValB9fVJqTWnyIUZqDRUmc12zl/XAhgfTEktTs 1NSC1CKYLBMHp1QDIzOHQoB9R3zSx/ddZy0YLIO6F372525YJ/V2m8i9iQwyqgpfb2eu0fc5 Hr91cu8hxYMvTlZNlfM8w5Dlo93zMeXFx+D1rNoFkwUslpRba0dfWfc0ZvbidUb/DYJz+P6o s37nXyizzNr1iNITuW0xCbb/ve2EIu128yfNmeie/N+w897M4/4vlFiKMxINtZiLihMBLKEs YJYCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/Hab5oZI6kaouDR0NyStVb8CRwhU>
Cc: IETF MMUSIC WG <mmusic@ietf.org>
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 09:35:45 -0000

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

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