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

Taylor Brandstetter <deadbeef@google.com> Fri, 17 February 2017 02:27 UTC

Return-Path: <deadbeef@google.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 7F0B2129400 for <mmusic@ietfa.amsl.com>; Thu, 16 Feb 2017 18:27:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 3Kt6oohZxHhd for <mmusic@ietfa.amsl.com>; Thu, 16 Feb 2017 18:27:57 -0800 (PST)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 96F8D129463 for <mmusic@ietf.org>; Thu, 16 Feb 2017 18:27:57 -0800 (PST)
Received: by mail-qk0-x232.google.com with SMTP id u25so33337130qki.2 for <mmusic@ietf.org>; Thu, 16 Feb 2017 18:27:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KDQ+hcTA2rGMYRTzCOoj9mSlOEW8j7fjnR2xoFiAGq8=; b=MQzwLVC1r3gggH/7wEi9Xb514uAcxLEtFPOrZI0+CR3JcWWp8sZHyb473MMaL1GPoe FfElLeZjYzTrFcS1IgemBUpRdItrAxdPTNgRfYtTr1EHnmtVSLc2Mrzci6FL5/U68aL4 GD9yl3YJjsoxLr1OTPqFj8P4MDttaFRRNu26jpZOPAAXilcP3cVD5SPVbtFuMQKOqrOo 6T4R352wVfNGylk5sj0ppWG1+W+5fumWnBPWvgD9fG16bB837sSfg5WrrrJtP+ToPA3y TFK7fPMuiQ7LZLyD//HHkrVnB3vLHIqIh+SITEGkknApBW7+ksm5XEeJfyUVI4u9NZ5c ctwQ==
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=KDQ+hcTA2rGMYRTzCOoj9mSlOEW8j7fjnR2xoFiAGq8=; b=EtgFuG9bAWLae2Qnvk/ZeV065n51yVHMCKdZprFeJ4ioDxj4vINfhLCOuhffY8ln2o QoeUtUZ7J1x7vN1QENlkyeUFE8bqy0Xc8qDLEmAiRkQw2wFC1nG7zsYuQHZ9MsE9oe8y 2D/TOi1peDDHFC4ouJpKebK7RhnIr96UzP6U8mHacxJFHDUdYq0q/sUovNAw219ZRJC7 MPOoPtOHLYx+Yk8SMQpDzIR7Co0TQidf47WZ+LUOby6P5eLRqKGt0CGuMP45KBIbknYX 3y9379dRrlk7TNdKLOKuB456P7ecm47GTCL52BpdOHkkvcjgS4zg1G6MxVKcZCPl9D4M US+A==
X-Gm-Message-State: AMke39nhC1bRrU83pA0ZvFP8iWF55xpkr6jdgVQP9WFH+f/41VVt6XIdREQOOruwdvnO0I+F42rr8tQ/bJWDh4E7
X-Received: by 10.55.112.7 with SMTP id l7mr5125993qkc.252.1487298476449; Thu, 16 Feb 2017 18:27:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.38.188 with HTTP; Thu, 16 Feb 2017 18:27:56 -0800 (PST)
In-Reply-To: <d76c840d-e2cd-5d04-45d8-d66a7a576aab@alum.mit.edu>
References: <CABcZeBP-XL9snCaghp5Hxn5pNxpmSSodWd93Qa-hCL8yDi97gw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4C0045CB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0045FE@ESESSMB209.ericsson.se> <d76c840d-e2cd-5d04-45d8-d66a7a576aab@alum.mit.edu>
From: Taylor Brandstetter <deadbeef@google.com>
Date: Thu, 16 Feb 2017 18:27:56 -0800
Message-ID: <CAK35n0anO17UVUda+CvgB0cQpbTzjme7gP0cmGBTyqNJqTqmGQ@mail.gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary=001a114fe9885d76900548b0a9f7
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/ip8F4EcONgJRyhcujZZMG4fQFJI>
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: Fri, 17 Feb 2017 02:27:59 -0000

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

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
>