[rtcweb] Proposal for API mapping for RTP

[Magnus Westerlund <[e-mail]>]

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