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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 16 February 2017 23:50 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 9D09612947C for <mmusic@ietfa.amsl.com>; Thu, 16 Feb 2017 15:50:57 -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 jFBZ55wuC8xx for <mmusic@ietfa.amsl.com>; Thu, 16 Feb 2017 15:50:56 -0800 (PST)
Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (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 5B8F21293DA for <mmusic@ietf.org>; Thu, 16 Feb 2017 15:50:56 -0800 (PST)
Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-04v.sys.comcast.net with SMTP id eVoWcb0uSxUJaeVp8cybaU; Thu, 16 Feb 2017 23:50:54 +0000
Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-12v.sys.comcast.net with SMTP id eVp7cNPhsL4A9eVp8c2Yjv; Thu, 16 Feb 2017 23:50:54 +0000
To: Christer Holmberg <christer.holmberg@ericsson.com>, IETF MMUSIC WG <mmusic@ietf.org>
References: <CABcZeBP-XL9snCaghp5Hxn5pNxpmSSodWd93Qa-hCL8yDi97gw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4C0045CB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0045FE@ESESSMB209.ericsson.se>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <d76c840d-e2cd-5d04-45d8-d66a7a576aab@alum.mit.edu>
Date: Thu, 16 Feb 2017 18:50:53 -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: <7594FB04B1934943A5C02806D1A2204B4C0045FE@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfCC1tGJg5GdWDvPHjbpaJszXLST2VE4xioJxWH8kJGs6QBY4kWvi4JChj5xFkUtTIN5CofGjdayOG6fdN1Z/VAmq7stDOICwgqwicytuCKzOR+13l2vW ADNgQlA6GFxu1q7Hcu64U4U2fqrfNA6mIMMfdjHEDqxOmN3QwG/k/mOcILTH3oqqhadhBU5rTsYId6SRBMOpIeexSbTgwl/j5U5NRxeABSNf/TpgMV17rxqS
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/A9rWnUCuTyyWefq0V6V_NIKx0oo>
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: Thu, 16 Feb 2017 23:50:57 -0000

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] *On Behalf Of *Christer
> Holmberg
> *Sent:* 16 February 2017 19:07
> *To:* Eric Rescorla <ekr@rtfm.com>om>; mmusic WG <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/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
>