Re: [rtcweb] Additional requirement - audio-only communication

Randell Jesup <randell-ietf@jesup.org> Fri, 26 August 2011 19:44 UTC

Return-Path: <randell-ietf@jesup.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 1AFC321F8CBC for <rtcweb@ietfa.amsl.com>; Fri, 26 Aug 2011 12:44:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.504
X-Spam-Level:
X-Spam-Status: No, score=-3.504 tagged_above=-999 required=5 tests=[AWL=1.095, BAYES_00=-2.599, GB_I_INVITATION=-2]
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 rfAAZqW075wy for <rtcweb@ietfa.amsl.com>; Fri, 26 Aug 2011 12:44:18 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 8285321F8BAB for <rtcweb@ietf.org>; Fri, 26 Aug 2011 12:44:18 -0700 (PDT)
Received: from pool-98-111-140-38.phlapa.fios.verizon.net ([98.111.140.38] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1Qx2LO-0006te-Iq for rtcweb@ietf.org; Fri, 26 Aug 2011 14:45:34 -0500
Message-ID: <4E57F749.4030806@jesup.org>
Date: Fri, 26 Aug 2011 15:43:05 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E539A1F.109@alvestrand.no> <4E53B80C.20304@ericsson.com> <4E53E0C8.6010304@alvestrand.no> <BBF498F2D030E84AB1179E24D1AC41D61C1BCA7F62@ESESSCMS0362.eemea.ericsson.se> <4E54ADC7.8030407@jesup.org> <4E54CC05.1040705@alvestrand.no> <4E54CE29.2060605@ericsson.com> <4E54D867.4060706@alvestrand.no> <4E54D9C2.6000205@ericsson.com> <4E54DE8E.9080207@alvestrand.no> <4E54DFCF.4000805@ericsson.com> <4E54E24F.7060906@alvestrand.no> <4E56707B.104@skype.net> <4E567737.6020101@jesup.org> <4E5680B0.6070702@skype.net> <CAOJ7v-0DnVKYD2gd4os3R-LuzN1mu4qZqjndDEJcJXwY7U-FnA@mail.gmail.com> <4E56E264.8000600@mozilla.com> <CAOJ7v-2kEByX3mq7dRFuo7wEqaEGz597aWuFpEZK9zE_eS6U4A@mail.gmail.com> <4E5747E7.2050605@ericsson.com> <CAOJ7v-1ccLPZhqCDW0ngFkm23TeDSLjNCMUJj-k7wwdg+tTnhg@mail.gmail.com> <4E57AC5C.1020406@ericsson.com>
In-Reply-To: <4E57AC5C.1020406@ericsson.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] Additional requirement - audio-only communication
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, 26 Aug 2011 19:44:19 -0000

On 8/26/2011 10:23 AM, Stefan Håkansson LK wrote:
> On 2011-08-26 16:11, Justin Uberti wrote:
>>
>>
>> On Fri, Aug 26, 2011 at 3:14 AM, Stefan Håkansson LK
>> <stefan.lk.hakansson@ericsson.com
>> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>>
>>     FWIW,
>>
>>     this is how I would do the case of the caller (initiator) wanting to
>>     receive only audio, but willing to send audio and video with the
>>     current API proposal:
>>
>>     1. Generate an audiovisual mediastream (getUserMedia)
>>     2. create PeerConnection, add the above mediastream (addStream)
>>     3. combine the SDP received from PeerConnection with the following
>>     fields "This is an invitation to a communication", "sending audio
>>     and video", "want to receive only audio" into a message sent to the
>>     peer.
>>     4. the app in the peer (same app!) receives the message, reads the
>>     fields, (given user agreement to start the communication) creates a
>>     PeerConnection, feeds the received SDP into the PC, generates an
>>     *audio only* stream (getUserMedia) and adds it to the PC
>>     5. A couple of SDP exchanges later the application is working as
>>     intended. (there will be onaddstream's, you will attach those
>>     streams to video/audio elements etc.)
>>
>>     Quite simple! And no need to have the application read, understand,
>>     or modify, the SDPs - they are opaque. (Then, of course, the
>>     mediastreams must be mapped to RTP sessions and such stuff, but I'm
>>     sure that is solvable and should not be visible in the API IMHO.)
>>
>>
>> Maybe I misunderstand, but it sounds like with these fields you are
>> defining a new signaling protocol, which I think we want to avoid.
>
> That's not how I see it. It is the same web app in both peers, and 
> they can communicate inbetween them in any way the app developer see 
> fit (using e.g. XHR via the web server). There is already a need for a 
> mechanism to pass the SDPs between the browsers, and that mechanism 
> could be used to pass other data.
>
> So no new protocol needed!

This is a new (application-specific) protocol.  It may be a simple one, 
but it is one, overlaid on top of the SDP saying "ignore this part of 
the SDP" effectively.  As mentioned, you then have more problems when 
two different domains/apps want to talk to each other.  We've left the 
protocol between the domains unspecified here, but it will likely need 
to be translated to some external standard such as SIP, H.323 (ugh) or 
Jingle/XMPP.


-- 
Randell Jesup
randell-ietf@jesup.org