[rtcweb] Proposal for API mapping for RTP

Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 07 November 2013 18:18 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4886711E821B for <rtcweb@ietfa.amsl.com>; Thu, 7 Nov 2013 10:18:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.556
X-Spam-Status: No, score=-105.556 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id qsTHH5F87mdw for <rtcweb@ietfa.amsl.com>; Thu, 7 Nov 2013 10:18:21 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se []) by ietfa.amsl.com (Postfix) with ESMTP id 1C05721E8173 for <rtcweb@ietf.org>; Thu, 7 Nov 2013 10:16:10 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-7d-527bd8e72ac7
Received: from ESESSHC007.ericsson.se (Unknown_Domain []) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C5.59.23787.7E8DB725; Thu, 7 Nov 2013 19:16:07 +0100 (CET)
Received: from [] ( by smtp.internal.ericsson.com ( with Microsoft SMTP Server id 14.2.328.9; Thu, 7 Nov 2013 19:16:06 +0100
Message-ID: <527BD94C.2070900@ericsson.com>
Date: Thu, 7 Nov 2013 10:17:48 -0800
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAJMWRmVeSWpSXmKPExsUyM+Jvje7zG9VBBuc/61us/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujK428YL9EhVTW/ewNTCuEuli5OSQEDCReLmjkwXCFpO4cG89 WxcjF4eQwCFGiSNd+9khnGWMEpf+/QWr4hXQlvjV+owNxGYRUJG48HobK4jNJmAhcfNHI1hc VCBY4vyrxewQ9YISJ2c+AesVEVCXuPzwAlCcg0NYQFPiyxMXEFNCQFyipzEIpIJZQE9iytUW RghbXqJ562xmEFsIaGtDUwfrBEb+WUiGzkLSMgtJywJG5lWM7LmJmTnp5YabGIGhdHDLb90d jKfOiRxilOZgURLn/fDWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD48yca8LSQn+2Ks2P yeMoT3uvP3uZRGZS7Dmlno06R6pNm4wmSXfc/O0bfDU66HccC4fuLzs2i47y/I/eLywsVvLx taSlWPTPW+EbWRooFn+1YZHVmf3X42R8rV78evvE6obaMYdPC+8urxfw0JlS7R/Q9NNjmXPh mw6nm0tYTd7OD528sHuhEktxRqKhFnNRcSIA59PoqvMBAAA=
Subject: [rtcweb] Proposal for API mapping for RTP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Nov 2013 18:18:28 -0000

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


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: magnus.westerlund@ericsson.com