Minutes of the Meeting: MMUSIC Working Group at IETF 91

The MMUSIC working group met at IETF #91 in Honolulu, Hawaii on Thursday November 13, 2014 from 9:00 to 11:30 and on Friday November 14, 2014 from 9:00 to 11:30.


The meeting was chaired by Flemming Andreasen and Ari KerŠnen.

Simon Perrault and the chairs took notes on Thursday, and Jonathan Lennox acted as Jabber relay.
Roni Even and Charles Eckel and the chairs took notes on Friday, and Jonathan Lennox acted as Jabber relay.


The meetings were broadcast live and recorded by the Meetecho team. The recordings of the sessions are available at the following URLs:

      ThursdayÕs recording: http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF91_MMUSIC&chapter=chapter_0

      FridayÕs recording: http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF91_MMUSIC_II&chapter=chapter_0



Below is the final agenda with links to the relevant sub-sections below:


Thursday, November 13, 2014

09:00-09:15     Introduction and Status Update (15 mins)


09:15-09:35     A Framework for SDP Attributes when Multiplexing (20 mins)


09:35-09:45     IANA Registration of SDP ÔprotoÕ attribute for transporting RTP Media over TCP under various RTP Profiles (10 mins)


09:45-10:15     Negotiating Media Multiplexing Using SDP (30 mins)


10:15-11:00     SCTP-Based Media Transport in SDP (45 mins)


11:00-11:30     SDP bis and IANA Registry Updates for SDP bis (30 mins)




Friday, November 14, 2014

09:00-09:40     ICE bis (40 mins)


09:40-09:55     ICE IPv4/IPv6 Dual Stack Fairness (15 mins)


09:55-10:40     Using Simulcast in SDP and RTP Sessions (45 mins)


10:40-11:05     MSRP over SCTP/DTLS & SDP-based "SCTP over DTLSÓ negotiation (25 mins)


11:05-11:30     RTP Payload Format for Forward Error Correction Packets (25 mins)



Introduction and Status Update

The chairs presented their slides.


There were no comments from the room on the agenda.


During the status update, the chairÕs asked Harald Alvestrand to provide a short update on the status of the msid draft (draft-ietf-mmusic-msid-07):

      Harald has received reviews from Adam Roach and Ted Hardie and he will address those comments (Harald believes they are editorial).

      Overall, Harald believes the technology is good enough for its purpose at this point.

      No second use case outside of RTCWeb has been identified so far and hence itÕs not clear the extensibility mechanisms are really needed, but Harald suggests we leave them in there.

      There has also been some changes in WebRTC where a single media-stream track now belongs to a m=line. This change results in a bit of redundant data with the current mechanism, but no change is needed.

      Once the editorial changes have been made, Harald suggests we go to WGLC.

      Ari (co-chair) asked for additional comments from the room. No comments received.

      Conclusion: Once updated draft addressing the review comments has been submitted, we will proceed towards WGLC.



A Framework for SDP Attributes when Multiplexing (Suhas Nandakumar)



Suhas presented his slides


The categories for the new SDP attributes were accepted as proposed in the slides.

Suhas believes the draft is ready for WGLC at this point.


Christer Holmberg:

      Don't have any comments, but there are a few drafts we want to discuss this week and they may impact Bundle. If we chose to adopt them then the attributes need to be added to this draft.


Cullen Jennings:

      Draft will never be done if keep adding new drafts to it.

      Would rather we have those new drafts put the categories in them.


Christer Holmberg:

      OK - agree with Cullen.


Mary Barnes:

      Agrees with Cullen


Flemming Andreasen (as individual):

      This needs to be finished at some time. This time is as good as any other. 4566bis would need to add a section that new attributes need to have a section that defines the mux categories.


Harald Alvestrand:

      Seems we are ready for WGLC


Charles Eckel:

      Agrees with CullenÕs suggestion


Flemming (Chair):


1.     Seems we are ready for WGLC (asking room); nobody in room disagrees.

2.     4566bis will add procedures that you have to specify mux behavior

3.     Drafts not covered by mux-drafts will now have to to start specifying their mux behavior (will be a requirement in the WG).



IANA Registration of SDP ÔprotoÕ attribute for transporting RTP Media over TCP under various RTP Profiles (Suhas Nandakumar)



Suhas presented his slides

A discussion ensued around how to indicate DTLS over different protocols


Jonathan Lennox:

      Do we have a way to say "DTLS-SRTP over TCP"?


Justin Uberti:

      I agree this is ambiguous. DonÕt want lower layers to buffer data. Thought that TLS in an RTP context always meant DTLS.


Cullen Jennings:

      There is no framing protocol to put DTLS over TCP defined anywhere. We have RTP over TCP. That framing protocol can be used for RTP over TLS. That cannot be used for RTP over DTLS over TCP.


Christer Holmberg:

      I also want something for SCTP over DTLS over TCP


[Note: Quick arguing at the mic.]


Jonathan Lennox:

      The issue is about DTLS-SRTP over TCP.


Ari KerŠnen:

      We need more clarity what is meant with the last 4 profiles in the slides


Harald Alvestrand:

      This shows that the protocol field is a broken concept.



      We need a general way to take what you're doing over datagram and frame it and do the same thing over TCP.


Paul Kyzivat:

      We already have the token DTLS together with SCTP. We should re-use that.


Justin Uberti:

      We already have an RFC specifying that (forgot).

      RFC 4571 handles framing.

      Need to agree on whether TLS can ever mean DTLS. They are changing JSEP to now imply that "UDP/TLS" actually means DTLS (the DTLS token was deprecated in jsep-08)



Ari (as chair):


      Need to start a thread on the mailing list. Give references. Then have this document point to the right documents.



Negotiating Media Multiplexing Using SDP (Christer Holmberg) 



Christer presented his slides covering the following open issues:

1.     Symmetric RTP

2.     Bundle-only default candidates

3.     Move sources



Symmetric RTP

ChristerÕs proposal is to mandate symmetric RTP. This lead to a discussion around support for multicast and non-symmetric RTP:


Jonathan Lennox

       What about multicast? Symmetric RTP would not allow MC to be bundled.


Harald Alvestrand:

      Is it possible to use bundle with multicast? It's only defined for O/A.


Flemming Andreasen (as individual)

      We usually have a separate section for multicast. 3264 also has such a section.



      Based on the KISS principle, both non-symmetric RTP and multicast should be specified later when we have more knowledge.


Colin Perkins:

      Symmetric RTP is good but not a requirement for bundle.


Paul Kyzivat:

      I would not object to words saying implications of non-symmetric RTP are not well known.


Ari (as individual):

      Do not mandate it but recommend?


Flemming (as individual):

      We don't know how non-symmetric RTP is going to work. We can do that by leaving non-symmetric RTP out of scope and add warning text.



      ICE requires symmetric RTP anyway.


Jonathan Lennox:

      I don't see any reason why bundle would change anything. Use non-symmetric RTP at your own risk, no matter if you're doing bundle or not.



      What about saying that you must send all your bundled media from the same transport address, not necessarily symmetric.



      What text says that media has to be sent from a single address:port?



      Because you're going to have different ICE candidatesÉ



      That's an ICE issue, not a bundle issue.

      We should allow sending from different address:port.


Bernard Aboba:

      Does anybody really consider using different sender addresses?



      We agreed long ago that both endpoints would be doing bundle, so there's no reason to be sending from different address:port.



      Not going to mandate symmetric RTP but mandate sending media from the same address:port

      [Note: there was general agreement on this]



      We should say this only applies for unicast O/A.

      [Note: There was general agreement on this]


Mo Zanaty:

      Is bundle limited to a type of m= line?



      RTP and data channel. You can do it for any m= line but describe in another document how multiplexing is done.



      It can never work with TCP.





Conclusion (verified in the room):

      Will not mandate symmetric RTP

      Will mandate sending from same address:port

      Will limit scope to unicast media streams (state explicitly in the draft).



Bundle-only default candidates

Christer presented 4 alternatives with alternative 1 as the proposed solution:

Alternative 1:  ÒDo not assign ICE candidates to bundle-only m- lines with zero port valueÓ



      Alternative 1 makes sense. In general in ICE you don't put candidates on a disabled m= line.


Suhas and Thomas Stach agreed with alternative 1 as well.


Conclusion (verified in the room)

      Alternative 1 is agreed to.


Move sources

The question: Òis it valid for an RTP stream (SSRC) to move between bundled m-lines, or be shared between several bundled m-lines ?Ó.


ChristerÕs proposal is to not allow this


Bernard Aboba:

      There is a special case with simulcast we should think about.


Jonathan Lennox:

      If you have a middlebox that want to leave SSRCs unchanged, then can't change streams. If want to change streams, then would have to rewrite SSRCs.

      I'd prefer to be able to move the SSRC. It adds complexity, but you can do useful things with that.


Mo Zanaty:

      I don't see how moving sources would hurt.

      Moving the SSRC between m-lines does not harm harm BUNDLE as such, so no need to disallow it as it can be useful for certain things.


Roni Even:

      This means that the MID in the RTP header will change.



      Jonathan volunteered to help come up with some text if we agree to allow sources to move.

      The tricky part is if packets get reordered at the moment you start sending an SSRC with a different MID.



      We can just take this text out, publish this, and worry about it later.



      I want to have explicit text in the doc that moving SSRC is allowed. Otherwise we might get interoperability issues.


Emil Ivov (from Jabber room):

      Does not want the restriction


Colin Perkins (from Jabber room)

      There is a problem with allowing this (clock-rate switch).


Ari (as chair)

      On the list, was there any argument for not allowing it apart from complexity?



      Not really.



      Clue has a requirement to actually allow this.



Conclusion (verified in the room):

      Suggestion not agreed to. Jonathan Lennox will help craft some text.

      Ari (as chair) noted we the text ASAP because we need to get the document done.

      Jonathan will provide a date for when he can do this after the meeting.



SCTP-Based Media Transport in SDP (Christer Holmberg)



Christer presented his slides covering the following issues:

1.     Active/passive + TLS role

2.     Identical 5-tuple

3.     Proto values

4.     IANA SCTP fmt registry



Active/passive + TLS role and Identical 5-tuple

Profiles "SCTP" and "SCTP/DTLS":

Justin Uberti:

      SCTP permits both sides to be ACTIVE. And it's actually faster. The role is only for DTLS. Chrome does this. I think Firefox as well. Let's leave the setup field only applying to DTLS.



      The endpoint behind a NAT is the one that needs to open the connection.



      It'll work just as well if both endpoints try to open simultaneously. We will have issues if both are passive. So say that both should be always active and we're done.



      Do we need a setup attribute at all?



      a=setup attribute is only for DTLS. Pure SCTP doesn't need it.



      For SCTP, don't use the setup attribute (slide 3)

      For DTLS, you do want to use it (slide 4)


Profile "DTLS/SCTP" Identical UDP/TCP 5-tuple



      Want to understand the problem. Why do we need to do multiple associations when SCTP allows for ~65000 channels ?


Christer's suggestion (slide 13, alternative 1): Allow single SCTP association per DTLS connection (this is what is done in RTCWeb; does allow multiple data channels, but single association usage).



      The basic problem here is that SDP is a mess.

      In favor of Christer's suggestion.


Peter Thatcher:

      In favor of Christer's suggestion.




      Consensus for alternative 1 (ChristerÕs proposal), "Allow single SCTP association per DTLS connection".



Proto Values

ChristerÕs proposal: UDP/DTLS/SCTP + TCP/DTLS/SCTP are suggested as replacement for DTLS/SCTP



      The word "TLS" has to mean the same thing whether we're talking about RTP or SCTP. Because you can put both TLS and DTLS over TCP, we need to say "DTLS" whenever we're talking about DTLS.

      DTLS over TCP is defined in ice-tcp

      Always want to use DTLS.

      Should have TLS mean the same thing between RTP usage and SCTP usage (back to Suhas' draft on IANA)



      Need to have normative reference to where DTLS over TCP is defined (ice-tcp it seems).


Charles Eckel:

      BFCP had to go through this. Dropped the "D" for DTLS (basically said "TLS" when over UDP).



      We need to have a common definition what TLS or DTLS means in the proto field.



      4571 is not a complex draft; could update it to solve the "where is it defined"


Adam Roach:

      This is the biggest bikeshed I've seen in this group in a long time.



      This is definitely a bike-shed.

      Justin will start an email thread to choose the right color.



      Email thread to be started on the mailing list about this topic.



IANA SCTP fmt Registry (15)

ChristerÕs proposal: Specification Required.



      Is data-channel registration done by this draft or the data-channel draft?

      Doesn't like the term "webrtc-datachannel". Is applicable beyond webrtc.

Mary Barnes:

      Name was brought up long time ago; people didn't care then. Too late to bring up now.



      Christer's suggestion agreed to.



SDP bis and IANA Registry Updates for SDP bis (Ali Begen)




Ali presented his 4566bis slides and his 4566bis-iana-updates slides



Need more reviewers to look at Paul Kyzivat's ABNF updates.


Paul Kyzivat:

      There hasn't been much review, and we really need serious review of these.



      Christer, Colin & Jonathan Lennox volunteer to review


Note: Also need review of the template.

Bundle classification: Kyzivat didn't put in yet but should be added.


Outstanding Issues:

Issue 1: Christer had reviewed the changes and had some comments around Offer/Answer considerations missing for attributes in 4566bis and if we should add bundle considerations (category) as well. 



      Clarifying that his comment was more about for new attributes. Need to have template information etc. considering mux'ing for new attributes.


Issue 2: Christian Groves had caught some attributes and values that are missing in the IANA registries. Some of these pre-date RFC 4566 and its IANA registration requirements.


Keith Drage:

      Stuff from old RFCs that has not been registered with IANA falls back to the old procedure before we had IANA considerations sections, which is that the chairs can handle them.

      Chairs can ask IANA to get them registered.


Action: Ali to send list to chairs so they can get registered.




(IANA updates for 4566bis document)


Flemming (as individual):

      Why do we need a separate document instead of putting it into 4566bis?


      This is intended to be a temporary document that can be merged into 4566bis once content is agreed.



      I don't know what "Attribute is character-set dependent" means.


      It's for attributes that contain human-readable text, because SDP pre-dates UTF-8.



      I would be inclined to deprecate this mechanism


Need volunteers to review the document



      Jonathan Lennox, Christer and Colin volunteer to review this one as well.



ICE bis (Ari KerŠnen)




Ari presented his slides.


Slide 3 (pacing for non-RTP traffic)



      RTP with non-RTP traffic may be combined with bundle. Need to consider (may belong to bundle draft though).


      Good point; original pacing was assuming a single RTP stream. Need to consider further.



      Still think we only need one timer for all kind of traffic.


      Connectivity check different for non RTP since for RTP the rate may be known.

      DonÕt have good numbers for the behavior with arbitrary non-rtp traffic, need to understand it better via measurements.


Slide 4 (Updated Offer with SIP/SDP)


Consensus at IETF 90 to indicate if going to do this, but more discussion since then.


Thomas Stach:

      A lot of arguments indicating doing the updated offer causes problems


      Agreed, which is why we can have the indication.


      So if offerer and answerer don't agree, who gets to decide.



      Wrong place to do it; should be higher in the protocol stack. Should go into the SIP header. What message need to send different from the content in the message.

      Creates a real problem for WebRTC, forces clients to do SDP inspection and figure out what you are required to do.

      Doing with SIP option would be OK



      Can do in either ICE or SIP; ICE can be used without SIP.

      It's also not just about the update offer; there is continuous nomination, etc. all of which you should be able to negotiate the use of. Need some kind of signaling indication (whether in ICE or higher layer)

      Need to decide what the default values are for this.

      Need to make sure it's backwards compatible as well.



      If you have other protocols than SIP; would we also mandate the double O/A exchange?


      Are there non-SIP deployments where this could be an issue?


      Fundamental problem remains that some deployments don't work with the second O/A exchange and others don't work without. How to resolve?


      Need to negotiate which one to use


      Will still need a tiebreaker. We also have other specs that mandate the second O/A exchange. Need to consider the issue more broadly.


Flemming (chair):

      Should raise that point on those drafts.


      Already did on the mailing list.



      Responded to Thomas on mailing list with mechanisms to solve the problems he pointed out. Thomas just hasn't implemented those.  Again, default should be backwards compatible, i.e. what current RFC specifies.



      SDP is not tied to SIP. In terms of signaling, still haven't heard solid arguments as to whether this (negotiation) indication belongs in SDP or outside of SDP. Preconditions is an example where it got coupled too much.


Andrew Hutton:

      Conclusion at the last meeting was that implementations tend to ignore the second O/A. We want to simplify things, this extra negotiation seems to only complicate things.


Lennox (relaying Emil):

      There is work to be done in ICE anyway. Adding an extra indication in ICE doesn't seem like a big deal.


Lennox (for himself):

      Doing it at the SIP level would be fine; don't have a strong opinion.



      It's good to simplify things, but there are people deploying this. Cannot break backwards compatibility

      Fine with adding a mechanism that allows the second O/A exchange to be skipped, but has to be done in a backwards compatible manner.



      Doesn't automatically belong in SIP just because it doesn't belong to SDP.



      Responding to Christer's point about why don't you implement PRACK, preconditions, etc


Flemming (chair)

      Asking for people to focus on how we move forward. Hear a lot of positioning and opinions, including "there is no solution". Need to focus on what we can do.



      It is the middle boxes that need this, so why a mechanism for ends to indicate whether or not it is needed. Feels more like session-timers. Need way for middle boxes to control this.



      There is already plenty of stuff in SIP that forces O/A behavior (e.g. offerless INVITE).



      Suggest to have a separate off-line session on this and see if we can come up with a proposal for way forward. Need to explore the SIP option; if no solution we default back to RFC 5245.



Slide 5 (ICE nomination)



      Agree with Ari's sentiment.  We can make aggressive nomination deprecated in ICE bis and do cleanup on that. Continuous nomination should go to separate document.



      Generally agree with Justin. Also multiple validate pairs. Continuous nomination may belong in trickle draft though.


Martin Thomson:

      Not sure about the multiple validated pairs. Explore EmilÕs proposal separately and see how complex it ends up..



      Think deprecating aggressive nomination should be in ice-bis.



      Does anybody think deprecating aggressive nomination is a bad idea?



      If you can negotiate the use of it in a backwards compatible manner, then OK with it. But middleboxes may prevent this working.



      In good case with this media goes faster, in bad case as fast as currently. But need to do testing with this.



      In the absence of continuous nomination, still need to support "use-candidate".


      Agree; no one seems to think this is a bad idea



      Need to think about it a little more. Why was the "use-candidate" there in the first place (in the spec); should look carefully into



      Agree we should deprecate aggressive nomination. Aggressive nomination seems to have been designed as a redundant mechanism



      Keep in mind aggressive nomination is really being used today because it works and normal nomination is way too slow. Does continuous nomination replace this safely? If not, we will have some last call comments on it. Need to look further into this.



      This new proposal takes care of this


Next steps:

      Pursue looking into the recommendation (not agreed to as final solution yet by all).

      Christer asking for additional write-up and call flows

      Emil, Justin, and Lennox will do write-up and post to the mailing list, Cullen and Ari will review.



ICE IPv4/IPv6 Dual Stack Fairness (PŒl-Erik Martinsen)



PŒl-Erik presented his slides.


Chairs took a show of hands for adopting the document for matching milestone.


For adoption of document: 12

Against adoption: none

Need more information: 2



      Attempted to implement the algorithm. Doesn't work.

      Think it's valuable to work on, but need something that actually works.

      Would like to hear from more implementers (primary problem seems to be with tunneling scenarios).


Flemming (chair) asking if anybody else has implemented it. Only PŒl has; says it works, but has not looked at all the tunneling scenarios Bernard says are problematic.


Zahed Sarker:

      Would like more data on whether this works.



      So can Bernard share what does work so we can use that as the baseline?



      Issue is the broken IPv6 routes (predominated for tunnels). Need to change the way you deal with these, the current proposal results in delays that defeat the purpose; solution may be to de-prioritize IPv6 tunnel addresses



Next steps:

      Defer adoption decision

      PŒl-Erik work with Bernard (and Simon) on the problems Bernard raised.



Using Simulcast in SDP and RTP Sessions (Bo Burman)



Bo presented his slides.


Want WebRTC and CLUE clients to be able to use N encoded streams for one media source AND have SDP interoperable simulcast AND support layered RTX and FEC mechanisms. Not proposing any changes to SDP, just clarifying usage.


Slide 5 (Offer from Mixer to Client)



      Does it require the use of fmtp parameters for all codecs to indicate resolution etc?


      No. Can use SDP as usual. Just need separate payload. Resolution and frame rate



      Need to clarify in draft the usage of codec parameters vs. image attribute


      Don't think the depend line shown is right. 103 should be SVC.


      Key point of example is whether we want to align with the principle of having a payload type to show what you want to send.



      Seems like a reasonable example (with a few minor technical mistakes)



      O/A payload types are receive payload types; don't necessarily have to be the same in the other direction.


      Same semantics as in normal SDP (receive numbers). Answer can use different payload types, as long as the information lines up consistently.



      question on the fmtp; looks inconsistent.


      Just a short-hand notation; not intended to be different or constraining compared to normal SDP.



      Codec parameters versus imageatt is two different things.


Stephen Botzko:

      What about combination of layered and simulcast, only layered, only simulcast?


      covered in draft



      There is an example of simulcast and layered in the draft, so yes, can do it. Seems like it works.



Slide 7 (Answer from Client to Mixer)


[Various clarifying questions]



      Going in the right direction.

      Microsoft declared IPR on draft with very similar text previously, be aware of that.


Bernard to work with his legal team regarding this draft



      Ericsson does not have IPR on this one.


Zahed, Roni, Christer, Cullen supporting the draft


Peter Thatcher

      Not excited about different payload type for each

      Can live with it. Best alternative so far.


Chairs took a hum on taking the document as a WG item.

Strong consensus in favor.


Hum on using draft for this WG item.

Strong consensus in favor.



      Consensus  for adding a new WG work item and adopting this document for that item


Chairs will work with the AD on adding a milestone.



MSRP over SCTP/DTLS & SDP-based "SCTP over DTLSÓ negotiation (Keith Drage)




Keith presented his slides.


Problem Statement: How to negotiate well defined sub protocol over DataChannels. draft-ejzak-mmusic-data-channel-sdpneg-02 is generic one for all protocols, draft-ejzak-mmusic-msrp-usage-data-channel-01 is specific to MSRP, similar draft needed for other protocols to be used over DataChannel.


Proposed Work Plan (slide 17)



      Strongly support it. Very important.

      Have some comments on defining new values; not important right now.



      Generally like the idea.

      This is not applicable to browser implementations

      IANA considerations for dcsa may be a bit tricky (not written yet though). Need to spell out in details which attributes are valid in dcsa attribute.



      action item accepted



      May be some timing issues wrt CLUE (trying to finish up in CLUE)



      Support the work; like it (and important)

      Unclear what the CLUE dependency is. CLUE is in a bit of a hurry.

      Regarding "dcsa"; seems similar to "a=ssrc" and had to define a while IANA registry for that.

      Noting gateway use case as motivation (similar to Christer point earlier).



Chairs took hums for new WG items.


Strong consensus to take on as WG items.


Chairs took hums for adopting the documents:



      Solid consensus to take on document (nobody against or needing more time)

      AD asking how many people have read the document: 10-15



      10-12 people have read

      Solid consensus to take on document (nobody against or needing more time).



      Consensus for adding new WG work items and adopting these documents


Chairs will discuss with AD (and confirm on mailing list).



RTP Payload Format for Forward Error Correction Packets (Mo Zanaty)



Mo presented his slides.



      Need clarity around SSRC handling / use cases in the draft



      Looking for feedback on whether you have to lock-down whether there is a single SSRC or multiple.



      How does this work with simulcast.


      Draft only protects a single source flow currently.

      Premise of draft is RTX; question for the group is whether that is the right premise.


Option 1, associated FEC with streams it repairs using payload types



      Is this to determine which FEC stream goes with which simulcast stream? (yes); Then would be useful to have way to say a FEC stream is protecting all the payload types within a given m-line.



      SSRC in FEC is same as SSRC in stream being protected?


      same as RTX, declare one FEC but that FEC could be used dynamically to protect any of the streams with which it is associated.



      Need to disambiguate in SDP whether FEC needs to be separate SSRC or can be same SSRC multiplexed with stream it is repairing.


      Not allowing one FEC stream protecting multiple source streams (e.g. not protecting multiple simulcast streams).



      Doesn't like the "apt" thing.


      Doesn't always know the SSRC.

      Not allowing one FEC stream protecting multiple source streams (e.g. not protecting multiple simulcast streams)


Option 2, specify SSRCs such that single FEC can be used to protect multiple streams (use SSRCs instead of payload types), using ssrc-group semantics.


Peter Thatcher:

       Prefer this option.

Roni and Bernard:

      This is what is currently defined and used, even if not ideal.



      The unknown SSRC case still exists and needs to be addressed, e.g. requirements addressed by option 1 are important, but may need better solution than option 1.


      Goal is to define mechanism(s) that works for most/all working groups rather than explosion of different mechanisms for each use case.


Next steps:

      work toward agreement on multiplexing and binding source and repair streams in SDP, take to list and capture in this doc