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

Dzonatas Sol <> Fri, 26 August 2011 18:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE3B021F8C4C for <>; Fri, 26 Aug 2011 11:25:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.812
X-Spam-Status: No, score=-3.812 tagged_above=-999 required=5 tests=[AWL=-0.813, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LvsIuR9L+Fh5 for <>; Fri, 26 Aug 2011 11:25:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1D5AF21F8C48 for <>; Fri, 26 Aug 2011 11:25:22 -0700 (PDT)
Received: by yie12 with SMTP id 12so2127342yie.31 for <>; Fri, 26 Aug 2011 11:26:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=2PCrEvODrkDre/qb79Gp6uczioKRHI+0Doke5NmjCa4=; b=gTBJEDphef96Y40We66ujk6v1oXvubwBDqo3YX4k64WfqYEEbF+m9Ig3OPoUj4ICm0 Um6dEBLxxVERYjaw7DbIskox5N0wKjPdWOAohUfvR3DCDxdu+JA5SoONdyKNC3epVEae SCbYpNBlgX3fNUZAQchgk19QaTg3heqCcfn7A=
Received: by with SMTP id ht9mr1429816icc.492.1314383198658; Fri, 26 Aug 2011 11:26:38 -0700 (PDT)
Received: from [] ([]) by with ESMTPS id m21sm926219ibf.8.2011. (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Aug 2011 11:26:37 -0700 (PDT)
Message-ID: <>
Date: Fri, 26 Aug 2011 11:27:36 -0700
From: Dzonatas Sol <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110505 Icedove/3.0.11
MIME-Version: 1.0
References: <> <>, <>, <>, <> <>, <> <>, <> <>, <> <>, <> <>, <>, <>, <>, <>, <>, <>, <>, <> <BLU152-W4528C66BBF7B1C9A76E1BA93130@phx.gbl>
In-Reply-To: <BLU152-W4528C66BBF7B1C9A76E1BA93130@phx.gbl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Additional requirement - audio-only communication
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Aug 2011 18:25:22 -0000

One less complex path forward is the question "is this audio meant for 
this geolocation" rather than "is this audio meant for this user". In 
the ubiquitous environment is the implication of user recognition by 
gestures and the assumption of relative vehicle location (that carries 
the audio out) to specific geolocation.

Instead of 'the phone' in the browser, tabs with geolocation data may 
clarify "mobile tabs". For example, two different web-browsers, user 
drags tab from one browser to the other, and it "just works". If the 
web-browsers works like an O/S, then this should be simple based on 
"offers" that originate at the paravirtual level. If each web-browser 
virtualizes such ability then you already know (a) and tabs as the 
semantic vehicle.

On another note, I wonder why the concept is so hard to open tab X and 
tab Y and connect the two related sites together through those tabs if I 
set X as server and Y as client for each other. Of course, some keep the 
motto that the web-browser does not enter web-server mode because 
corporate firewalls are more acceptable for them.

Based on capabilities available ("tethering included"), which endpoint 
is client and which endpoint is server SHOULD BE negotiated in the 
connection phase. The example above taken one step further, the users 
drags the mobile X tab already in server mode (for Y client-tab) to 
another web-browser... still complex? I think that clearly reveals 
legacy systems.

On 08/26/2011 10:06 AM, Bernard Aboba wrote:
> [BA] Why can't the initiating application delete the m=video line from 
> the SDP blob
> that the signaling callback receives, before sending it to the 
> callee?   Are we assuming
> that the SDP blob is opaque and can't be edited?
>  Stefan said:
> "What we really want is some way to either a) an API to tell the
> initiator browser to produce an offer with no m=video, or b) a way for
> the application to customize or generate the offer and feed it back to
> the browser. b) is definitely more complex, but a) could end up causing
> us to add a lot of knobs to the API.
> Stefan
> "
> _______________________________________________
> rtcweb mailing list

--- ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant