Re: Alternative to the offer/answer mechanism

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