Re: [rtcweb] No Plan

Emil Ivov <emcho@jitsi.org> Fri, 31 May 2013 17:56 UTC

Return-Path: <emil@sip-communicator.org>
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 1543021F8F83 for <rtcweb@ietfa.amsl.com>; Fri, 31 May 2013 10:56:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 vyGOmLKOejkH for <rtcweb@ietfa.amsl.com>; Fri, 31 May 2013 10:56:15 -0700 (PDT)
Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1A621F8E79 for <rtcweb@ietf.org>; Fri, 31 May 2013 10:56:11 -0700 (PDT)
Received: by mail-bk0-f51.google.com with SMTP id ji1so912890bkc.10 for <rtcweb@ietf.org>; Fri, 31 May 2013 10:56:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=AHU5/veni9joeHqKRCHFY4VH6CTXvjqNwx8qo6IcrVY=; b=Ey9Ehuzs2G4amQ2fq0gYGB4xTw8qn8nkqG8j3bTcoSah7GRfCRCc0t2hUYPAtTTQDS 6fXpQMJW6SLd0TvrHtu7vqeDz7dqHdiORTjcv8AkQrWCvjxtSy582s8h6+Fz6kq+ESNn nEx6lGC7w6cY9py/t0+lbMW/8ARDgX2rvnitQfoS+BRYWcJOBjRUUPiskNZ9UYVj7YoT z4RT17dM0wRqOY/+7LeZ/tvDeTxsIjyFW3aHD1heJEgbB1x1PDDl4N+gpG2j+/22kZ1S lLV2/sdp/U2o+vMkdoODLQH9sMkzZ5pQ+5UlSFMlv3DV+/hEWKt+xYBCUJJxft9GvTxZ Iapg==
X-Received: by 10.205.113.16 with SMTP id eu16mr3732085bkc.109.1370022970356; Fri, 31 May 2013 10:56:10 -0700 (PDT)
Received: from camionet.local ([83.228.77.158]) by mx.google.com with ESMTPSA id og1sm11819674bkb.16.2013.05.31.10.56.08 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 May 2013 10:56:09 -0700 (PDT)
Message-ID: <51A8E434.1020904@jitsi.org>
Date: Fri, 31 May 2013 20:56:04 +0300
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
References: <51A65017.4090502@jitsi.org> <51A70CBC.5010108@ericsson.com>
In-Reply-To: <51A70CBC.5010108@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnjIsx1KNRqvFmMIeC+/u2jUlfCDP6bzXIwUyBNqEwzjISTdwlTdRYvJOYamvNR89qu3t2O
Cc: 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: Fri, 31 May 2013 17:56:16 -0000

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.

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

> 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 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.

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
>

-- 
https://jitsi.org