Re: [MMUSIC] WGLC on draft-ietf-mmusic-msid-10

[Magnus Westerlund <[e-mail]>]

Hi,

I have reviewed this document, although I am late I thought I would 
provide my comments.

1.

Section 2:

   "There may be multiple msid attributes in a single media description.
    There may also be multiple media descriptions that have the same
    value for identifier and application data."

Section 3:

   "If two different media descriptions have MSID attributes with the
    same values for "msid-id" and "msid-appdata", it means that these two
    media descriptions are both intended for the same MediaStreamTrack.

    So far, no semantic for such a mixture have been defined, but this
    specification does not forbid the practice."

So this text discusses two different cases. Lets take them one at a time.

A single media description (m=) with multiple MSID:

I think the semantics of what this means is quite clear as long as the 
media description carries source media rather than redundancy data. That 
would mean that a single media source is actually having multiple 
identities in W3C land. That, do make sense, but we have a decision that 
initially we would not allow this optimization and that is encoded in 
draft-ietf-rtcweb-rtp-usage in Section 11, and I quote:

   "It is important to note that the same media source can be feeding
    multiple MediaStreamTracks.  As different sets of constraints or
    other parameters can be applied to the MediaStreamTrack, each
    MediaStreamTrack instance added to a RTCPeerConnection SHALL result
    in an independent source packet stream, with its own set of
    associated packet streams, and thus different SSRC(s)."

So, this could be changed in the future. But we have no idea how we move 
from what we currently have to such a world. I frankly know if allowing 
this usage today is better than forbidding it. If we would change it we 
have the issue that you either fail silently when offering an old client 
the behaviour or getting a signalling failure. I think getting an error 
would be better as that enables one to correct it.

For the second case: Multiple media description (m=) with the same MSID:

This could come in two flavours from my perspective. The first one is 
that the MSID lines are only applied to media description that carries 
source streams. That would mean that one uses some type of scalability 
or other feature that have parts of the encoding sent in different RTP 
streams, and that these RTP streams are not part of the same RTP 
session, otherwise all the SSRCs would be in the same media description.

The second flavour would be to have also redundancy streams to have MSID 
attributes on the media descriptions that represent cases where they are 
send in other RTP sessions. I think this can be avoided as we already 
are using other grouping mechanism to group the encoded stream(s) with 
the redundancy streams.

I would note that assuming that there will be some mechanism that groups 
the related encoded streams, using MSID for that would be redundant. 
Thus, I don't currently see a need for this. However, in this case I 
can't see a negative issue with this case, other than bloating the SDP.

To conclude, I don't like it being allowed, but not specified. I think 
it might be better to indicate that this might be a future extension 
dimensions and make clear that if this occurs an implementation raises 
an error. With the one-way declarative nature of the information the 
attribute itself can't be used to signal the issue in an answer.

cheers

Magnus Westerlund



Flemming Andreasen skrev den 2015-06-25 23:52:
> Greetings MMUSIC
>
> This is to announce a 2 week WGLC on the msid-10 draft:
>
>      https://tools.ietf.org/html/draft-ietf-mmusic-msid-10
>
> as Proposed Standard. Please review and provide any comments you may
> have on the document by Thursday, July 9, 2015. Comments should be sent
> to the document authors and the MMUSIC WG list. If you review the
> document but do not have any comments, please send a note to that effect
> as well.
>
> Thanks
>
> -- Flemming (MMUSIC co-chair)
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>


-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------