Re: Alternative to the offer/answer mechanism

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
>
>