Re: [rtcweb] No Plan

Bernard Aboba <bernard_aboba@hotmail.com> Thu, 30 May 2013 09:19 UTC

Return-Path: <bernard_aboba@hotmail.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 C6F3221F97A0 for <rtcweb@ietfa.amsl.com>; Thu, 30 May 2013 02:19:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level:
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
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 IDpYje28UetG for <rtcweb@ietfa.amsl.com>; Thu, 30 May 2013 02:19:41 -0700 (PDT)
Received: from blu0-omc3-s6.blu0.hotmail.com (blu0-omc3-s6.blu0.hotmail.com [65.55.116.81]) by ietfa.amsl.com (Postfix) with ESMTP id EB53521F978B for <rtcweb@ietf.org>; Thu, 30 May 2013 02:19:40 -0700 (PDT)
Received: from BLU402-EAS376 ([65.55.116.73]) by blu0-omc3-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 May 2013 02:19:40 -0700
X-EIP: [vDzF4e0aEiKPijEP5b9MKh59i7oMAi+W]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU402-EAS3768DFFEC379C8EEB254A5693910@phx.gbl>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
References: <51A65017.4090502@jitsi.org> <51A70CBC.5010108@ericsson.com>
From: Bernard Aboba <bernard_aboba@hotmail.com>
MIME-Version: 1.0 (1.0)
In-Reply-To: <51A70CBC.5010108@ericsson.com>
Date: Thu, 30 May 2013 02:19:39 -0700
To: =?utf-8?Q?Stefan_H=C3=A5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
X-OriginalArrivalTime: 30 May 2013 09:19:40.0298 (UTC) FILETIME=[D02396A0:01CE5D16]
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] No Plan
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, 30 May 2013 09:19:46 -0000

Comments below.

On May 30, 2013, at 1:24, "Stefan Håkansson LK" <stefan.lk.hakansson@ericsson.com> wrote:

> Hi Emil,
> 
> a couple of comments:
> 
> "1.  Expose the SSRCs of all local MediaStreamTrack-s that the
>       application may want to attach to a PeerConnection."
> 
> I don't think that would be possible, or desirable. SSRC _only_ come into play when a MediaStreamTrack is to be transported over the network - it is useless in local cases. And, the same local MediaStreamTrack could be sent to several peers (using different PeerConnections) and could have different SSRC's (and even different number of SSRC's) for the different peers.
> 
> I think SSRCs would only be available for MediaStreamTracks that are attached to a PeerConnection.

[BA] If ICE fails, it may be necessary to use alternative transport, outside of PeerConnection. So if SSRCs are to be used in signaling for that case, the API needs to make them available.

>