Re: [rtcweb] Proposal for API mapping for RTP

Stefan Håkansson LK <> Sun, 10 November 2013 09:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5520C21E8064 for <>; Sun, 10 Nov 2013 01:32:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mKGkjDqC4bFx for <>; Sun, 10 Nov 2013 01:32:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B307421E8056 for <>; Sun, 10 Nov 2013 01:32:42 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-18-527f52b48ad4
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 7E.4B.03802.4B25F725; Sun, 10 Nov 2013 10:32:36 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Sun, 10 Nov 2013 10:32:35 +0100
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <>
To: Magnus Westerlund <>, "" <>
Thread-Topic: [rtcweb] Proposal for API mapping for RTP
Thread-Index: AQHO2+XFKCOjbayppUaIHGN4PDMgyw==
Date: Sun, 10 Nov 2013 09:32:35 +0000
Message-ID: <>
References: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUyM+Jvje6WoPogg7mNIhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY+mrrawFu9Qq7mw4x9bAeEW+i5GTQ0LARGLp6sssELaYxIV7 69m6GLk4hAQOMUp0tF6GcpYwSiy4u5wZpIpNIFBi674FbCC2iECsxPvZV1lBbGEBM4lrfyax QsTNJWb8XcgCYetJ3F20iAnEZhFQlehb9ZAdxOYV8JW4eHs2WFxIQFtiyYvzjCA2I9AV30+t AYszC4hL3HoynwniOgGJJXvOM0PYohIvH/9jhbCVJBqXPGGFqNeTuDF1ChuErS2xbOFrZohd ghInZz5hmcAoMgvJ2FlIWmYhaZmFpGUBI8sqRvbcxMyc9HKjTYzAAD+45bfqDsY750QOMUpz sCiJ83546xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdEpNoK9aI7vJRPZiOp984Qu+PXt j1k86fL7r/t7HGduqtGwPnFIcz3b7d0flrtqKe74k1u6VHEag+JvJWW56ZLLXv63mFHgvaUp 8Lah8cUdC756sS2dHPdHvfyU5/5dTMGb2n8zmT2Lr/2h9fa1dSZLWMVOiQU+NXpzC5r+Miya tpmh/n5lyVolluKMREMt5qLiRABP7IXRPgIAAA==
Subject: Re: [rtcweb] Proposal for API mapping for RTP
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 10 Nov 2013 09:32:48 -0000

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


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


> Disagreements, requests for clarifications?
> Cheers
> Magnus Westerlund
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto:
> ----------------------------------------------------------------------
> _______________________________________________
> rtcweb mailing list