Re: [rtcweb] No Plan

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Thu, 30 May 2013 09:55 UTC

Return-Path: <prvs=1862a96fff=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 4731B21F963A for <rtcweb@ietfa.amsl.com>; Thu, 30 May 2013 02:55:25 -0700 (PDT)
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 in+lk8iaFp1g for <rtcweb@ietfa.amsl.com>; Thu, 30 May 2013 02:55:13 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA2121F96A0 for <rtcweb@ietf.org>; Thu, 30 May 2013 02:55:06 -0700 (PDT)
X-AuditID: c1b4fb30-b7f9e6d000002643-cc-51a721f7aa5b
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7D.B5.09795.7F127A15; Thu, 30 May 2013 11:55:03 +0200 (CEST)
Received: from [150.132.141.62] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Thu, 30 May 2013 11:55:03 +0200
Message-ID: <51A721F6.6090805@ericsson.com>
Date: Thu, 30 May 2013 11:55:02 +0200
From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= <stefan.lk.hakansson@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Bernard Aboba <bernard_aboba@hotmail.com>
References: <51A65017.4090502@jitsi.org> <51A70CBC.5010108@ericsson.com> <BLU402-EAS3768DFFEC379C8EEB254A5693910@phx.gbl>
In-Reply-To: <BLU402-EAS3768DFFEC379C8EEB254A5693910@phx.gbl>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkluLIzCtJLcpLzFFi42KZGfG3Vve74vJAg0f/VSz2L7nMbLH2Xzu7 A5PH454zbB5LlvxkCmCK4rZJSiwpC85Mz9O3S+DOeLT+H1vBfJ6Kg59XMTUwPuLsYuTkkBAw kdg4ZwMjhC0mceHeerYuRi4OIYFTjBJXji5jhnDWMEqsmdDKBFLFK6AtcXXXP6AEBweLgKrE 4dM6IGE2gWCJ/ctBmjk5RAWiJOase8AGUS4ocXLmExaQchEBXYm/XUYgYWYBdYk7i8+xg9jC ArIS167PACsXEqiUWPppJguIzSlgK3Fg2WUmiHoLicVvDrJD2PISzVtnM0PU60q8e32PdQKj 4Cwk22YhaZmFpGUBI/MqRvbcxMyc9HLzTYzAkDy45bfBDsZN98UOMUpzsCiJ8+rzLg4UEkhP LEnNTk0tSC2KLyrNSS0+xMjEwQkiuKQaGA34Or2ldR+a/vq/SWDi1IqWhytEuNa9XObfdrb8 6NF+tYBjdpyVj1uEUgVe379kd8V8XUzEORaedTGFL84bJe5lM5m/p9T+xbL8iY57ix/xyZ/a ayoReOXkHIELlWmmU5csX1r5c9WDHtlgGzthg/Zsl+mTb1QZbrU8/yhH/ZJAmrPktU+yU5VY ijMSDbWYi4oTAQDj40IcAgAA
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:55:29 -0000

On 2013-05-30 11:19, Bernard Aboba wrote:
> 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.

Definitely.

But my point was that unless there is an intention to transport, SSRCs 
are useless (and they only have a meaning if there is RTP involved, 
right?). There are a lot of local use cases for MediaStream's 
(containing MediaStreamTrack's), so it does not make sense to add SSRC 
APIs to those objects; it belongs to PeerConnection IMO.

But when (if) another transport object in JS space than PeerConnection 
is defined, it would also need an API where SSRCs could be accessed.

Stefan

>
>>