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

RE: Alternative to the offer/answer mechanism

From: Matthew Kaufman (SKYPE) <matthew.kaufman@skype.net>
Date: Thu, 20 Jun 2013 21:52:21 +0000
To: cowwoc <cowwoc@bbs.darktech.org>
CC: "piranna@gmail.com" <piranna@gmail.com>, Roman Shpount <roman@telurix.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <AE1A6B5FD507DC4FB3C5166F3A05A4841A2E25BC@TK5EX14MBXC273.redmond.corp.microsoft.com>
Microsoft has published a plugin that implements the API along with several different samples. As you can see from those, the common use cases are not really harder to deal with.

Matthew Kaufman

From: cowwoc [cowwoc@bbs.darktech.org]
Sent: Thursday, June 20, 2013 10:37 AM
To: Matthew Kaufman (SKYPE)
Cc: piranna@gmail.com; Roman Shpount; public-webrtc@w3.org
Subject: Re: Alternative to the offer/answer mechanism

Hi Matthew,

    Common use-cases should be easy, advanced use-cases should be possible.

    We need an API that lies somewhere between WebRTC and CU-RTCWEB because it looks like the latter complicates common use-cases. If you disagree, can you please reply with a complete testcase demonstrating what a common use-case would look like?


On 20/06/2013 1:11 PM, Matthew Kaufman (SKYPE) wrote:
I already showed the use case for why you want more than "the browser does ICE for you" a few days ago (which is part of the motivation for separation in the CU-RTCWEB proposal)... I'll repeat one of them here:

I want to be able to open a connection between two browsers that uses my private fiber network (via relays), but I also want a connectivity test done to see if they have direct Internet connectivity should I need to fall back to that.

Having the browser choose the candidates all on its own makes it difficult to intervene in the decision, and thus the (better) relayed path would not be selected.

Matthew Kaufman

From: cowwoc [cowwoc@bbs.darktech.org<mailto:cowwoc@bbs.darktech.org>]
Sent: Thursday, June 20, 2013 9:17 AM
To: piranna@gmail.com<mailto:piranna@gmail.com>
Cc: Roman Shpount; public-webrtc@w3.org<mailto:public-webrtc@w3.org>
Subject: Re: Alternative to the offer/answer mechanism

    ... a good point, especially now that I revisit their document with this in mind. Yes, that's the general idea though they went much lower level than is necessary in some places (replacing ICE connectivity with an API for opening ports... why bother?). The goal is to be able to specify all configuration using Javascript even though in most cases you'll never have to deal with anything more than:

navigator.getUserMedia({ audio: true }, function(media) {
    var track = media.audioTracks[0];
    var description = new RealtimeMediaDescription(track);
    var localRtStream = new LocalRealtimeMediaStream(track, description, realtimeTransport);

    (taken from their document)


On 20/06/2013 12:06 PM, piranna@gmail.com<mailto:piranna@gmail.com> wrote:

That reminds me to Microsoft & Skype CU-WebRTC specification...

El 20/06/2013 17:37, "Roman Shpount" <roman@telurix.com<mailto:roman@telurix.com>> escribió:
On Thu, Jun 20, 2013 at 11:04 AM, cowwoc <cowwoc@bbs.darktech.org<mailto:cowwoc@bbs.darktech.org>> wrote:

    On that topic, isn't it reasonable to assume we could expose an alternative to offer/answer without going down to the low level found in the C++ classes you mentioned? Surely we should be able to come up with an intermediate-level interface that stands between offer/answer and low-level signaling?

C++ does not necessarily means low level. I was just pointing out that internally webrtc is not based on offer/answer.

The  API that I think would makes sense will be something that gives you media types supported (audio and video), list of supported codecs, let's you configure receive payload types (ie what codecs this is and what parameters are associated with each payload type you expect to receive), send payload type (what payload id you will use to send, what codec, and what encoding parameters that you will use). Transports are separate. Media streams (audio and video sources) are separate. Essentially instead of negotiating everything at once (ie send codecs, receive codecs, transports) using a single opaque blob you control each logically independent component separately using an separate API call. All the same concepts, just not mungled up together.
Roman Shpount
Received on Thursday, 20 June 2013 21:53:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:44 UTC