Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP

[Silvia Pfeiffer <[e-mail]>]

On Fri, Mar 8, 2013 at 10:10 AM, Matthew Kaufman <[e-mail]> wrote:

>  On 3/7/2013 3:01 PM, Silvia Pfeiffer wrote:
>
> On Fri, Mar 8, 2013 at 8:48 AM, Matthew Kaufman <[e-mail]>wrote:
>
>> On 3/7/2013 1:46 PM, Roman Shpount wrote:
>>
>>> I do not think redefining session description is the best approach.
>>> Having access to direct API methods that control send codecs, send media
>>> types, resolution, etc  is easier to understand and to program. I think
>>> even simply exposing the API from Voice and Video engines in current WebRTC
>>> implementation would be a more usable API then the current offer/answer SDP
>>> based one.
>>>
>>
>>  There is an existing proposal published by my employer which is along
>> these lines. It might be helpful if the folks who are just now realizing
>> what the issues are with dealing with both the complexity of the format of
>> SDP as well as the embedded offer-answer semantics could review that and
>> see how closely it matches their needs, rather than starting from a clean
>> sheet of paper.
>>
>
> I assume you're referring to:
> http://www.w3.org/TR/2012/WD-webrtc-20120821/#rtcsdptype  ?
>
>
> No, I was referring to
> http://html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web.htm
>


I like many features of this proposal and I would love to see it a good
part of it integrated with the existing API.



>  I like some of the approaches taken in this proposal.
> I like that there are actual objects for RTCSdpType and
> RTCSessionDescription .
> There are, however, no functions to manipulate a SDP yet.
>
> I assume that the API discussion has to happen in the W3C and not here? To
> be honest, I am not overly fussed as to what format the browser deals with
> - SDP or JSON - though the latter is a more natural browser format. I do,
> however, care what the Web developer has to deal with.
>
>
> The web developer currently is stuck with SDP *and* the SDP offer/answer
> semantics *plus* whatever gets added in MMUSIC to SDP in order to actually
> do everything that's needed (bundle, stream identification, etc.)...
> assuming that the changes to SDP can be made while keeping them compatible
> with everything else that already uses SDP.
>


So, in your opinion what should change in the SDP offer/answer semantic to
allow for a better API for Web developers along the lines of the above
linked proposal?

Silvia.