W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2015

Fwd: MMUSIC WG Virtual Interim Meeting: October 13, 2015

From: Ted Hardie <ted.ietf@gmail.com>
Date: Tue, 29 Sep 2015 15:48:48 -0700
Message-ID: <CA+9kkMDwUVmzdSkc47hcjPT94=YWVW5s8K+hwQVxsmdc3x3ZJQ@mail.gmail.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>, Ari Keränen <ari.keranen@ericsson.com>, Flemming Andreasen <fandreas@cisco.com>
As we discussed in Seattle, the MMUSIC group is going to hold a virtual
interim to discuss the simulcast work.  It's taken a bit of time to get
that together, but the time and date are as below.


The Multiparty Multimedia Session Control (MMUSIC) working group will hold
a virtual interim meeting on Tuesday, October 13, from 1100 to 1300 EDT.

Participation information and agenda will be announced on the MMUSIC
mailing list. For those that will attend, here is Adam's summary of the
current thinking:

​After significant conversations both at and after the interim WebRTC
> meeting, and considering information about the type of solutions that
> interested parties are likely to find acceptable, a number of the WebRTC
> participants have come up with a tentative proposal that we believe is
> likely to be simple, flexible, and satisfactory to everyone involved. At a
> high level:
>
>
>  * The current behavior described in the MMUSIC simulcast draft remains
> valid.
>
>  * Additionally, we define a new attribute type (provisionally called
> “RID”, for “RTP Stream ID”) that can be used to define additional
> codec-independent constraints on PTs (e.g., max-fps, max-bps,max-width,
> max-height).
>
>  *RIDs can be defined to be unidirectional, so as to allow implementations
> to signal the ability to send a different number of  encodings than they
> can receive.
>
>  * The values for each constraint can be specified to be different in
>    each direction.
>
>  * When used, the RID value is encoded as part of the RTP packet, in an
> extension header.
>
>  * The values (that is, identifiers) used for RID are proposed by the
> offerer in a session, and are symmetric. The RID values in an answer must
> be a subset of those present in the offer.
>
>  * The parameters associated with a RID can be made more restrictive
> (i.e., resolution decreased, bandwidth decreased), but not less
> restrictive, in an answer.
>
>  * For those sessions that use RIDs, the “a=simulcast” parameter is
> enhanced to be able to carry RIDs instead of PTs.
>
> We hope to have an internet-draft that describes this approach in more
> detail by the end of next week.
>
> /a
>
>
​Thanks to the authors and chairs of MMUSIC for pulling this together.

regards,

Ted​
Received on Tuesday, 29 September 2015 22:49:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:46 UTC