Re: [rtcweb] No Plan

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Sat, 01 June 2013 05:23 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 6B30021F86BB for <rtcweb@ietfa.amsl.com>; Fri, 31 May 2013 22:23:11 -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 V08EydlpR1BB for <rtcweb@ietfa.amsl.com>; Fri, 31 May 2013 22:23:04 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAE921F85EF for <rtcweb@ietf.org>; Fri, 31 May 2013 22:23:03 -0700 (PDT)
X-AuditID: c1b4fb25-b7f4c6d000004656-cc-51a98535f018
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D8.00.18006.53589A15; Sat, 1 Jun 2013 07:23:01 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Sat, 1 Jun 2013 07:23:01 +0200
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
To: Emil Ivov <emcho@jitsi.org>
Thread-Topic: [rtcweb] No Plan
Thread-Index: AQHOXJ6wvy+3t7Ib3U6qANONjzQMzw==
Date: Sat, 1 Jun 2013 05:23:00 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2DB39E@ESESSMB209.ericsson.se>
References: <51A65017.4090502@jitsi.org> <51A70CBC.5010108@ericsson.com> <51A8E434.1020904@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.146]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvra5p68pAg5Vr9S3W7JzAYrH2Xzu7 A5PHkiU/mTz+vwkMYIrisklJzcksSy3St0vgynhw4QpbwQL1istLZ7E0ML6W72Lk5JAQMJFo uPiOCcIWk7hwbz1bFyMXh5DAYUaJyZ1/GSGcxYwSLzbNYgOpYhMIlNi6bwGYLSIgL9Hdtgis m1lAXeLO4nPsILawgKzEteszoGrkJK7/3Adl60m8efEFqIaDg0VAReL3B0GQMK+Ar8Tmzutg JUIC6RJLrt5lBLEZgQ76fmoN1HhxiVtP5kMdKiCxZM95ZghbVOLl43+sELaSxI8Nl1gg6vUk bkydwgZha0ssW/iaGWKXoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKkT03MTMnvdxoEyMw Eg5u+a26g/HOOZFDjNIcLErivHq8iwOBPkgsSc1OTS1ILYovKs1JLT7EyMTBKdXAWH8xzVTt RMWbjCUHb3CvtnsasG2KmFhp5/0/MpOC2++1Mwlz/rb/9PZnifXiikVe79tf3D6/4UpS/6m2 GdGbGaM/PldZlJWtNOEfd35son+RbOv+7r3ccbI6Dx02el+9c+R2zBcXO/drOx3mbHF823j/ Q+u11zz6q1ON0rsXrNZ6uevqCsnt+kosxRmJhlrMRcWJAB12ABlSAgAA
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: Sat, 01 Jun 2013 05:23:11 -0000

Hej Emil,

On 5/31/13 7:56 PM, Emil Ivov wrote:
> Hey Stefan,
>
> On 30.05.13, 11:24, Stefan Håkansson LK 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.
>
> I believe Paul already commented on this but just to be clear: yes I
> agree that SSRCs would only make sense for tracks that are actually
> going on the network, so the API methods that give access to them would
> have to take this into account.

Yes, I think we're in agreement.

>
>> One thing I like about Plan A and B is that the naive application
>> developer does not have to deal with things below MediaStream and
>> MediaStreamTrack level.
>
> I don't think this is any different with "No Plan". Is there a
> particular scenario that you think would not work?

No, it was only that when I read the proposal it was unclear to me if it 
would work this way. Let me put it this way: I like it to work in the 
way that the MediaStream's and MediaStreamTrack's on the sending side 
are reflected at the receiving side sort of automatically (i.e. apps 
should not have to deal with stuff like PTs, SSRCs to make it happen - 
just forward opaque blobs).

>
>> The application would simply add a MediaStream
>> (containing MediaStreamTracks) to the PeerConnection, do the
>> createOffer/setLocal and exchange signaling blobs that it need not look
>> into, and the MediaStream with MediaStreamTrack's would be reflected at
>> the remote end. The application would not have to deal with PT's, SSRC's
>> etc.
>
> Note that No Plan does not suggest that PT's be taken up to the
> application. As for SSRCs, those would just serve as identifiers and
> shouldn't bother developers that don't care about them.

I probably misunderstood something here.

>
>> I think that the "No Plan" proposal could be made similar if the info
>> about how MediaStreamTrack's relate to SSRC's (including those for FEC
>> and RTX) is exchanged using some blobs that the (naive) app can just
>> exchange and need not look into.
>
> I was indeed hoping that we could push FEC and RTX down to the RTP layer
> for the applications that wouldn't want to be bothered. As for the SSRC,
> the point of making them available to applications would be so that they
> could use them so I don't think that putting them into blobs would
> change anything.
>
>
>> If done that way, "No Plan" seems to me to be quite similar to Plan B,
>
> It definitely has a lot in common with Plan B, and it's all about
> relaxing its constraints so that applications who want to handle
> signalling a bit differently could do so.

I have nothing against that!

Cheers,
Stefan

>
> Cheers,
> Emil
>
>
>
>
>
>> On 2013-05-29 20:59, Emil Ivov wrote:
>>> Hey all,
>>>
>>> Based on many of the discussions that we've had here, as well as many
>>> others that we've had offlist, it seemed like a good idea to investigate
>>> a negotiation alternative that relies on SDP and Offer/Answer just a
>>> little bit less.
>>>
>>> The following "no plan" draft attempts to present one such approach:
>>>
>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan
>>>
>>> The draft relies on conventional use of SDP O/A but leaves the
>>> intricacies of multi-source scenarios to application-specific
>>> signalling, with potentially a little help from RTP.
>>>
>>> Hopefully, proponents of Plans A and B would find that the
>>> interoperability requirements that concerned them can still be met with
>>> "no plan". Of course they would have to be addressed by
>>> application-specific signalling and/or signalling gateways.
>>>
>>> Comments are welcome!
>>>
>>> Cheers,
>>> Emil
>>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>