[MMUSIC] Simulcast: Short timelines, draft impending

[Adam Roach <[e-mail]>]

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