Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing

[Cullen Jennings <[e-mail]>]

I agree SDP is not used as an RTP API. I looked at a few RTP API and they looked like "here is your compressed media and it's time stamp" and "send this compressed media with following time stamp to this IP, port. I don' think any one want that to be the level of API that gets exposed by the browser. For one thing, the performance issues would likely not work. 

One question that comes up is when a browser adds support for a new CODEC, should the Java script code of a given web sight need to change to take advantage of it. If your answer to that is at least in some cases, No, then it means you need an API that allows the browser to do the negotiation of the codecs. Today SDP (and the mapping of it in Jingle), are pretty much the only games in town for that sort of negotiation. You can argue if we should use SDP or invent something new. I'd love to hear your opinion on that. If we decide we are going to use SDP, I think you end up with a API at roughly the level of what is the W3C WEBRTC draft today and something around the level of protocol as described in ROAP. 

A third level of api that one could do - and I think Dan York, may have been arguing for this but I'm not sure - is and API where there is an DOM object that represent all the communications and in the implies case you just tell it who to connect to and it is done. Imagine if the HTML5 Video tag has something like rtc attribute of someone you wanted to communicate with and the browser set up a video session with them. For example: <video  rtc="jingle:[e-mail]" />. WIth this sort of API, JS could still be used to manipulate the dom object , add streams, pause them, get attributes etc. My read of folks involved was this sort of approach had been pretty much rejected this. 

Like you, I care more about we have something that works and does not limit innovation. I don't really care about how we do it but I want it done soon not 5 years from now. I wrote up ROAP with JDR because I think that it splits the middle ground as is by far the most acceptable thing to people. Largely that is based on my feelings from the room after the last IETF. 

On Oct 19, 2011, at 1:01 , <[e-mail]> <[e-mail]> wrote:

> Hi,
> 
> Hadriel Kaplan wrote:
>> 
>> How many RTP libraries do you know of that use SDP offer/answer protocol as
>> their API?
>> 
> 
> This confuses me too in the direction where the RTC-Web work seems to be heading. There are countless SIP user agents and XMPP clients that implement SDP offer/answer or the Jingle equivalent. But I've not  heard SDP used as an *API* towards the RTP/media libraries. So, when I think about the RTP/media API that the browser should expose to the Javascript app, I'm surprised to see SDP on that level.
> 
> I see that it may be useful to have a higher level API that provides ICE and SDP offer/answer type of functions to developers who want that. But I'm not sure if that should be a real W3C standard API or could it just be Javascript libraries. 
> 
> Having said that, I'm not going to write a "signaling" or API draft. I can live with any outcome that does not limit app developers too much. So for me at this point it would be valuable input to understand what we are *loosing* if the API were based on SDP and we would have something like ROAP. I've heard it "limits innovation" but I haven't seen concrete examples of that. So if Hadriel is going to produce a draft on these issues, it would be great if it had something like that.  
> 
> Markus