{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/webrtc-pc/issues/1858","repository_url":"https://api.github.com/repos/w3c/webrtc-pc","labels_url":"https://api.github.com/repos/w3c/webrtc-pc/issues/1858/labels{/name}","comments_url":"https://api.github.com/repos/w3c/webrtc-pc/issues/1858/comments","events_url":"https://api.github.com/repos/w3c/webrtc-pc/issues/1858/events","html_url":"https://github.com/w3c/webrtc-pc/issues/1858","id":318514474,"number":1858,"title":"What happens when an answerer stops a transceiver that others are \"bundled\" on?","user":{"login":"taylor-b","id":14118599,"avatar_url":"https://avatars3.githubusercontent.com/u/14118599?v=4","gravatar_id":"","url":"https://api.github.com/users/taylor-b","html_url":"https://github.com/taylor-b","followers_url":"https://api.github.com/users/taylor-b/followers","following_url":"https://api.github.com/users/taylor-b/following{/other_user}","gists_url":"https://api.github.com/users/taylor-b/gists{/gist_id}","starred_url":"https://api.github.com/users/taylor-b/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/taylor-b/subscriptions","organizations_url":"https://api.github.com/users/taylor-b/orgs","repos_url":"https://api.github.com/users/taylor-b/repos","events_url":"https://api.github.com/users/taylor-b/events{/privacy}","received_events_url":"https://api.github.com/users/taylor-b/received_events","type":"User","site_admin":false},"labels":[{"id":904421577,"url":"https://api.github.com/repos/w3c/webrtc-pc/labels/May%202018%20interim","name":"May 2018 interim","color":"c2e0c6","default":false}],"state":"open","locked":false,"assignee":{"login":"taylor-b","id":14118599,"avatar_url":"https://avatars3.githubusercontent.com/u/14118599?v=4","gravatar_id":"","url":"https://api.github.com/users/taylor-b","html_url":"https://github.com/taylor-b","followers_url":"https://api.github.com/users/taylor-b/followers","following_url":"https://api.github.com/users/taylor-b/following{/other_user}","gists_url":"https://api.github.com/users/taylor-b/gists{/gist_id}","starred_url":"https://api.github.com/users/taylor-b/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/taylor-b/subscriptions","organizations_url":"https://api.github.com/users/taylor-b/orgs","repos_url":"https://api.github.com/users/taylor-b/repos","events_url":"https://api.github.com/users/taylor-b/events{/privacy}","received_events_url":"https://api.github.com/users/taylor-b/received_events","type":"User","site_admin":false},"assignees":[{"login":"taylor-b","id":14118599,"avatar_url":"https://avatars3.githubusercontent.com/u/14118599?v=4","gravatar_id":"","url":"https://api.github.com/users/taylor-b","html_url":"https://github.com/taylor-b","followers_url":"https://api.github.com/users/taylor-b/followers","following_url":"https://api.github.com/users/taylor-b/following{/other_user}","gists_url":"https://api.github.com/users/taylor-b/gists{/gist_id}","starred_url":"https://api.github.com/users/taylor-b/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/taylor-b/subscriptions","organizations_url":"https://api.github.com/users/taylor-b/orgs","repos_url":"https://api.github.com/users/taylor-b/repos","events_url":"https://api.github.com/users/taylor-b/events{/privacy}","received_events_url":"https://api.github.com/users/taylor-b/received_events","type":"User","site_admin":false}],"milestone":null,"comments":1,"created_at":"2018-04-27T18:56:43Z","updated_at":"2018-05-23T01:04:08Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"The BUNDLE spec says:\r\n\r\n> When an answerer wants to reject a bundled \"m=\" section in an answer, it MUST first check the following criterium:\r\n> \r\n> -In the corresponding offer, an offerer BUNDLE address:port (previously selected [Section 8.3.1] or newly suggested [Section 8.5.1]) has been assigned to the \"m=\" section by the offerer.\r\n> \r\n> If the criterium above is fulfilled the answerer can not reject the \"m=\" section in the answer (unless the answerer rejects each bundled \"m=\" section within the BUNDLE group).  The answerer can either reject the whole offer, reject each bundled \"m=\" section within the BUNDLE group, or keep the \"m=\" section within the BUNDLE group in the answer and later create an offer where the \"m=\" section is disabled within the BUNDLE group [Section 8.5.4].\r\n\r\nOr, in [this PR](https://github.com/cdh4u/draft-sdp-bundle/pull/59/files) which changes the terminology:\r\n\r\n> When an answerer wants to reject a bundled \"m=\" section in an answer, it MUST first check the following criterium:\r\n> \r\n> - In the corresponding offer, the \"m=\" section is the offerer tagged \"m=\" section.\r\n> \r\n> If the criterium above is fulfilled the answerer can not reject the \"m=\" section in the answer. The answerer can either reject the whole offer, reject each bundled \"m=\" section within the BUNDLE group, or keep the \"m=\" section within the BUNDLE group in the answer and later create an offer where the \"m=\" section is disabled within the BUNDLE group.\r\n\r\nEither way, the point is the same. If you have an established bundle group, \"a=BUNDLE audio video\", the answerer can't reject the \"audio\" section without rejecting \"video\" as well.\r\n\r\nSo: how should this play with `RTCRtpTransceiver.stop`, specifically when called in the \"have-remote-offer\" state? Should stopping the audio transceiver automatically cause the video transceiver to be stopped as well? Or should the answerer keep the audio m= section (as \"inactive\", maybe?), then stop it in a subsequent offer triggered by `onnegotiationneeded`?\r\n\r\nAnd does this require JSEP changes?"},"comment":{"url":"https://api.github.com/repos/w3c/webrtc-pc/issues/comments/391187810","html_url":"https://github.com/w3c/webrtc-pc/issues/1858#issuecomment-391187810","issue_url":"https://api.github.com/repos/w3c/webrtc-pc/issues/1858","id":391187810,"user":{"login":"taylor-b","id":14118599,"avatar_url":"https://avatars3.githubusercontent.com/u/14118599?v=4","gravatar_id":"","url":"https://api.github.com/users/taylor-b","html_url":"https://github.com/taylor-b","followers_url":"https://api.github.com/users/taylor-b/followers","following_url":"https://api.github.com/users/taylor-b/following{/other_user}","gists_url":"https://api.github.com/users/taylor-b/gists{/gist_id}","starred_url":"https://api.github.com/users/taylor-b/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/taylor-b/subscriptions","organizations_url":"https://api.github.com/users/taylor-b/orgs","repos_url":"https://api.github.com/users/taylor-b/repos","events_url":"https://api.github.com/users/taylor-b/events{/privacy}","received_events_url":"https://api.github.com/users/taylor-b/received_events","type":"User","site_admin":false},"created_at":"2018-05-23T01:04:08Z","updated_at":"2018-05-23T01:04:08Z","author_association":"CONTRIBUTOR","body":"> Is there a way in the API to know that BUNDLE is being used? \r\n\r\nYes; if `transceiver1.receiver.transport == transceiver2.receiver.transport`, they're currently bundled together and would be affected by this. That still doesn't tell you which is the special one that can't be rejected, but you could tell by parsing the \"a=group:BUNDLE\" in the offer.\r\n\r\nBy the way, the conclusions at the virtual interim were:\r\n* We should just reject all bundled m= sections if this happens, because that's simpler.\r\n* The other rejected m= sections' transceivers shouldn't be stopped until `setLocalDescription(answer)`"}}
{"actor":{"display_login":"taylor-b"}}