W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2011

Re: Additional requirement - audio-only communication

From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 25 Aug 2011 09:02:51 -0700
Message-ID: <CABcZeBMYAOkPU2JJ+kiU2UJSOYeQT4WQtJqJj7FKYk7Z_WSWGg@mail.gmail.com>
To: Matthew Kaufman <matthew.kaufman@skype.net>
Cc: Harald Alvestrand <harald@alvestrand.no>, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>

Do you think you could sketch out (or point to) what a sample app
would look like using
this API style?


On Thu, Aug 25, 2011 at 8:55 AM, Matthew Kaufman
<matthew.kaufman@skype.net> wrote:
> On 8/24/2011 4:36 AM, Harald Alvestrand wrote:
>> I think that:
>> a) this doesn't make sense - it's a completely new SDP/RTP practice, and
>> we should not depart from established practice without a good reason; it
>> also flies against the "keep the number of RTP sessions as low as we can"
>> conclusion that came out of all the discussions about ICE.
>> b) it's not consistent with section 4.1.2 step 7.
>> I think step 16 of section 4:
>> "If connection's ICE started flag is still false, start the PeerConnection
>> ICE Agent and send the initial offer. The initial offer must include a media
>> description for the PeerConnection data UDP media stream, marked as
>> "sendrecv", and for all the streams in localStreams (marked as "sendonly")."
>> is neither correct nor complete.
> I agree that "this doesn't make sense" and it is just yet another reason
> that I think SDP offer-answer is entirely inappropriate for WEBRTC.
> The web user agent should do what the web site's HTML and cooperating
> Javascript tell it to do. It should not be engaged in direct negotiation
> with the far end such that the outcome is either indeterminate or even
> unexpected, except where direct negotiation is explicitly required to meet a
> security requirement (the initial ICE handshake to determine that it is
> permitted to send data to that endpoint).
> Note that any perceived gains by doing this negotiation (like "what if my
> browser is on a slow connection and only wants to receive audio") are
> immediately negated the moment the site changes the SDP enroute to add
> "wants HD-resolution video" for you.
> In addition, because the spec is currently written with offer-answer, a wide
> array of use cases that would be possible if capabilities were instead
> exposed via Javascript become impossible. As an example, it should be
> possible for me as a web site developer to create a page that can determine,
> without prompting you to use your camera, whether or not a camera is
> available and if so what codecs it supports. That way I can put "I see you
> have a high-resolution camera and can encode H.264 video... click here to
> call a live agent who can help you find the exact replacement part" for
> users who have that, and not if they don't have a codec that works with my
> call center or a camera with sufficient resolution to examine the parts I
> sell.
> Matthew Kaufman
Received on Thursday, 25 August 2011 16:04:17 UTC

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