Draft: draft-ietf-rtcweb-jsep

Commentary: attributes . As far as I can tell this can happen : On re - offers On any answer because nothing requires the offerer to generate bundle tags in the same order as m= lines ( even though the data channel m= line is last ) See : 
 PTAL 
 Say you have a session where only a data channel is created . SDP looks like [ session boilerplate ] a = group : BUNDLE d1 m = X application UDP / DTLS / SCTP webrtc - datachannel a = mid : d1 ... Now , a media m= section is ( i.e. after first o / a ) . SDP becomes : [ session boilerplate ] a = group : BUNDLE d1 a1 m = X application UDP / DTLS / SCTP webrtc - datachannel a = mid : d1 a = ice - ufrag : ABCD ... m = X audio UDP / TLS / RTP / SAVPF 0 a = mid : a1 [ no ice - ufrag or TRANSPORT attrs , since bundled ] Now , where does a = rtcp - mux go ? It ca n't go into because of the language that states  on how to resolve ? 
 Could generating a session description be split into two parts ? First , generate media - level attributes for each " m= " section , then transport - level attributes for the BUNDLE group and each non - bundled " m= " section . 
 That would be my preference , i.e. , jam it into the BUNDLE group m= section , regardless of media type , as that 's conceptually simplest , and easily handled here in JSEP . Either way , I suspect this will require changes upstream in the bundle spec . 
 So ... is it really not allowed in the d1 section . Unknown attributes are allowed in the d1 section , they are just ignored if they have no meaning for the data channel . Agree this sounds like something that will hit bundle . 
 Could n't you do a = group : BUNDLE a1 d1 I would have thought this was prohibited , but is it really ? 
 I think that 's legal , but that approach does n't work in the general case , where " m= " section A has TRANSPORT attributes that only it uses , and section B has TRANSPORT attributes that only it uses . BUNDLE just needs to allow an " m= " section to contain attributes that it normally would n't contain if it was n't bundled . ( If this is n't already allowed ) . 
 any action needed here ? 
 I think what we want in this scenario is to put " a = rtcp - mux " and " a = rtcp - rsize " in the data channel section . The simplest way would be to say : Which I guess could only happen in subsequent offers . 
 Let 's go with what suggests , although this makes it a bundle problem . 
 What would you say is needed on the BUNDLE side ? Just clarification that the offerer BUNDLE - tag m= section should contain the union of all TRANSPORT and IDENTICAL attributes used by the BUNDLE group ? 
 talked to chairs and advice from chairs on this and similar things that depend on mmusic outcomes . We put in JSEP now what our best guess is of how mmusic will end up and publish  . At the same time we log a bug to check if we need to make any changes to line up with what mmusic decides . We can take changes to line up with mmusic as Last Call comments later on . 
 +1 with  proposal to put RTP related things in data m= section if it is first and good with making this be bundles problem 
 I assume that you think that on initial offers this can not happen because data comes last ? 
 Right . I ca n't think of a scenario where it would n't go last in an initial offer . 
 Agreed . 
 Oh , except that you are n't required to make the bundle group in order So you can have 
 I do n't think the question whether you are allowed or not to place an RTP attribute in a non - RTP m= section is a pure BUNDLE issue . One needs to check what the specs defining those attributes say . 
 every SDP spec has to accept ( and ignore ) lines it does not understand ... 
 I looked into the a = rtcp - mux and a = rtcp - rsize specs , and I did n't see anything that prohibited their inclusion into a non - media section . Generally , I think BUNDLE can define the rules for this sort of thing , without fear that it will somehow contradict some other spec . 
 You may want to chime in on the current MMUSIC thread . I agree with you , but it seems to be going in the direction of " you ca n't do this " . 
 I looked into the a = rtcp - mux and a = rtcp - rsize specs , and I did n't see anything that prohibited their inclusion into a non - media section . It may not be explicitly stated , but since the semantics is about RTP and RTCP I think it is implicit . Having said that , I personally have no problem with allowing the attributes in non - RTP m- sections . I just want to verify that there is no text that has to be modified somewhere , and/or whether there is some text that has to be somewhere :) 
 Resolved by 
 Looks good .
Paragraph (version B):
Note that if media m= sections are bundled into a data m= section,
then certain TRANSPORT and IDENTICAL attributes may appear in the
data m= section even if they would otherwise only be appropriate
for a media m= section (e.g., "a=rtcp-mux").  This cannot happen
in initial offers because in the initial offer JSEP
implementations always list media m= sections (if any) before the
data m= section (if any), and at least one of those media m=
sections will not have the "a=bundle-only" attribute.  Therefore,
in initial offers, any "a=bundle-only" m= sections will be bundled
into a preceding non-bundle-only media m= section.
Paragraph (version A):
If a data channel m= section has been offered, a m= section MUST also
be generated for data.  The <media> field MUST be set to
"application" and the <proto> and "fmt" fields MUST be set to exactly
match the fields in the offer.
Paragraph (version B):
If a data channel m= section has been offered, a m= section MUST also
be generated for data.  The <media> field MUST be set to
"application" and the <proto> and "fmt" fields MUST be set to exactly
match the fields in the offer.  Note that if media m= sections are
bundled into a data m= section, then certain TRANSPORT and IDENTICAL
attributes may appear in the data m= section even if they would
otherwise only be appropriate for a media m= section (e.g., "a=rtcp-
mux").