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

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 17 February 2017 08:27 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 B58A4129528 for <mmusic@ietfa.amsl.com>; Fri, 17 Feb 2017 00:27:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 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, URIBL_BLOCKED=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 hj0UDe1L3GTe for <mmusic@ietfa.amsl.com>; Fri, 17 Feb 2017 00:27:47 -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 B621F128B37 for <mmusic@ietf.org>; Fri, 17 Feb 2017 00:27:46 -0800 (PST)
X-AuditID: c1b4fb30-2868b98000002c77-f6-58a6b400190a
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by (Symantec Mail Security) with SMTP id C0.3F.11383.004B6A85; Fri, 17 Feb 2017 09:27:45 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0319.002; Fri, 17 Feb 2017 09:27:43 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Taylor Brandstetter <deadbeef@google.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections
Thread-Index: AQHSiMV0wsnKqkRmGEuVhuugjvh/xaFs3Maw
Date: Fri, 17 Feb 2017 08:27:42 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4C0051A7@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>
In-Reply-To: <CAK35n0anO17UVUda+CvgB0cQpbTzjme7gP0cmGBTyqNJqTqmGQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGbHdRpdxy7IIg993OCwur3jIajF1+WMW ixUbDrA6MHv8ff+ByWPBplKPJUt+MgUwR3HZpKTmZJalFunbJXBl3Pyzia3gnF7F3AUfmRoY t+h2MXJySAiYSGz495sdxBYSWMcosf2HURcjF5C9mFGi9eIixi5GDg42AQuJ7n/aIDUiAqES K2+3MYHYzAIqEq9OX2YFsYUFQiT6J8wFKwep2XKkEqLcSKLt6X5GEJtFQFVidudhsFZeAV+J 2fd3skCsusok8blrHwtIL6dAoMTr/ekgNYwCYhLfT62BWiUucevJfCaIkwUkluw5zwxhi0q8 fPyPFcJWklh0+zMTyBhmAU2J9bv0IVoVJaZ0P2SHWCsocXLmE5YJjKKzkEydhdAxC0nHLCQd CxhZVjGKFqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIERszBLb8NdjC+fO54iFGAg1GJh7dg39II IdbEsuLK3EOMEhzMSiK8whuXRQjxpiRWVqUW5ccXleakFh9ilOZgURLnNVt5P1xIID2xJDU7 NbUgtQgmy8TBKdXA2GneXmBiPnvVnKlvZQ3+/w46mS8jIXOF+Wf0j4XL/l19Hmu1c8kPg1mf +v6+E5HrfRi1YHvF+fV//rz37xGY9bIktVn2VPzcTQ/+TV6qYDVDZNOqCz23dGKKvqYJ9F8y u6q0Qi43+lhEd3P64iq/O6vkxTnPXp3CwC/46dW34EP3d01bpmOyzU6JpTgj0VCLuag4EQDu gK+qlAIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/WM5OUxb3d6Be6EFsEKoD199C19s>
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: Fri, 17 Feb 2017 08:27:49 -0000

Hi,

>> 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 am sure it could be done. The question is what (if any) specifications that would have to be updated.

Regards,

Christer


On Thu, Feb 16, 2017 at 3:50 PM, Paul Kyzivat <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] *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

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic