Re: [rtcweb] No Plan

Enrico Marocco <enrico.marocco@telecomitalia.it> Thu, 30 May 2013 15:53 UTC

Return-Path: <enrico.marocco@telecomitalia.it>
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 9C3D421F939E for <rtcweb@ietfa.amsl.com>; Thu, 30 May 2013 08:53:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.719
X-Spam-Level:
X-Spam-Status: No, score=-101.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1, 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 zrGbi1Zx68EZ for <rtcweb@ietfa.amsl.com>; Thu, 30 May 2013 08:53:45 -0700 (PDT)
Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by ietfa.amsl.com (Postfix) with ESMTP id 9103121F96A3 for <rtcweb@ietf.org>; Thu, 30 May 2013 08:53:37 -0700 (PDT)
Received: from grfhub702rm001.griffon.local (10.19.3.9) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 30 May 2013 17:53:33 +0200
Received: from MacLab.local (163.162.180.246) by smtp.telecomitalia.it (10.19.9.235) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 30 May 2013 17:53:33 +0200
Message-ID: <51A775FC.8080003@telecomitalia.it>
Date: Thu, 30 May 2013 17:53:32 +0200
From: Enrico Marocco <enrico.marocco@telecomitalia.it>
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: rtcweb@ietf.org
References: <BLU404-EAS183E8C6EC78BF3F108964C793900@phx.gbl> <51A66B3B.6070005@gmail.com> <CAL02cgTjJ7RrOZWUUFHCsEGSFSHSkDEt2kEfXB94HV2VzyDPPQ@mail.gmail.com> <51A715E6.6060703@telecomitalia.it> <51A76CBA.7030106@alum.mit.edu>
In-Reply-To: <51A76CBA.7030106@alum.mit.edu>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms030202050205060605060909"
X-TI-Disclaimer: Disclaimer1
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 15:54:12 -0000

On 5/30/13 5:14 PM, Paul Kyzivat wrote:
>> 1. sender gets the additional local tracks
>>
>> 2. sender tells the receiver on the app-specific signalling channel
>>     (assuming a plain-english-over-something one): "I can also send you
>>     video and audio of a webcam I've just installed in the girls locker
>>     room. They'll have SSRC xxx and yyy" (xxx and yyy retrieved through
>>     JS API -- kind of what exists in Chrome today for stats)
>>
>> 3. receiver responds "Shoot!"
> 
> What does the receiver say if it can use the media, but cannot receive 
> it over the *existing* audio and video m-lines where it is receiving 
> other media already?

I may have misinterpreted the draft, but it seems to me the whole point
here is about having WebRTC endpoints support multiple SSRCs on the same
m-line. If that's the case, an endpoint not supporting that would
qualify as "legacy". It would be behind a gateway anyway, and the
gateway function would be in the best position to translate both SDP and
media in a way it can digest.

Enrico