Re: [MMUSIC] Remove msid-semantic

[Harald Alvestrand <[e-mail]>]

On 03/31/2015 06:32 PM, Martin Thomson wrote:
> On 31 March 2015 at 02:07, Magnus Westerlund
> <[e-mail]> wrote:
>> Just to be clear here and ensure that I haven't missed anything. RTP
>> usage requires all WebRTC endpoint to provide synchronization
>> information when sending. However, it is up to the receiver to decide if
>> they want to synchronize the playout. Thus this LS group would only be
>> there to indicate a strong preference by the sender that the receiver
>> should/shall playout in synchronization?
>
> Correct, the information in RTP will make it possible to synchronize
> tracks, but whether that is acted upon will ultimately depend on
> whether the tracks are rendered in the same stream.  I think that the
> intent with the LS groups is to make this clear, not just to a WebRTC
> receiver, but to legacy receivers as well.
OK, here is how the section on handing unsignalled tracks looks when 
I've removed msid-semantic.

Note that depending on exactly how we do early media, this may cause 
trouble in delivering it.

3.1.  Handling of non-signalled tracks

    Entities that do not use msid will not send msid.  This means that
    there will be some incoming RTP packets that the recipient has no
    predefined MediaStream id value for.

    Note that this handling is triggered by incoming RTP packets, not by
    SDP negotiation.

    When MSID is used, the only time this can happen is when, at a time
    subsequent to the initial negotiation, a negotiation is performed
    where the answerer adds a MediaStreamTrack to an already established
    connection and starts sending data before the answer is received by
    the offerer.  For initial negotiation, packets won't flow until the
    ICE candidates and fingerprints have been exchanged, so this is not
    an issue.

    The recipient of those packets will perform the following steps:

    o  When RTP packets are initially received, it will create an
       appropriate MediaStreamTrack based on the type of the media
       (carried in PayloadType), and use the mid RTP attribute (if
       present) to associate the RTP packets with a specific media
       section.  If the connection is not in the RTCSignalingState
       "stable", it will wait at this point.

    o  When the connection is in the RTCSignalingState "stable", it will
       look at the relevant media section to find the msid attribute.

    o  If there is an msid attribute, it will use that attribute to
       populate the "id" field of the MediaStreamTrack and associated
       MediaStreams, as described above.

    o  If there is no msid attribute, the identifier of the
       MediaStreamTrack will be set to a randomly generated string, and
       it will be signalled as being part of a MediaStream with the
       WebIDL "label" attribute set to "Non-WebRTC stream".

    o  After deciding on the "id" field to be applied to the
       MediaStreamTrack, the track will be signalled to the user.

    The process above may involve a considerable amount of buffering
    before the stable state is entered, If the implementation wishes to
    limit this buffering, it MUST send a "mediadiscarded" event to the
    user, as described in [????].