Re: [MMUSIC] Simulcast: Short timelines, draft impending

[Suhas Nandakumar <[e-mail]>]

Hello All

   As indicated by Adam in his email , we have submitted the draft defining
"RID".

   The draft can be found here:
https://datatracker.ietf.org/doc/draft-pthatcher-mmusic-rid/?include_text=1

   Please provide your feedback on the same.

Thanks
Suhas

On Thu, Sep 24, 2015 at 7:34 PM, Adam Roach <[e-mail]> wrote:

> At the W3C WebRTC interim meeting a couple of weeks ago, one of the issues
> that the group was not able to resolve was how to enable the use of
> simulcast for WebRTC browser implementations. A key point of contention was
> the use of unique payload types for each simulcast encoding in the current
> MMUSIC document (draft-ietf-mmusic-sdp-simulcast-01). Combined with the
> other features planned for WebRTC, there is concern that such an approach
> may lead to PT exhaustion within a session under certain reasonably
> expected circumstances.
>
>
> As important context: the WebRTC 1.0 specification is rapidly approaching
> finalization, and the working group hopes to leave the TPAC meeting at the
> end of October with all of the loose ends tied up. Simulcast is one of the
> more important and one of the most loose ends in the specification at the
> moment. As a result, we sincerely hope that we can come to consensus on a
> viable approach in MMUSIC over the next few weeks. To be explicit: the TPAC
> meeting is the week before the Yokohama IETF meeting, so we cannot afford
> to wait for the ordinary meeting-driven work schedule to push simulcast
> along. We hope to foster a useful and productive conversation on the
> mailing list well ahead of IETF 94.
>
>
> While there were some “hallway discussions” in Prague to discuss potential
> approaches that would address these concerns, none of these have yet been
> documented and shared with the mailing list.
>
>
> 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
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>