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

Christer Holmberg <> Wed, 15 March 2017 11:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11855129BAB for <>; Wed, 15 Mar 2017 04:17:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1diXdUUcvH7B for <>; Wed, 15 Mar 2017 04:17:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31076129B5D for <>; Wed, 15 Mar 2017 04:17:30 -0700 (PDT)
X-AuditID: c1b4fb30-25b3698000007738-03-58c922c81bf7
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id B5.47.30520.8C229C85; Wed, 15 Mar 2017 12:17:28 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Wed, 15 Mar 2017 12:17:26 +0100
From: Christer Holmberg <>
To: Eric Rescorla <>
CC: Paul Kyzivat <>, Taylor Brandstetter <>, IETF MMUSIC WG <>
Thread-Topic: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections
Thread-Index: AQHSiMV0wsnKqkRmGEuVhuugjvh/xaFtWdeAgAEo62CAAF3NgIAAK2mAgAAwa4CAAA3rAIANq1KA///01ACAGREAAA==
Date: Wed, 15 Mar 2017 11:17:26 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D4EEEFE619C62christerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUyM2J7lO4JpZMRBisuq1hcXvGQ1WLF63Ps FlOXP2axWLHhAKsDi8ff9x+YPBZsKvVYsuQnk8fkx23MASxRXDYpqTmZZalF+nYJXBnHP6xm K2h8wFTxZHtkA2P3bKYuRk4OCQETiV2LbrF0MXJxCAmsY5TYt+EIO4SzmFHiyuvzrF2MHBxs AhYS3f+0QRpEBBQkfv05wQISZhYol9gxQR8kLCwQIjF/SgcjSFhEIFRiy5FKiOosid0rNrCD 2CwCqhLbZy5gAbF5Bawlbl1vYIbYdIhNYuWL22AJToFAiSstD8BuYxQQk/h+ag2YzSwgLnHr yXyomwUkluw5zwxhi0q8fPyPFcQWFdCTWP58DVRcSeLHhktQZyZI7FsZAbFXUOLkzCcsExhF ZyGZOguhahaSKogSA4n35+YzQ9jaEssWvoay9SU2fjnLCGFbS+zetZgNWc0CRo5VjKLFqcVJ uelGRnqpRZnJxcX5eXp5qSWbGIGRenDLb4MdjC+fOx5iFOBgVOLhLWA9ESHEmlhWXJl7iFGC g1lJhNdD5mSEEG9KYmVValF+fFFpTmrxIUZpDhYlcV6zlffDhQTSE0tSs1NTC1KLYLJMHJxS DYysy5d/XtqmPOMa8+75OmcKTXcf57nREyGwIvUcq5vW+x3F64sUk24v0085U8/fbG7+LvDv 8n33Z+/6kXsu6oRnTFrIL4EDF2epTRT4nfvs+Nwz/KvOd730vRGcG/XWuEw57++RMobHe6/O 4nqe3vqzTHPT1N+Ljp3WFrPVuFYcc2jdg9ulhTkeSizFGYmGWsxFxYkA4V9LgdACAAA=
Archived-At: <>
Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Mar 2017 11:17:34 -0000


Nobody has objected to this, so assuming we are moving forward with this I am not sure there is anything to discuss in Chicago?



From: Eric Rescorla <<>>
Date: Monday 27 February 2017 at 16:32
To: Christer Holmberg <<>>
Cc: "<>" <<>>, Taylor Brandstetter <<>>, "<>" <<>>
Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections

Yes, I think we do

On Mon, Feb 27, 2017 at 5:10 AM, Christer Holmberg <<>> wrote:

Do people think we need to discuss this face-to-face in Chicago? Note that I have currently NOT requested agenda time for BUNDLE.

As far as document changes are concerned, we would AT LEAST need some clarification text in BUNDLE and/or draft-mux-attributes.



From: Eric Rescorla <<>>
Date: Sunday 19 February 2017 at 00:28
To: "<>" <<>>
Cc: Christer Holmberg <<>>, Taylor Brandstetter <<>>, "<>" <<>>

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

On Sat, Feb 18, 2017 at 1:38 PM, Paul Kyzivat <<>> wrote:
On 2/18/17 1:45 PM, Eric Rescorla wrote:

On Sat, Feb 18, 2017 at 8:09 AM, Paul Kyzivat <<>
<<>>> wrote:

    On 2/18/17 4:35 AM, Christer Holmberg wrote:


        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.

Yes, and so it doesn't matter which one they are attached to.

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.

Huh? We already have a document that analyzes every single attribute and tells you how it
is to be handled ( and
tells you how to hoist stuff from one m= line to all of them. And we're already handling
it that way if the m= line associated with the bundle tag is a media section. The only
difference is how it's handled if it's a data section.


    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.






        -----Original Message-----
        From: Paul Kyzivat [<>
        Sent: 17 February 2017 18:51
        To: Taylor Brandstetter <<>
        Cc: Christer Holmberg <<>
        <<>>>; IETF MMUSIC WG
        <<> <<>>>
        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
            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
            attributes to appear in m= sections with proto values not
            used with those attributes.

        I will reserve judgement until I see specific text.


            On Thu, Feb 16, 2017 at 3:50 PM, Paul Kyzivat
            <<> <<>>

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

                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
                of the "RTP-related" attributes to see if they make a
                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
                would also be needed. But then they would not be used as
                attributes. Instead, they would be dcsa attributes.


                    *From:*mmusic [<>
            <<>>>] *On Behalf Of *Christer
                    *Sent:* 16 February 2017 19:07
                    *To:* Eric Rescorla <<>
            <<>> <<>
            <<>>>>; mmusic
                    WG <<> <<>>
            <<> <<>>>>

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


                    * *





                        The basic issue is that it's possible to have a
                        where you

                    have both

                        media and data m= sections but the BUNDLE tag is
                        with the data

                        m= section and now you need to put the TRANSPORT and

                        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=


                        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
                    that of course means they have to be added to every
            RTP m= section.



                mmusic mailing list
      <> <<>>
            <<> <<>>>

    mmusic mailing list<> <<>>