Re: [rtcweb] Proposal for API mapping for RTP

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Sun, 10 November 2013 09:32 UTC

Return-Path: <stefan.lk.hakansson@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5520C21E8064 for <rtcweb@ietfa.amsl.com>; Sun, 10 Nov 2013 01:32:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKGkjDqC4bFx for <rtcweb@ietfa.amsl.com>; Sun, 10 Nov 2013 01:32:43 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B307421E8056 for <rtcweb@ietf.org>; Sun, 10 Nov 2013 01:32:42 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-18-527f52b48ad4
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 7E.4B.03802.4B25F725; Sun, 10 Nov 2013 10:32:36 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Sun, 10 Nov 2013 10:32:35 +0100
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Proposal for API mapping for RTP
Thread-Index: AQHO2+XFKCOjbayppUaIHGN4PDMgyw==
Date: Sun, 10 Nov 2013 09:32:35 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3D5EF5@ESESSMB209.ericsson.se>
References: <527BD94C.2070900@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.148]
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-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: 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)

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  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>