Draft: draft-ietf-rtcweb-jsep

Commentary: per seems like answers should now be handled differently : 
 do you know why this change was made ? 
 Assuming I am reading S 8.3.2 of BUNDLE correctly , then you must set the port to 0 . The text seems vague on c= , but I see that it is not present in the examples for the bundled m= sections . Is that correct ? If so , does the text say so somewhere ? 
 The change was based on comments and requests ( including Ekr 's earlier request to get rid of the shared address concept ) that one should not have to repeat the BUNDLE address in multiple m- sections . Therefore , once a BUNDLE group is created , one can now assign the port to only one m- section in both offers and answers . 
 well , I was n't arguing that you should n't repeat the address , just that " shared address " was n't a meaningful way of expressing it . Regardless , can you answer my other question about the c= line ? 
 There were others requesting that the address should n't be repeated . Regarding the c= line , is there a reason why you would want to use media level c= lines with BUNDLE 
 Not particularly , but ordinarily you need a c= line , so I 'm looking for the place where the BUNDLE spec says you do n't . Where is that ? 
 Ok , I think I understand now : you ask for text explicitly saying that a media level c= line must not be assigned to a bundle - only m= section ? Such text does NOT currently exist ( I guess I always assumed that one would use a session level c= line with BUNDLE ) , but we could add it . ( Of course , it would not only apply to bundle - only m= sections in answers , but also in offers . ) 
 Well , JSEP currently says : So probably we actually do need to come down on this . 
 I see no need to include a c= line in a bundle - only m= section , as the whole idea is that the m= section will only be used it becomes part of a BUNDLE group . If people agree , we should clarify that in BUNDLE , and modify the JSEP text above . Maybe something like this could be to section 7.1 of BUNDLE : " According to normal SDP offer / answer procedures , a bundled m= section can implicitly retrieve its IP address from a session - level c= line , or from a media - level c= line that has been explicitly assigned to the bundled m= section . A media - level c= line MUST NOT be assigned to a bundle - only m= section . " 
 do you want to write up a PR for this ? We have an opportunity to fix it now as part of the 8445 updates . 
 BUNDLE already references 8445 . But , I have no problem writing a PR if we can add the text without having to take the draft back to the WG etc . After all , it 's just a clarification . 
 where did we end up on this ? Is there a clarifying sentence that should be here ? 
 any further thoughts here or should we just close this out ? 
 Is there any problem of things that do n't do this failing to parse it if it does not have the c= dummy address ? 
 It unfortunately seems like the clarifying sentence was never . 
 At the end of the day , it should not matter what address you use , because you would take the port , and the address ( in case you have c- lines for each m- section ) , from the bundled m- section . 
 It looks like we have 2 issues : 1 ) the aforementioned c= guidance , which I think is probably mostly cosmetic 2 ) the original issue where BUNDLE gives different guidance than  on where bundle - only is to be used .  sayeth : 
 re 1 ) , I do n't see anything in bundle-54 indicating that a c= line can be omitted from a m= section , meaning that the guidance from RFC 4566 still applies : A session description MUST contain either at least one " c= " field in each media description or a single " c= " field at the session level . 
 That is correct . BUNDLE allows " c= " fields in each media description . The question ( AFAIU ) is whether we need to say something about that in BUNDLE , i.e. , whether to use the real address in such " c= " fields , or a dummy address . 
 Regarding 2 ) , would it be possible to simply remove that statement from JSEP ? After all , it does n't seem normative , but rather " referencing " procedures defined elsewhere . 
 We could , but we 'd probably need to add a note to the section about generating answers indicating that a = bundle - only lines are to be inserted ( and may need to update the examples as well ) 
 Regarding c= , JSEP currently says that once an address is known , all c= lines for the bundle group should use that address ( rather than 0.0.0.0 ) . 
 Correct . 
 I think a BUNDLE implementation should be able to handle that . Does a JSEP implementation also assume a c= line in each m= section in SDPs received from a peer ? 
 JSEP can handle session - level c= lines , but it does n't say anything about a SDP where only some m= sections have c= lines . 
 I am pretty sure that most ( all ? ) SDPs received from non - JSEP endpoints will only contain a session level c= line . So , whatever JSEP requires , I guess the receiving stack will have to " correct " the SDP before passing it on to JSEP . 
 Not sure what you mean . I think the key question for 1 ) at this point is whether c= lines in bundled m= sections need to use 0.0.0.0 or can use the shared address for the bundle group . 
 as a BUNDLE author , can you see what needs to be done here ? 
 hmm - not sure I can but I will take a look 
 JSEP previously was in accordance with BUNDLE . The problematic changes seem to have happened in this PR : , which was merged with no review ( and a single email to the list that received no replies on Nov 24 , 2017 ) . In fairness , this github issue was opened shortly afterwards , but I confess I did n't understand the actual issue until now . The discrepancies with JSEP are essentially the same as noted above ; bundled m= lines now always have zero ports and a = bundle - only attributes , regardless of initial offer status , which contradicts JSEP 's guidance . With some more time I think I could tweak  's handling of bundle - only to match BUNDLE ; this is largely syntactical . However the zero port issue may affect how we select dead m= sections to recycle , and it does seem somewhat odd that we use this zero port hack in situations where it is not needed . That will require some effort to unwind . do you recall the impetus behind making this change in BUNDLE ? Somebody is going to have to do some work , so let 's try to figure out where we want here and then we can figure out where to make the patch . as    previously was in accordance with BUNDLE . The problematic changes seem to have happened in this PR : , which was merged with no review ( and a single email to the list that received no replies on Nov 24 , 2017 ) . In fairness , this github issue was opened shortly afterwards , but I confess I did n't understand the actual issue until now . The changes were also mentioned when the new version ( -41 ) of the BUNDLE implementing the PR draft was submitted : See below for the e - mail discussion behind the PR . The discrepancies with JSEP are essentially the same as noted above ; bundled m= lines now always have zero ports and a = bundle - only attributes , regardless of initial offer status , which contradicts JSEP 's guidance . The removal of the " shared address " concept in general was based on comments from Ekr . However , when it comes to the specific change regarding port zero and the bundle - only attribute , it was suggested by   
 I agree that is the issue . ( I just wanted to point out that SDPs from non - JSEP endpoints most likely will only contain a session - level c= line , and IF that is a problem for JSEP then the receiving SDP stack need to " fix " the SDP before passing the received SDP to JSEP . ) 
 the c= line is just one part of the issue . The zero port stuff is the bigger issue , and not something that can be trivially fixed up . Generally , I think that this change was made to bundle without sufficient discussion , and as a result we now have two specs that contradict each other . 
 Well , I was very frustrated throughout the whole BUNDLE process , since people did n't comment on the changes - including people who asked for changes . I did send out e - mails on the list , I did send e - mails to people in private , and I did open pull requests . My opinion has always been that if one is interested in a draft , one is expected to follow the mail discussions . Also , after these changes had been made , there were WGLC reviews etc . However , discussing history wo n't solve the issue : what we need to do to figure out now is how to move forward . When it comes to port zero and bundle - only , my suggestion is to make the change in JSEP . When it comes to media - level c= lines , we can for sure add clarification text in BUNDLE and/or JSEP , if needed . 
 The problem though is that BUNDLE has n't articulated a migration strategy from the previous behavior to the new behavior , meaning that all current implementations are not in compliance and there 's no easy way to change that .  , on the other hand , is consistent with current implementations . Therefore I think the correct path forward is to revert the new behavior from BUNDLE before publishing . 
 The problem though is that BUNDLE has n't articulated a migration strategy from the previous behavior to the new behavior , meaning that all current implementations are not in compliance and there 's no easy way to change that .  , on the other hand , is consistent with current implementations . Both BUNDLE and JSEP drafts were still work - in - progress back in 2017 , and implementers need to be aware that there can be changes . And , we DID identify ( described in this GitHub issue ) the change back then , nobody objected to it , but we forgot to fix it . So , until JSEP implementations have been updated , I think the web application developer can " manually " fix the SDP before sending it out on the wire . Does n't the web app anyway have to modify the SDP for other reasons , or do I remember wrong ? 
 At some point every change needs to be done with a migration in mind , and we are well past that point ( even in 2017 ) . We can not simply tell every application they need to fix up their SDP , or that we are suddenly going to change what is emitted by the browser , unless there is some clear and urgent motivation . It is regrettable that we are only realizing the extent of this issue now , but here we are ( and at least we 're not finding this months after publication ) . I 'm discussing with  how to best sort this out ; unless we can demonstrate that this change does n't break existing apps , I think we need to fix it as an erratum to bundle . in case he has any thoughts on how to handle the situation . 
 At some point every change needs to be done with a migration in mind , and we are well past that point ( even in 2017 ) . Nobody made that claim , or objected to the change , when this JSEP issue was raised in 2017 . The problem is that we forgot to implement the change in the JSEP draft . We can not simply tell every application they need to fix up their SDP , or that we are suddenly going to change what is emitted by the browser , unless there is some clear and urgent motivation . Changing it could break existing BUNDLE implementations ( non - JSEP ) . And , we do n't know if there are other standard specifications referencing BUNDLE , and how such change would affect those specs . 
 I do n't think we understood the extent of the change when the issue was initially raised . There are literally billions of WebRTC endpoints that would be affected by this change , so unless we can show that there are a comparable number of non - WebRTC BUNDLE endpoints that would be affected by a rollback , I think that 's the clearest path forward . I 'm going to send a note to the C238 list now , we can continue the discussion there . 
 But the endpoints still need a JavaScript web app that implements some signalling protocol ( SIP / SDP , or something else ) that will take care of the wire traffic , wo n't it ? 
 sure , but how does that change the situation ? 
 You can do an intermediary fix by updating those " signaling web apps " on their servers . The browsers will download the latest version of the app from the server whenever they are going to run the app . Also , I would assume that every pro-2017 web app that supports JSEP and BUNDLE have already done the fix , if they have implemented the latest versions of the spec . The actual JSEP API implementation , that is part of the browser , will be updated whenever people update their browser . 
 We ca n't even get apps to update to improve their security story , they are not going to update for this issue . 
 If there are pre-2017 web apps out there , that have since then not been updated with whatever changes ( e.g. , related to BUNDLE ) and improvements ( e.g. , related to security ) that have been made since then , maybe it 's a good thing that they do n't work . 
 We 're not the internet police , we do n't get to decide that . This ship has sailed . 
 We should also not be held hostage by people who do n't bother to update their implementations - especially if they implement something that is still work in progress . 
 I looked into this more and Chrome / Edge / Safari never generate a = bundle - only , and  only does so on initial offers ( like JSEP ) . Given this , I think the chance of someone misinterpreting a zero port is pretty high , and we ought to simply scrap that behavior entirely . 
 How does C / E / S request ( in an initial offer ) that an m= line shall only be accepted by the answerer if it puts the m= line in the BUNDLE group ? 
 shared port in the initial offer 
 which is what we would have originally done , but we were concerned that non - bundle - aware endpoints might malfunction upon receiving non - unique ports . That concern no longer really exists , but now we have the new concern that bundle - aware endpoints might malfunction upon receiving zero ports ... hence why I think we should junk a = bundle - only , at least in the WebRTC context 
 Such behavior has never been part of BUNDLE or  ( unless you count port 9 as a shared port ) . 
 why does that concern no longer exist ? Sorry , still paging all this back in . 
 Exactly one person has complained about  not supporting a = bundle - only over the last 10 years , so I think we have a clear signal that this is not a real - world concern . However , because we never this , we now have a real compatibility concern in that apps that use  - bundle may suddenly break when we start sending zero ports . indicated they hit this as part of adding bundle - only in firefox and may be able to add more specifics here . IOW , no upside , all downside . 
 In initial offers , if you do n't have bundle - only , you will have to include separate port numbers ( and separate candidates , if ICE is used ) for each m- line ( unless you use trickle , in which case you will use port 9 for each m- line ) . One of the main reasons for introducing bundle - only was to avoid having to do that . Using the same non-9 port number in each m- line in the initial offer was shut down more or less the first day we started working on BUNDLE . 
 Remember , we 're really only talking about the  - bundle case here ( otherwise , separate port numbers are already used ) . Evidence shows that a shared port works pretty well in this case ( as that 's the behavior used by   ) , so I think we can just internalize that and move on . 
 Let 's continue this discussion on the list so that we do n't need to reply in both places . 
 Yes , I was going to suggest that , and I also noticed that you had suggested it earlier . 
 Path forward here : 
 The new version of the BUNDLE specification has passed MMUSIC WGLC , and the publication request has been sent to IESG . 
 LGTM
Mailing list commentary: At the recent meeting there were several decisions which need confirmation . First , the resolution of the core question of the mismatch between BUNDLE and was : Switch BUNDLE to match [ Christer volunteered to do it ] . If you object to this result , please send a message to the list explaining why and what you would like to see instead . For the mechanism to accomplish that , the group in the meeting agreed to : Create a new " - bundle - safe " [ name TBD ] with current " - bundle - behavior " . Document that " " used to exist and now has unspecified and deprecated behavior . If you object to this result , please send a message to the list explaining why and what you would like to see instead . Note that if you object to the first point and your reason for the second objection is that you prefer something else there , you do not need to object again . On a functional basis the plan i to re - rev in place rather than to do a patch draft . If you object to that revision plan , please send a message to the list explaining why and what you would like to see instead . will discuss the same thing for BUNDLE with the ADs and chairs ; if you have an opinion on that , please send it to the ADs and chairs of both RTCWEB and MMUSIC . If you are okay with these results and did not voice your opinion at the meeting , please send your confirmation to the list . Thanks ,
Hi , I have submitted a new version ( -41 ) of BUNDLE . The main technical changes are in the Offer / Answer sections : The SDP bundle - only attribute is now used both in offers ( initial and subsequent ) and answers . If the m- section of an offer contains a BUNDLE address , the answerer can not reject that m- section or move the m- section out of the BUNDLE group in the answer . Some of the ICE offer / answer subsections were removed , because most of the text was duplications and people asked why it is needed . I have tried to address to questions / comments I have received , and I personally think the procedures are easier to understand now . Regards , Christer
In an initial offer , if we want to communicate " this ' m= ' section must be either bundled or rejected " , that 's accomplished with " a = bundle - only " : a = group : BUNDLE A B m = audio ... a = mid : A ... m = video 0 ... a = mid : B a = bundle - only In subsequent offers , this is accomplished by duplicating the IP address / port ( see section 8.3.3 ): a = group : BUNDLE A B m = audio ... a = mid : A ... m = video ... a = mid : B Is this initial vs. subsequent offer difference necessary ? Both blobs of SDP are communicating the same information , so the " shared address " rules seem to only add complexity . Also , the approach of using a " shared address " to communicate something is n't extensible to protocols that do n't use an address for identification , like ICE . We 'd need to define additional rules for those cases , or allow them specifically to use " a = bundle - only " in subsequent offers .
Paragraph (version B):
This specification obsoletes RFC 8829.
Paragraph (version A):
Since the approval of the WebRTC specification documents, the IETF
has become aware of an inconsistency between the document specifying
JSEP and the document specifying BUNDLE (this RFC and RFC8843,
respectively).  Rather than delaying publication further to come to a
resolution, the documents are be ing published as they were
originally approved.  The IETF intends to restart wor k on these
technologies, and revised versions of these documents will be publish
ed as soon as a resolution becomes available.
Paragraph (version B):
When [RFC8829] was published, an inconsistency regarding BUNDLE
RFC8843 operation was identified concerning both the specification
text as well as implementation behavior.  The former concern was
addressed via an update to RFC8843.  For the latter concern, it was
observed that some implementations implemented the "max-bundle"
bundle policy by assuming that bundling had already been negotiated,
rather than marking "m=" sections as bundle-only as indicated by
RFC8829.  In order to prevent unexpected changes to applications
relying on the pre-standard behavior, the decision was made to
deprecate the use of "max-bundle" and instead introduce a new "must-
bundle" policy that, when selected, provides the correct behavior.
Paragraph (version A):
The application can specify its preferred policy regarding use of
bundle, the multiplexing mechanism defined in RFC8843.  Regardless of
policy, the application will always try to negotiate bundle onto a
single transport and will offer a single bundle group across all "m="
sections; use of this single transport is contingent upon the
answerer accepting bundle.  However, by specifying a policy from the
list below, the application can control exactly how aggressively it
will try to bundle media streams together, which affects how it will
interoperate with a non-bundle-aware endpoint.  When negotiating with
a non-bundle-aware endpoint, only the streams not marked as bundle-
only streams will be established.
Paragraph (version B):
The application can specify its preferred policy regarding the use of
BUNDLE, the multiplexing mechanism defined in RFC8843.  Regardless of
policy, the application will always try to negotiate bundle onto a
single transport and will offer a single bundle group across all "m="
sections; use of this single transport is contingent upon the
answerer accepting bundle.  However, by specifying a policy from the
list below, the application can control exactly how aggressively it
will try to bundle media streams together, which affects how it will
interoperate with a non-bundle-aware endpoint.  When negotiating with
a non-bundle-aware endpoint, only the streams not marked as bundle-
only streams will be established.
Paragraph (version B):
RFC8829 defined a policy known as "max-bundle", which, while defined
identically to the "must-bundle" policy described above, was
implemented by some implementations according to an earlier, pre-
standard definition (in which, for example, no "m=" sections were
marked as bundle-only).  As a result, "max-bundle" is considered
deprecated, and new applications should use the "must-bundle" policy
instead.
Paragraph (version A):
This section shows a more involved example of a session between two
JSEP endpoints.  Trickle ICE is used in full trickle mode, with a
bundle policy of "max-bundle", an RTCP mux policy of "require", and a
single TURN server.  Initially, both Alice and Bob establish an audio
channel and a data channel.  Later, Bob adds two video flows -- one
for his video feed and one for screen sharing, both supporting FEC --
with the video feed configured for simulcast.  Alice accepts these
video flows but does not add video flows of her own, so they are
handled as recvonly.  Alice also specifies a maximum video decoder
resolution.
Paragraph (version B):
This section shows a more involved example of a session between two
JSEP endpoints.  Trickle ICE is used in full trickle mode, with a
bundle policy of "must-bundle", an RTCP mux policy of "require", and
a single TURN server.  Initially, both Alice and Bob establish an
audio channel and a data channel.  Later, Bob adds two video flows --
one for his video feed and one for screen sharing, both supporting
FEC -- with the video feed configured for simulcast.  Alice accepts
these video flows but does not add video flows of her own, so they
are handled as recvonly.  Alice also specifies a maximum video
decoder resolution.