Re: [rtcweb] Proposal for API mapping for RTP

[Stefan Håkansson LK <[e-mail]>]

On 07/11/13 19:18, Magnus Westerlund wrote:
> WG,
> (As draft-ietf-rtcweb-rtp-usage Editor)

Magnus,

thanks for this write up. Some comments inline.

>
> 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.

Can't there be enhancement packet streams as well (for layered codecs)?

And in some proposals a single MediaStreamTrack can be sent in more than 
one encoding (UA - as opposed to JS handled - handled simulcast) - is 
that covered?

>
> 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.

I think this is the right way to do it.

>
> 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

s/contains/can contain/

> MediaStreams can share the same MediaStreamTrack. MediaStreamTrack
> within one MediaStream is synchronized. Thus, at any point the JS

"synchronized _at playout_"?
> 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.

By stating that all SSRC's originating from an endpoint shall use the 
same CNAME? (Just for clarification)

>
> 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.

Could you expand a bit? Do you mean that if there is an API to alter 
CNAMEs (and I guess there is: SDP mangling) it must ...do what?

> In addition if one like to optimize the cases where multiple
> MediaStreamTrack have a common media source that can be added.

This is not so simple. E.g. assuming we will support pause/resume at 
some point, that could be quite complex if you pause one 
MediaStreamTrack but not another - both using the same source.

The application can already optimize by only sending it once (and clone 
- if required - at the receiving end).

Stefan



>
> 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
>