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

Re: Alternative to the offer/answer mechanism

From: <piranna@gmail.com>
Date: Thu, 20 Jun 2013 18:06:57 +0200
Message-ID: <CAKfGGh0SxsuDTeNd-LfJTY7SUWPsoxGoFmnDrAB8CJmV6RLRWQ@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Cc: cowwoc <cowwoc@bbs.darktech.org>, public-webrtc@w3.org
That reminds me to Microsoft & Skype CU-WebRTC specification...
El 20/06/2013 17:37, "Roman Shpount" <roman@telurix.com> escribió:

> On Thu, Jun 20, 2013 at 11:04 AM, cowwoc <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 16:07:29 UTC

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