Re: Alternative to the offer/answer mechanism

On 20/06/2013 11:36 AM, Roman Shpount wrote:
> 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

     I meant that if the C++ interface consists of a few thousand lines 
then clearly it's much lower level than offer/answer which has an 
interface of about 10 lines. Probably the best way to push your proposal 
is to create the actual interface and post it to this list.

     One thing worries me :) So far we haven't heard much from the 
pro-SDP camp which leads me to believe that it's being treated as a 
foregone conclusion. A release date is probably around the corner (I 
haven't heard of anything official but there are rumors) so they're 
sitting tight and simply ignoring these emails.

     It would be nice to get an official response, either to this 
proposal or the proposal of simply wrapping the SDP in a Javascript API.

Gili