Re: FW: Issue #27: Allow RTP attributes in non-media m= sections
Eric Rescorla <[email protected]>
| Newsgroups | gmane.ietf.mmusic |
|---|---|
| Message-ID | <CABcZeBNg3cO-ACm9M+sF78mjezzvznHqQ5rKeTjGcYm5O3JXAg@mail.gmail.com> |
Yes, I think we do On Mon, Feb 27, 2017 at 5:10 AM, Christer Holmberg < [email protected]> wrote: > Hi, > > 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. > > Regards, > > Christer > > From: Eric Rescorla <[email protected]> > Date: Sunday 19 February 2017 at 00:28 > To: "[email protected]" <[email protected]> > Cc: Christer Holmberg <[email protected]>, Taylor > Brandstetter <[email protected]>, "[email protected]" <[email protected]> > > 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 <[email protected]> > wrote: > >> On 2/18/17 1:45 PM, Eric Rescorla wrote: >> >>> >>> >>> On Sat, Feb 18, 2017 at 8:09 AM, Paul Kyzivat <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> On 2/18/17 4:35 AM, Christer Holmberg wrote: >>> >>> 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... >>> >>> >>> 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 (https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux- > attributes-16) 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. > > -Ekr > > 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. >> >> Thanks, >> Paul >> >> -Ekr >>> >>> >>> Thanks, >>> Paul >>> >>> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:[email protected] >>> <mailto:[email protected]>] >>> Sent: 17 February 2017 18:51 >>> To: Taylor Brandstetter <[email protected] >>> <mailto:[email protected]>> >>> Cc: Christer Holmberg <[email protected] >>> <mailto:[email protected]>>; IETF MMUSIC WG >>> <[email protected] <mailto:[email protected]>> >>> 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 >>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] >>> >>> <mailto:[email protected]>>> 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:[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>>] *On Behalf Of *Christer >>> Holmberg >>> *Sent:* 16 February 2017 19:07 >>> *To:* Eric Rescorla <[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>>>; mmusic >>> WG <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> >>> *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/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> >>> <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 >>> [email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>> https://www.ietf.org/mailman/listinfo/mmusic >>> <https://www.ietf.org/mailman/listinfo/mmusic> >>> <https://www.ietf.org/mailman/listinfo/mmusic >>> <https://www.ietf.org/mailman/listinfo/mmusic>> >>> >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/mmusic >>> <https://www.ietf.org/mailman/listinfo/mmusic> >>> >>> >>> >> > _______________________________________________ mmusic mailing list [email protected] https://www.ietf.org/mailman/listinfo/mmusic