Draft: draft-ietf-rtcweb-jsep

Commentary: And also Since introducing transceivers , replaceTrack , early media , etc . , the definition of a MediaStreamTrack has changed and track ID signaling has become somewhat pointless . In many cases , " " on one side will not match " " on the other side ; endpoints must use MIDs or m= section indices or some other means to identify which track is which . Thus this PR just removes track ID signaling altogether and the lingering problems it causes . 
 Now that we only use the stream ID , " a = msid:{streamId } " , I just want to verify that I understand this correctly : If I do addTrack(track ) without any streams , " a = msid " is completely omitted . If I do addTrack(track , stream1 , stream2 , ... ) with multiple streams , I get one " a = msid " line per stream . Is this correct ? 
 Or is " a = msid " mandatory in which case I would have to do " a = msid:- " in the case of no stream ? 
 FWIW , I missed this discussion , and do not agree with the change . It is a significant , breaking protocol change introduced very late in the process , and has not ( AFAIK ) been discussed on the mailing list . So by IETF consensus rules , there 's no basis for ruling that the change has consensus in the WG . 
 Before this change , " a = msid " was broken e.g. and The track ID is only surfaced to JavaScript if the answerer does not have any transceivers to match with the offer . Relying on " mid " or MediaStream IDs are clearly the better alternative , because they have a reliable behavior that works not just in edge - cases and are not misleading in all other cases . An argument can be made for keeping track IDs , but I suspect the argument would be for backwards compatibility reasons or for people who want to parse SDP to figure out ID information ( information which , by the way , would have been easier to carry through streams ) . In either case ,  and MSID specs . As I recall from testing , while  surfaces track IDs in some edge - cases ,  does not . If we can survive the switch to Unified Plan without track ID related breakages , as  did , then I see little reason to try to save the sinking ship that is " a = msid " . This is a remnant of the track / stream way of thinking . To be discuss at TPAC . There is a slide for the issues referenced . 
 a = msid is still relied on to create streams with synchronized tracks -- LS groups have n't made it to any implementation afaik . 
 AFAIK tracks synchronization in receiver is based in RTCP CNAME rather than msid . msid is just an artifact to tell the app whether different tracks should be grouped within the same MediaStream , but that 's just a hint and a unfortunate remnant of the " stream based API " that should n't be part of WebRTC itself . 
 Anyone who is sad to not be able to rely on could though , because of " a = msid " , do this :) 
 a = msid is not mandatory , and can be omitted if there are no streams . 
 discoveries when updating -msid to allow for this : omitting a = msid will lead to a default stream ( legacy behavior ) the way to signal that a track is no longer present is by omitting msid after it has been present so the only way to signal " one track no stream " is to send a = msid:- -msid used to allow for sending one track into multiple recipient streams . With a = msid:- it can no longer do so . PR is up .
Paragraph (version A):
If present, "a=msid" attributes MUST be parsed as specified in I-
D.ietf-mmusic-msid, Section 3.2, and their values stored.
Paragraph (version B):
If present, "a=msid" attributes MUST be parsed as specified in I-
D.ietf-mmusic-msid, Section 3.2, and their values stored, ignoring
any "appdata" field.