Re: [rtcweb] A problem with both A and B

Emil Ivov <emcho@jitsi.org> Mon, 20 May 2013 09:00 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 A5CA321F901B for <rtcweb@ietfa.amsl.com>; Mon, 20 May 2013 02:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level:
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599]
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 I2pEe4F7Xx+l for <rtcweb@ietfa.amsl.com>; Mon, 20 May 2013 02:00:07 -0700 (PDT)
Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id CAA4421F8437 for <rtcweb@ietf.org>; Mon, 20 May 2013 01:31:00 -0700 (PDT)
Received: by mail-bk0-f54.google.com with SMTP id it19so2719351bkc.41 for <rtcweb@ietf.org>; Mon, 20 May 2013 01:30:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received: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=Jk+UyE8QvK7CWkT3IHBhHCxpWKh5KwLaFo3bszQ8ExM=; b=jixsySDcFu+6vRRpejAPqDRFEehgg8W9sWRmLXJXHCG+A37bAR5UAGPSOeP30HM3+q dJ44QuFzRMa23r//VweyYfEIp3UbIewwZrEfhYur0UPEhsZ5VIFcVVqgNBa7gqza5GMP m1nSI7X0MpZMb2crhW7mjLjK/owgEzfLXQs7rK80S3abDV2Ux5MEyvMaZokrlzV/ROCs bFPyJOwZvcutnvAKbI/WrFCtLuBJIQcBN2p05r3ZErLaOeXNmEXCwgJdDLdJhaedkOkg 2Ujx1rsHLWTd09iGGDUV2gyKvnH75RCxSEyT2E8m84RGpzV1QjoZ9HvotdLJeCGEU+ty +TSA==
X-Received: by 10.205.46.131 with SMTP id uo3mr18581095bkb.43.1369038603388; Mon, 20 May 2013 01:30:03 -0700 (PDT)
Received: from camionet.local (77-85-165-231.btc-net.bg. [77.85.165.231]) by mx.google.com with ESMTPSA id so13sm1357820bkb.15.2013.05.20.01.30.01 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 May 2013 01:30:02 -0700 (PDT)
Message-ID: <5199DF08.8030002@jitsi.org>
Date: Mon, 20 May 2013 11:30:00 +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: Christer Holmberg <christer.holmberg@ericsson.com>
References: <51965506.7050008@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C373F07@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C373F07@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQnqk/wHTP7PObwmmUPsqc3VLTAXojqBAHHIb9Loit2o0V9itvtEMOpkvOBK7aPyw1G/ftKJ
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] A problem with both A and B
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: Mon, 20 May 2013 09:00:09 -0000

Hey Christer,

On 20.05.13, 09:50, Christer Holmberg wrote:
> Hi Emil,
> 
> I agree that the signaling protocol is outside the scope of this group.
> 
> However, as SDP O/A is also used within the API, it becomes an issue for this group :)

My point was that such semantics do not belong to SDP O/A in the first
place. They are a matter for application specific signalling.

Emil




> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Emil Ivov
> Sent: 17. toukokuuta 2013 19:04
> To: rtcweb@ietf.org
> Subject: [rtcweb] A problem with both A and B
> 
> I've mentioned this in a couple of other threads but I think it's important so I am also posting it separately.
> 
> Both plan A and B currently describe semantics that would require O/A exchanges every time a source is added or removed from a session.
> 
> Whether it is about adding a second webcam, or a conference participant that leaves or joins, both schemes suggest that the remote party should be notified with an updated SDP.
> 
> Plan A deals with this by manipulating m= lines, while plan B does it with msid-s.
> 
> We are nowhere near consensus and I think that this fact alone is a strong argument in favour of the following:
> 
> This is not a problem for rtcweb to solve.
> 
> We all have our own preferences for a solution and those come from the different use cases we are planning on addressing and the different apps we are planning to build. The promise of WebRTC is that, by building on the Web paradigm we would provide building blocks which can then be assembled into specific solutions (rather than providing the solutions themselves).
> 
> In other words: it is not our job to try and implant a signalling protocol into O/A. Signalling is the job of the application.
> 
> Applications alone know the meaning of the stream that came from your second web cam, or that of the tenth conference participant. They know which conferencing topology they most care about. They have best knowledge about what streams they are currently rendering and which ones they don't need. They know that the names Adam and Justin should be displayed to describe the streams they are currently getting.
> 
> Most importantly however: they are best placed to know how they'd like to communicate that information to their peers or IF they need to communicate it at all.
> 
> Currently neither Plan A nor Plan B would let the application do its job. However I do believe Plan B is closer.
> 
> If we agree that browsers would give applications the latitude that's necessary to address these issues with app specific signalling, then the SDP shouldn't change when they are doing it. Plan B is almost there and the only remaining problem is its insistence on the pre-announcement of SSRCs.
> 
> If we get rid of that requirement then all we need would be for the W3C to make sure that the APIs have everything they need to allow apps to retrieve SSRC information, send it remotely then pass it down to the browser again when they receive it.
> 
> I acknowledge that the simulcasting and FEC cases might be a bit different, which is normal because they are about the resolution of transport problems. I still think they could be solved with app-specific signalling and the proper APIs but in this case it would also be worth investigating the options of doing this through RTP/RTCP.
> 
> Does any of this make any sense?
> 
> Emil
> 
> --
> https://jitsi.org
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 

-- 
https://jitsi.org