Draft: draft-ietf-rtcweb-jsep

Commentary: I cleaned up the language . 
 lgtm 
 Cullen wants LS groups because that is what legacy gear understands . Magnus wants to use MSID , which carries this . 
 Discussed in DC : will test out the LS group concept ,  will send text to the list and we will discuss . Concerns are that there is a potential for mismatch between what is signaled in LS groups and what is signaled in MSID . We also need to work out what to do in the absence of LS groups . 
 bug 32 is prob dup of this 
 pinged Lennox 
 Given the discussion on CNAME , no one in the room at IETF90 objected to the idea that LS group was MTI . 
 Plan here is update draft to say that when creating the SDP , everything in PC has same CNAME , and the things in the same MediaStream get put in a LS ( lipsync ) group . This will mean legacy stuff that support  will do the right thing , and legacy stuff that does not , will simply try and sync everything . 
 Cullen to ping Harald to get his LG regarding the comment above ( ie . regarding its interaction with MSID ) 
 Just to add some clarity here .... this is what I think we decided . All the RTP in a given PeerConection will use the same CNAME . For each stream , If a stream has more than one track , then the JSEP needs to create a lip sync group ( see ) to put all the tracks in a given stream into the same lip sync group . 
 Yes . If no lipsync group from the remote side , everything is synchronized . If only some tracks in LS group , the rest are unsynchronized . ( Basically , if you indicate you understand LS , we take what you give us , all synced ) 
 MT , would you be willing to write some text here ? 
 Who has the token here ? 
 Just realized there could be a problem . Consider A , who does not want to sync its audio / video , and B , who wants its video to be synced . A offers a = group : LS with no mids . B has to reply with a subset of the proposed mids , by 5888 rules . Therefore B 's a / v wo n't be synced . I do n't see a good reason to require this , but 5888 is pretty clear . The identification - tags contained in this " a = group " line MUST be the same as those received in the offer , or a subset of them ( zero identification - tags is a valid subset ) . When the identification - tags in the answer are a subset , the " group " value to be used in the session MUST be the one present in the answer . 
 There 's an issue with LS when using bidirectional media sections . If media stream X ( from A to B ) uses media sections 1 and 2 , and media stream Y ( from B to A ) uses media sections 2 and 3 , what should be the lipsync groups ? Are lipsync groups unidirectional or bidirectional ? 
 see comment above .  says  , but that is crazy talk . 
 Indeed . Crazy . What is our plan of attack here then ? Can we ask MMUSIC to fix this ? Either by un - screwing - up a = group ( which seems unlikely ) , by making a new grouping semantic , or by telling us that there is a better option . 
  reserves the right to contradict existing standards where necessary . Generally , it seems like the need for symmetry in a = group is semantic - dependent , and so fixing it later in 5888 seems possible . 
 So you are suggesting that we define a = group : LS as declarative : it applies to the media that is sent by the peer that includes the grouping . I can live with that , though I suspect it will cause considerable heartburn . It certainly complicates the grouping model considerably . 
 yes , essentially . I do n't see any way to reconcile LS with reality otherwise . 
 Changing the semantics of existing mechanisms by declaring that they are changed without actually changing them is a dangerous process . A simpler alternative is to drop media section reuse when LS groups are present : If a particular media section is a member of an LS group , or if a MediaStream requires its tracks to be part of an LS group , do n't use it for a track in the opposite direction . The legacy case of one audio section , one video section that is used in both directions will then require that we somehow turn off LS group generation .
Paragraph (version B):
The next step is to generate session-level lip sync groups as defined
in RFC5888, Section 7.  For each MediaStream with more than one
MediaStreamTrack, a group of type "LS" MUST be added that contains
the mid values for each MediaStreamTrack in that MediaStream.
Paragraph (version B):
The "LS" groups are generated in the same way as with initial offers.
Paragraph (version B):
The next step is to generate lip sync groups as defined in RFC5888,
Section 7.  For each MediaStream with more than one MediaStreamTrack,
a group of type "LS" MUST be added that contains the mid values for
each MediaStreamTrack in that MediaStream.  In some cases this may
result in adding a mid to a given LS group that was not in that LS
group in the associated offer.  Although this is not allowed by
RFC5888, it is allowed when implementing this specification.