- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 5 Jul 2013 15:33:08 -0700
- To: Emil Ivov <emcho@jitsi.org>
- Cc: "piranna@gmail.com" <piranna@gmail.com>, cowwoc <cowwoc@bbs.darktech.org>, Martin Steinmann <martin@ezuce.com>, tim panton <thp@westhawk.co.uk>, Yana Stamcheva <yana@jitsi.org>, Parthasarathi R <partha@parthasarathi.co.in>, Christer Holmberg <christer.holmberg@ericsson.com>, Iñaki Baz Castillo <ibc@aliax.net>, Robin Raymond <robin@hookflash.com>, Roman Shpount <roman@telurix.com>, Adam Bergkvist <adam.bergkvist@ericsson.com>, Ted Hardie <ted.ietf@gmail.com>, "public-webrtc_w3.org" <public-webrtc@w3.org>, Eric Rescorla <ekr@rtfm.com>
On 5 July 2013 15:25, Emil Ivov <emcho@jitsi.org> wrote: > On the contrary. It would mean that all the things SDP is currently taking > care of would have to be understood and managed by the JS: key negotiation > for SRTP, encoding ICE priorities, ICE foundations and options, RTP payload > types, codec parameters, negotiating supported formats, renegotiating them > ... All this will need to be handled by the JS. Again, this isn't necessarily true either. A good API can do most of this stuff for you. There is obviously a responsibility on the JS application for carrying some of this information, but that's a long way from having to deal with ICE foundations. A really good API would do two things: make it easy to do the easy things, and make it possible to do some really interesting things. A really good API can be both low- and high-level at the same time. If you haven't read CU-RTC-Web, I recommend that you do. It's not really good, but I think that you'll find that it is possible to do the easy things really easily, without compromising access to the internal stuff.
Received on Friday, 5 July 2013 22:33:35 UTC