W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2012

Re: UI Problem - media types of incoming connection

From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 1 Jun 2012 09:38:50 -0700
Message-ID: <CABcZeBOXpS3keocfg8HTo5rgdG-1zB=RKH2wZGr++tak5E+geA@mail.gmail.com>
To: Cullen Jennings <fluffy@cisco.com>
Cc: public-webrtc@w3.org
On Fri, Jun 1, 2012 at 9:31 AM, Cullen Jennings <fluffy@cisco.com> wrote:
> On Jun 1, 2012, at 10:26 AM, Eric Rescorla wrote:
>> On Fri, Jun 1, 2012 at 9:21 AM, Cullen Jennings <fluffy@cisco.com> wrote:
>> >
>> > Say that Alice has sent an Offer to Bob. This offer perhaps has an audio / video / and data stream. The JS running on Bob's browser would like to know if this offer includes video and/or audio so that it can render an appropriate UI. Bob might want to know if the ALice is offering video or not before Bob decides to provide a video stream or not back to Alice.
>> >
>> > One option is to have the JS look at the SDP. I think we all agree this sounds pretty gross. I'd like to propose that we add something to the API that can take an offer and return the number of tracks of audio, video, and data in the offer. I'm thinking something roughly like a getCharacteristics method that takes a SessionDescription and returns a dictionary with keys "numberAudioStreams", "numberVideoStreams", "numberDataStreams"
>> Would this be conditioned on the local properties?
> I was thinking "no" - it would only indicate what was in the offer with no consideration for what the device might be capable of accepting.
> An alternative design might be to have createAnswer return a similar dictionary that indicated what it was possible to negotiate and would take into account device capability's and whatever constraints had been set.

Where would either of these calls go wrt setRemoteDescription(OFFER).

Received on Friday, 1 June 2012 16:39:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:28 UTC