Minutes of the Meeting: MMUSIC Working Group Virtual Interim meeting, 13th October 2015

 

The MMUSIC working group had a virtual interim meeting on October 13th, 2015 from 15:00 to 17:00 UTC.

 

The virtual interim was chaired by Flemming Andreasen and Ari Keränen

Ben Campbell and Alissa Cooper attended as Area Directors.

Ted Hardie and the chairs took notes.

 

The meeting was recorded in WebEx. The recording of the session is available at the following URL:

https://cisco.webex.com/ciscosales/lsr.php?RCID=675ea3c9403f49d5865382f7b67693cd

 

Below is the final agenda:

 

1. (10 min) Refresher on simulcast -01 design using PT to identify encodings.

2. (10 min) Potential problem of PT exhaustion in complex simulcast scenarios. Agree it is a real problem that must be solved.

3. (20 min) Propose new identifier (RID) to identify encodings (in combination with PT).

4. (40 min) Review key design points of RID attribute and header extension.

 - Identifier value: integer or UTF-8?

 - PT binding: allow wildcard?

 - Common codec parameters (as further constraints on PT): max-width, max-height, max-fs, max-fps, max-pps, max-bps.

 - Dependencies for scalable layers.

 - Directionality: uni only or allow bi?

 - RID as SDES item or not

5. (40 min) Review simulcast -02 design using RID.

 - Mandatory or optional to implement?

 - Mandatory or optional to use in offers/answers?

 - Directionality: explicit or implicit?

 - Negotiation of PT or RID identification for simulcast

 

 

Chairs reviewed note well and reminded the attendees that one of the documents did have an IPR declaration, already available on the IETF IPR pages.  They also noted that there would be a recording.

 

Chairs reviewed the agenda and asked if there were any changes?  None, and they then asked for presenters.

 

Mo Zanaty presented slides from IETF #91 for the refresher.

 

The main use case is the Simulcast of HD + thumbnail to Mixer.  Of course, there are other use cases, but this illustrates the need. Note that the Simulcast is upstream only in this primary use case, as the mixer sends non-simulcast streams appropriate to the current primary speaker and associated attendees.  For this to work, the mixer must be able to state that it wants to receive simulcast streams and the client must be able to state that it is sending simulcast streams.  In the -01 draft design, payload type was used to specify the simulcast streams.  The payload type number is used to indicate which stream a set of payload type characteristics applies to, and then a “a=” line indicates simulcast and the directionality (a=simulcast send streamr#; otherstream#; recv stream#).

 

The limitations of this approach is that because you using a payload type, there is a risk that you may exhaust the available payload types.  The -02 draft addresses this issue, and the group then started to review section 10.1 of draft-pthatcher-mmusic-rid-00.  This highlighted the situation when the payload types may become pressured or exhausted.  The key issue is that multiple supported codecs and resolutions over even a relatively small pool of participants will exhaust the primary dynamic space.  It could be argued that another possibility is going to secondary and tertiary spaces, but there are issues with clients being robust in their usage of these payload types.  Mo reviewed the use of MID as a demultiplexing tool, and he noted in particular the case where there are different window sizes whose constraints must be expressed.  Colin asked whether there were issues with 127 payload types as a limitation, rather than 32; there are such cases, but Mo noted that he had been convinced with exhaustion as a problem at 32, because of client limitations.  Adam noted that he believed that there were realistic cases where exhaustion of 127 was a possibility.  Paul Kyzivat asked if this was a limitation only during negotiation, but did not need to affect the usage on the wire?  Mo replied that some clients may want to be agile during the call, so we cannot assume that this is the case.  Adam said that he believed that solving that problem with something other than RID was likely going to be equally complex and might not solve the full set of issues.  Cullen noted that there may be clients for whom the PT design is adequate, even though there clearly were cases where it is not.  Mo noted that he would have questions later on what needed to support.

 

Cullen and Colin are not entirely convinced that exhaustion of the full 127 will be common.  Magnus noted that he did not see exhaustion for the classical uses of payload type, but if the payload type is used for all constraints, there would be problems with some use cases. 

 

Flemming asked the counter question: who does believe that there are exhaustion cases?  Jonathan said he believed that a minor modification of both examples would show it; Peter agreed with Jonathan.  Adam noted that things are multiplicative in nature and so it is not hard to imagine.  Ted agreed with Adam.  Mo was asked his opinion, and he noted that he is quite convinced with 32 and is less convinced with 96, but thinks we have to solve it even with 32.  Cullen clarified that he is supportive of something like RID, because he believes that there are cases which will need it, he just notes that there are also cases which do not.  Colin also noted that he was asking for clarity on the point of how many will be exhausted, and if people are convinced that we may exhaust 100, then we should solve it.

 

Suhas noted that he is not hearing objections to discussion of RID, but that there may be questions of whether it is mandatory.  Flemming said that we would go ahead with discussion of RIDs and how they solve the problem.

 

Mo then reviewed section 5 of the draft, noting that it is a new attribute, which is an identifier (not clear yet whether integer or string); it provides a direction and the payload types to which it applies (fmt-list), and then a list of rid-attributes.  The current definitions are video parameters, but a future update will address how to use this with audio.  Flemming asked about the requirements with backwards compatibility--is this compatible with offer/answer?  Mo clarified that you can’t guarantee that the other side will support RIDs.  If you need to express constraints on payload types, you have to make sure that you specify the payload types sufficiently to support fmt-level set up properly for interop.  You won’t be able to do everything RIDs do when providing interoperability with non-RID-aware endpoints.  Mo then reviewed section 6 of the draft, which describes rid-level attributes that function as media constraints.  There was some discussion of whether the subtly different ways to express constraints will work together.  Adam noted that the intention for RID at least is that these are constraints that are applied “on top” of anything else that has already been done in a payload-type specific constraint.  Flemming noted that we need to spend some time at the various different ways of using these constraints; they may solve different problems, but they may interact and we need to think about that.  Using both at the same time may have some interactions, and we need to understand them; Jonathan noted that there are more attributes that have this characteristic.  Mo replied that we can clarify that these are always “on top” of existing constraints and describe the conflict resolution possibilities.  Mo stated, though, that we need to be clear about whether RIDs are going to be a general-purpose method for common constraints or whether they should be limited to exhaustion cases.  Jonathan asked whether you mean non-simulcast cases?  Mo noted that the draft is independent of simulcast.  Jonathan asked what are the other use cases for it?  Mo cited association of primary and secondary streams might be a useful way to do that association, even outside of simulcast.  He believes that there are niceties for having this, but no necessities. Peter said that he can’t see use cases outside simulcast; this is only for cases where you have more than one layer. 

 

Magnus asked for clarification on the use cases and intended scalability.  Peter said that he felt it was valid to limit the discussion to simulcast (Jonathan added “...and Multiple RTP stream Single Transport - MRST”, as they are very similar).

 

Some discussion of application of RID media attribute specific constraints being used for cases where fmtp constraints cannot be used, but the authors really don’t want to boil the ocean.  But there is some thought to using it outside of simulcast.  Colin said that it is that which makes him want to think about interactions now.  Mo said that he thought once this was specified it could be advice to future payload.  The group then revisited the question of feature interaction and how you handle the cases where an answerer does not support RID.  Mo agreed that more text on these points would be useful. 

 

After discussion of agenda, the group turned to section 12.1 and 10.2 of the draft, reviewing the usage of RID in simulcast.  Note that in the draft this is not in lieu of payload types, it is in addition (you can list either payload types or RIDs).  There was discussion of how backwards compatibility works. Participants noted that the simulcast has no backwards compatibility issue yet because it does not exist.  Review of the RID line noted that it may be possible to omit “pt=*”.   After a review of the use of the RIDs in the simulcast space, the group turned to the question in Peter Thatcher’s slides:

 

Is RID an SDES item or not?  This would point to RID being an UTF-8 string, rather than an integer (also potentially favored by the WebRTC discussion to associate meaning with the RID). Cullen asked about the potential impact on stream size of making these strings; Jonathan noted that you can always use short, single byte strings.  Mo said that he thought the parallel with MID here was a strong reason to use UTF-8.  Cullen agreed that if we can use short strings for the common case, then he was okay.  Adam is anyone arguing for integer?  He had been in the camp, but has decamped.  No one was arguing for it, and the group believes that UTF-8 string is correct.  The group also said that “pt=*” was allowable and the omission of pt might even be taken as the wildcard.  The group then asked whether the presented list was a reasonable starting list, given that description of interaction will be fleshed out.  Jonathan commented that we need to be very clear that we align on what bps semantic is meant here, since there is more than one possibility.

 

The group then turned to the question of extensibility.  Is there a strawman extension in mind?  No, if we had something useful, it would likely go in.  Colin asked whether the extensions were meant to always be broadly useful or might be codec-specific?   In the interest of time, this was moved on. 

 

Directionality is now one-way, where it was originally possible to use bi-directional.  Note that you may remove RIDs, but cannot add RIDs.  Jonathan asks about updated offer.  Adam noted that the offerer would provide a comprehensive list of what he is willing to send, so adding a RID in the answer makes no sense.  Directionality of simulcast is also still there and the authors believe it should be explicit in both (rather than inferring simulcast direction from RID).

 

The group then turned to mandatory versus optional.  Cullen noted that the WebRTC context is different from the general context, and that it might say “mandatory to implement” where MMUSIC did not.  Jonathan notes that it may not symmetric for sending/receivers. 

 

Suhas asked if there was a message to send back to WebRTC.  Ted then said he expected to send something to WebRTC saying that there was clearly more discussion to be had but that the -02 draft appeared to be a likely base for future work here on simulcast.  Flemming, with chair hat on, then said he felt like it was early days yet and that more discussion was needed; he expected to have that discussion in Yokohama at least.  Adam noted that the draft deadline was Monday, so updates based on today’s discussion needed to be in quickly.

 

The interim meeting ended at 17:00 UTC.