Re: [rtcweb] Proposal for API mapping for RTP

[Harald Alvestrand <[e-mail]>]

On 11/22/2013 04:21 AM, Lijing (Jessie) wrote:
> A MediaStream contains multiple MediaStreamTrack, and different MediaStreams can share the same MediaStreamTrack. MediaStreamTrack within one MediaStream is synchronized.
>
> -----Does anywhere define how to describe same MST in different mediastreams in SDP? As I know, the current unified plan defines" One m-line == one MediaStreamTrack", so how can we mark multiple mediastreams in msid attribute?
> Allow msid carry more mediastream id?
> m=video1
> a=msid: ma ta; mb ta
>
> or have multiple msid attribute in one m line?
> m=vido1
> a=msid: ma ta
> a=msid: mb ta
>
> or we should expand other attribute?

My thinking is that the last one is the one to use; I have not defined 
special semantics for semicolons in MSID values, but the spec 
(draft-ietf-mmusic-msid-02) does say that there can be multiple msid 
attributes on a single m-line, and it seems logical to go that route.


>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Magnus Westerlund
> Sent: Friday, November 08, 2013 2:18 AM
> To: [e-mail]
> Subject: [rtcweb] Proposal for API mapping for RTP
>
> WG,
> (As draft-ietf-rtcweb-rtp-usage Editor)
>
> There was discussion yesterday afternoon on the W3C MediaStream to RTP mapping. This did arrive on some conclusions that I here try to word into a proposal for everyones review.
>
> A MediaStreamTrack is sent over a source packet stream (one SSRC) and can have additionally redundancy packet streams (SSRCs). These redundnacy streams are RTP retranmission streams or FEC.
>
> When multiple MediaStreamTracks have the same Media Source, then the fact that one has creaeted multiple MediaStreamTracks and added these through a MediaStream to the PeerConnection is going to result in that each MediaStreamTrack will have its own source packet stream (one SSRC).
> This will be true, even if there are no difference in the configuration of the MediaStreamTrack. Thus no optimizations in regards to collapsing or aggregating multiple MediaStreamTrack onto a single source packet stream (SSRC). This is done for keeping things simple and straightforward.
>
> When it comes to the use of CNAME, an RTCWEB end-point shall within the context of one origin, i.e. a particular JS creating PeerConnections, use the same CNAME in all these PeerConnections, for all outgoing mediaStreamTracks. However, a end-point MUST be capable of receiving multiple different CNAMEs both within and between different RTP sessions and PeerConnections. This definition comes from the following observations.
>
> A MediaStream contains multiple MediaStreamTrack, and different MediaStreams can share the same MediaStreamTrack. MediaStreamTrack within one MediaStream is synchronized. Thus, at any point the JS application can create a new MediaStream that includes MediaStreamTrack from different context. To avoid needing to change all SSRC and put the SSRCs into a single CNAME at that point, we ensure that this can't happen.
>
> MediaStreamTracks that are being received in one PeerConnection and then forward by being added to another one will need to be re-synchronzied into the endpoints outgoing. We discussed and came to the agreement on Monday that forwarding would need to be done equivalent of decoding and recoding when forwarding. Implementations may do other things, but must function equivalent to this.
>
> The above have some forward interoperability properties. If one like to be able to use multiple CNAMEs that can be added given that W3C API ensures that you don't cause issue with what CNAME a particular SSRC belongs to. In addition if one like to optimize the cases where multiple MediaStreamTrack have a common media source that can be added.
>
> Disagreements, requests for clarifications?
>
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb