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);
     signalingChannel.send(description.toDictionary());
});


     (taken from their document)

Gili

On 20/06/2013 12:06 PM, 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
>