Draft: draft-ietf-rtcweb-jsep

Commentary: Fixed 
 also tagging ( who might be unhappy with ' default ' which matches Chrome behaviour but not Firefox behaviour ( it generates a uuid ) 
 ping 
 PTAL - Barring any objections this one ought to get merged . 
 Folks , I think this one is pretty uncontroversial - planning to land this next week if there are no objections . 
 Take this simplified SDP offer from a remote endpoint ( in parts taken from : A single audio and video stream . No a = mid ( there is quite some text taking care of that ) but no a = msid line either . shows a live example . Both  ( without unified - plan ) and Firefox will fire the ontrack event ( or legacy onaddstream ) with a single mediastream containing an audio and video track . This has been like that since ... 2012 - ish ? Unified plan support in  changes this behaviour : ontrack is fired with an empty set of media streams . onaddstream is not fired . This is quite a change in behaviour . And unexpected , I did n't expect any issues for this trivial case of a single audio / video track . As webrtc - pc assumes / requires a = msid to be present and . In particular this says which means firing with no streams is technically correct . JSEP seems to assume it is present as well , but has this text about a = msid in Note the " If present " . What if it is not present ? The closest I could find in terms of guidance was this from the and its section about handling a = msid is supposed to be present in initial offer so we are talking about dealing with non - webrtc entities send an offer . Given that there is plenty of support for entities that do not support a = mid ( an RFC published in 2010 ) in  do we need backward compability for the case of a single audio / video track each but no msid ? Interop between browsers is probably not affected , due to  still interpreting and sending a = ssrc:123 msid : ... 
 note that a proper webrtc client will include " no streams " as ( maybe with a track ) which allows differentiating between " no streams because I do not use any " and " msid ? ? ? " Thanks for another 
 aside : the interesting case you have trouble distinguishing between is " no msid because I have n't started sending a track yet " and " no msid because I do n't support msid " . It 's one case where we still have trouble if RTP packets arrive ahead of signalling . But - yes , I think we are better off sticking with the 2012 behavior , default stream and all . We can handle the case above by changing the stream associations of the receiver if a new SDP ( with msid ) arrives after the RTP packets . 
 there used to be a a = msid - semantic line that would allow determining whether a party wants its offer to be treated assuming msid support . Browsers still send it :-) 
 How are non - signaled tracks supposed to be handled anyway ? There 's JSEP language about creating a track for it , but what about webrtc - pc ? ( If a track exists in the forest , and nobody is around to surface it to JavaScript , does it still exist ? ) " Run the following steps for each media description in description " means no ontrack will fire until we do have something signaled . If the track ( and/or stream ) only exists in some inaccessible way they 're almost conceptual until the signaling does arrive . And when it does arrive , we know whether or not MediaStreams were signaled . So we should know what to do , same things as if we did n't receive early RTP packets ? Does the distinction matter ? I love that we can tell the difference between " no streams because I do not use any " and " no msid signaled " whether or not " a = msid:- " was present . I had not thought about that ! Unless I 'm confused about something , I suggest : If is present , do what  does : do n't create any stream . If the line is completely missing , do what  ( or Chrome Plan B ) does : create a MediaStream with a random i d. Does that work for people ? 
 By the way I thought this was a webrtc - pc issue when I replied above , so I was thinking about what to do in JavaScript rather than talking about any JSEP change . 
 I suppose we need some JSEP language to handle the lack of any a = msid but i agree with what you propose above . We do have have a = msid:- and we need to handle that in webrtc - pc too . Will file an issue there . 
 All webrtc - pc says is " let msids be a list of the MSIDs that the media description indicates transceiver.[[Receiver]].[[ReceiverTrack ] ] is to be associated with . Otherwise , let msids be an empty list " And says " The special value " - " indicates " no MediaStream " . " So that already takes care of the case correctly , I claim . I agree . We need to solve what the media description ( JSEP ) says about this . Right now : " If present , " a = msid " attributes MUST be parsed as specified in [ I - D.ietf - mmusic - msid ] , Section 3.2 , and their values stored . " I think it needs to say what happens when it is not present . Something like : " If no a = msid is present , then in place of " msid - id " , create a single " i d " unique to this end - point , if one has n't already been created for this connection . " 
 " if one has n't already been created for this connection " ; so future tracks will share the same stream ? There is always at most a single " default stream " ? 
 says he observed this is how  and  work . 
 See 
  I asked is that chrome generates a MediaStream with i d " default " -- see while  does not . ( I do not see any reason to change the legacy behaviour of chrome even though it seems a bit odd that the RNG always emits the right bytes for " default " )
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.  If no "a=msid" attributes are present, a
random msid-id value is generated for a "default" MediaStream for
the session, if not already present, and this value is stored.