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

[Dzonatas Sol <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>    


-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant