| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | What are you using it for? | What has worked well? | What's the biggest pain point? | Do you have an opinion on SDP or O/A as the API surface? | Quotes from mailing list about SDP | Summarative opinion | Did you change your mind about the SDP API since it was first proposed? | |||||||||||||
2 | Marc Abrams | If the purpose for including SDP is compatibility with existing services or protocols, there are better ways to ensure this. | We should punt on SDP for v1.0 and move on. | (strong dislike) | No | |||||||||||||||
3 | Iñaki Baz Castillo | SIP over WebSocket. | Not. Lot of issues due to SDP usage. It is too hard and error prune to mangle a SDP from any browser/version/flavour. | SDP blob and O/A artificial mandate. | The worst API in the history of the WWW. Designed for telcos for satisfying today's telco business (the "webphone dream"). But worse than they think. Telcos should not design a JS API for the W3C and WWW. They do not know. | *** I don't want SDP *** We don't want to be forced to O/A model; We don't want to deal with blob strings | (strong dislike) | Yes | ||||||||||||
4 | Robin Raymond | Attempting to implement a reference implementation of the Open Peer P2P communication stack in JavaScript and have that utilize WebRTC. | getUserMedia? spin up a quick demo isn't bad, but even then we needed to shim the current browsers because they weren't compatible | Universal format, single binding point for signaling all media, and O/A state machine that doesn't exist and works contrary to one-sided negotiations in Open Peer | Horrible. Absolutely horrible. I've spent time drafting up exactly what is wrong with this approach in detail with scenarios. | It's truly awful: back: http://www.ietf.org/internet-drafts/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00.txt | (strong dislike) | Somewhat. Always thought it was a bit wonky but thought we could work around it (and perhaps it wass good for SIP) at first but now I think there is no hope for this SDP based API (even for SIP). | ||||||||||||
5 | Roman Shpount | Browser interfaces to a hosted MCU | Integration of Web UI with real time media | SDP interop between the SDP produced by the Browser and SDP produced by MCU | It is horrible for interop with external end points. It also prevents alternative capabilities negotiation flows such as better offer glare resolution flows. | An unmanageable monster was created which currently stays in the way; I am also strongly for removing O/A and SDP from the API. This is a wrong API surface that does not provide the necessary degree of control for building WebRTC apps. | (strong dislike) | My initial view was it was not ideal but manageable. At this point I see that maintenance effort that SDP and O/A puts on keeping MCU compatible with browsers makes it unsustainable. | ||||||||||||
6 | Bernard Aboba | Prototyping of accessibility enhancements. | gUM is ok; can live with adapter.js | a=ssrc declaration, and other aspects of Plan B. | Both are painful and artificially limiting. | I welcome [an] effort to enable applications who don't care about SDP to minimize its usage even if it is not eliminated entirely. | (strong dislike) | I was always wary but the video issues have proved that the current course is unworkable. | ||||||||||||
7 | Silvia Pfeiffer | Web applications | 1-1 works well | having to understand what SDP lines Chrome/Firefox understand and negotiate; as well as what the SDP lines mean | I don't mind SDP used by the browser, but there should be some explicit functions to manipulate it with the most common needs such as `; I have no opinion on O/A since I don't know what the alternative would look like | I am really excited that there is movement in this space ... I'm feeling the pain | (would like nicer interface to manipulate SDP) | had no initial view - it seemed a logical pick, but I wasn't for/against it | ||||||||||||
8 | José Luis Millán | Implementing a JavaScript SIP library (JsSIP - jssip.net -) | Simplest call setup | The fact that a given stimulus in the offerer (ie: directionality change), even if tranlated in the SDP Offer as 'sendonly', 'inactive', 'recvonly', does not generate a reaction in the answerer, so this last is unaware of the changes (hence communication itself). In general, the lack of control over the media and transport description from the JavaScript API, both from the point of the requestor, when making any change and from the point of requested, when receiving such a change. | SDP should be a mere representation format as well as JSON, XML... I don't feel like O/A is needed but "just" for interoperability, so it could just exist on the edges where interoperability is needed. | In favour of this flavour: http://www.ietf.org/id/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00.txt | Yes. Problems have arisen at implementation time. Initially OK with SDP | |||||||||||||
9 | Erik Lagerway | Realtively large comm projects, WebRTC as an extention to service. | getUserMedia, basic demos are simple, multiplexing media streams and doing fancy hand-offs. not so much | The current O/A API does not put the control in the hands of JS developers, so many of those features are simply not supported. | The people I have talked to, even at the WebRTC Expo yesterday, sounded somewhat relieved when I told them about this new JS API model. They need to see it and play with it obviously, but suffice it to say SDP O/A doesn't seem like it will work for most advanced web app developers. | +1 to re-open the debate re: SDP | (strong dislike) | Yes. Initially it seemed like SDP made sense, and would work for most. I think after having to implement the current API several times, we are seeing areas for improvement, a new model seems to make sense now. | ||||||||||||
10 | Alexandre Gouaillard | team of 5 dedicated to all aspects of webrtc (client, API/SDK, infrastructure) | the reference demo(s) and appRTC. | As soon as you want to venture further than appRTC, or to implement your own infrastructure, life is hard. No documentation, ever changing APIs, not fully implemented standard are the norm (it's expected, nonetheless painfull). All the details you would have to have access to too (media, e.g. codec list, transport: bandwidth options, ICE: which ice candidate failed, which one was kept) *seems* to be available only in the SDP. | I honestly have no opinion. I +1'ed the thread because I was not here at the beginning and wanted to hear both sides, and revisit the quetsion after having developped on top of the API for a year. Wether it uses sdp or not, if I had access to badnwidth, codec, ICE through a nice API, I wouldn't mind. I'm not sure I understand correctly the O/A mechanism enough to comment, but I am under the impression than it coul dbe made easier (datachannel like) in many cases, including the entreprise case where the IPs and other network informations could be known. | +1 to reopening the discussion. | would like extension of the API at t he JS level. Wether it uses sdp or not is not so important. If SDP was to be chosen, a more verbose parser woul dbe highly welcome. | was not here when it was first proposed. | ||||||||||||
11 | Adrian Georgescu | SDP is not such a great idea to put in practice and [some] may also want to come forward to admit their mistake. | (dislike) (strongly?) | |||||||||||||||||
12 | Matthew Jordan | In the Asterisk project, we were able to use our legacy SIP stack to enable very basic WebRTC communication with Chrome and FireFox. That sounds nice, until you realize we have to continually preface that with "sometimes". | ||||||||||||||||||
13 | Bossiel thioriguel | Using the current WebRTC we have managed to *easily* build almost all kind of applications: click-to-call, SIP/IMS clients, gateways to PSTN, MCUs, Telemedicine systems...and haven't seen any major issue | (it's good) | |||||||||||||||||
14 | Andrew Hutton | SIP interworking has been relatively straight forward. | The current SDP based API has worked well for us but we do have a lot of expertise in SDP manipulation. The API does not restrict to only using an O/A model but does make interworking with O/A easy which is needed. For sure I agree SDP is ugly and believe that SDP manipulation should be perfomed using API constraints rather then direct SDP manipulation. I want to see V1 complete without adding too much SDP complexity before making a decision on future direction. | Let's concentrate on making sure all those innovative apps already written deployable before we start trying to satisfy the requirements of the mega application developers. | (good for 1.0) | |||||||||||||||
15 | Philipp Hancke | xmpp, mapping sdp to jingle and vice versa. browser, native + android | early transport warmup. Had to come up with a pranswer hack because the addicecandidate api doesn't use enough sdp. Also, i am frequently hitting implementation bugs because of mangling the sdp alot, but that is not the fault of SDP. | o/a is fine for setting up (1-1) calls. Things like mute should not require O/A, nor should adding a remote stream do. SDP is ugly and complex, trying to express structured data in a plaintext format. Jingles xml isn't much better however, but it has a much better separation of media and transport. | (ugly and complex; fine for simple calls) | no. I knew SDP was going to be painful. However, it seemed like progress over things like adobes netconnection api in flash | ||||||||||||||
16 | Gavin Llewellyn | JS library enabling media calls, IM, data transfer & presence over our own SIP signalling infrastructure, including PSTN breakout and billing | Demo up and running surprisingly quickly | Mostly incompatibility problems between implementations, as they're all at the teething stage atm. Often seems to be ICE-related. | It's worked well for us, since we're experienced with SIP, and haven't had to mangle the SDP much. It does feel a bit odd to use it as a control surface, but I think we're better off sticking with it if the alternative would delay the spec significantly. | (a bit odd; fine for simple calls; good for 1.0) | ||||||||||||||
17 | Tim Panton | Creating a simple jquery API that lets javascript devs talk to our infrastuture and make calls in a couple of lines. Fallback to flash if webRTC not available, Creating opensource interoperable client code for iOS, android, java. | Wire protocols are well defined, writing gateway or client code from scratch to consume webRTC media is possible just with current documentation. | Ill defined SDP - non-existant error messages when something goes wrong. Creating interoperable SDP is an almost endless trial-and-error cycle. | SDP makes a poor API surface, it is ambigious, brittle and inflexible. O/A hasn't limited us so far, but it is almost inexplicable to web developers. | When we implemented DTLS support (for firefox), I spent longer on getting the correct SDP than I did on the crypto integration. | Strong dislike, but it is survivable for 1.0 if we stop messing with it. | Somewhat, my initial feeling was that SDP was the wrong solution, then I was largely convinced that a good a constraints API coupled with a description of relevant SDP would be an adequate work around. I'm now significantly less convinced that either is possible. | ||||||||||||
18 | Christoph Dorn | Completely new to RTC. Started with building examples. Will help build cross-platform communication service. | Getting examples running quickly and being able to test with two peers on same browser page. | Learning all the concepts (ICE, SDP, signaling) to understand what the API actually does to understand what can be done. True capability of API is not clear by looking at methods/events. Dealing with modifying SDP to do anything non-standard. | Seems to be a wire protocol. Not something a developer wants to have to deal with. Need to write own abstraction layer to modify anything beyond very basic use-cases. Looks like there will be a lot of duplication in work dealing with SDP modification. | don't like very much as an API I need to deal with; change now to remove SDP before it is too late | ||||||||||||||
19 | Gustavo García | Building videoconference platform | getUserMedia and quick basic demo. PSTN interconnection was easy to implement (because it is a very basic use case and it is only audio). | Finding what is wrong in my SDP when one browser stop behaving as expected (not accepting candidates, not sending PLIs...). Finding documentation and discovering new media constraints. Hacks to SDP (inactive, a=b:AS, crypto). re-Offer/Answer never works. Don't have an understanding on how that API can evolve to support simulcast, modifying bitrate dynamically, modifying list of codecs...) | The benefit is low for the problems it brings up. | There are only two reasonable approaches, changing the API now or changing it in a year. +1 to re-open the debate re: SDP. | Strong dislike, only acceptable for 1.0 if we stop trying to add features and there is a strong commitment to change it later | Somewhat, I never liked SDP and O/A a lot but was not expecting that it could become so problematic. | ||||||||||||
20 | Lance Stout (lance@andyet.net) | Talky.io, SimpleWebRTC, XMPP over WebSocket JS library (stanza.io) | Very easy to get initial 1-1 video calls and group mesh calls to work with socket.io, after some cross-browser api smoothing | The claims of using XMPP Jingle for signalling because any signalling protocol is allowed ring hollow -- translating the SDP is required, which is a hacky, fragile, and lossy process. It's doable, but constant vigilance is needed to ensure it keeps working, and some new features don't translate at all yet (BUNDLE, ssrc, etc). Figuring out inconsistencies between what FF and Chrome expect in the SDP (DTLS, etc). | It feels to only have been potentially useful for SIP developers/integration, but that is too far removed from the 'Web' part of WebRTC to be useful for non-SIP/telephony devs. SDP is too malleable of a format to be reliable as an API. At the very least give us a parsed version of the SDP blob, otherwise there will be lots of broken SDP-JSON parsers. | Strong dislike for SDP as final API. The 'no plan' plan sounds like the best forward moving compromise | No | |||||||||||||
21 | Wolfgang Beck | rtc.k.vu a demonstrator using 3rd party auth. | basic call, NAT traversal | Even common functions like muting a call require SDP parsing and manipulation. | SDP should at least be encapsulated with an API for common operations, like 'mute'. In general, the interoperability argument for SDP is weaker than expected -- see data channel content negotation. | Web developers should not have to deal with SDP | No, all my concerns were confirmed. However, the JSEP proposal has potential for improvement (which ROAP didn't have). | |||||||||||||
22 | Dmitry Sobinov | Adding support of WebRTC clients to AddLive.com webconferencing platform | 2-user basic conference with audio/video | SDP manipulations and generation in JavaScript. We didn't originally use offer/answer and SDP in our product, so now we have to generate SDP and simulate offer/answer for WebRTC API completely in JavaScript from data we got from our custom signaling protocol. It is not clear how to mute separate media streams correctly. And it requires modifications of SDP and offer/answer round again. Similar concerns about adding/removing media streams to exising PeerConnection. | SDP is a bad choice for API, because it requires lots of parsing and modifications to achieve non-typical use cases. O/A is not needed in all use cases, but having this is not a big problem. | Strong dislike for SDP | No | |||||||||||||
23 | Jesús Leganés Combarro (piranna@gmail.com) | WebP2P.io, an application-agnostic framework to easily develop P2P applications on HTML5 ShareIt!, a serverless and pure client-side P2P filesharing application in HTML5 and Javascript | Continuous changes on the API, lack of interoperatibility and not allignement to the specification, also after removing prefixes. Definitely it has been done too early by browser implementers | Should be an implementation detail that it's strange for applications that only require DataChannels and don't need to do negotiation, and if possible, O/A shouldn't be needed | I don't totally disagree O/A if there's no better alternative, but there should be a higher level alternative to SDP, and also should allow to interchange less verbose message (SDPs can get to be crazy big also in the most simple scenarios) | Not really, I though it was a strange decision but though it was the only one, and also a standard one, so I accepted it. Now I think there should be better options that hide so much complexities and also don't requiring so much band-width waste. | ||||||||||||||
24 | Jan Lelis | Small video/audio/data conferences (palava.tv) | Hello world/demo applications. Connection itself, once it has been established. | Browser interop. Also, the current browser implementations are still very buggy when it comes to all the details. | Would not mind having to use the SDP based API. Better JS interfaces will be developed by the JS community. On the other hand, we don't have a problem shifting to another API now/soon/later. Had some problems with O/A, but I am not convinced that the the general approach needs to change. | A JS API would be nice, but could live with having to deal with SDP. No strong opinion on O/A. | ||||||||||||||
25 | Saúl Ibarra Corretgé | SIP over WebSockets | A (really) simple callflow | Anything related to SDP manipulation, since it's treated as an opaque blob. | Using SDP or O/A as the API is terribly limiting. A lower level API allows for SDP to be built on top, but the other way around, things don't really work well. | Strong dislike for SDP. | Yes. In the beginning I thought it would make getting SIP working easier, but it turned out to make it really complex to support very basic features. | |||||||||||||
26 | Gili Tzabari | Customer support browser/mobile application | Two-way chat on Windows | Troubleshooting when something goes wrong. The API isn't strict enough, does not fail-fast, error messages are vague and it is virtually impossible to debug network problems. | Implementation details (such as SDP and O/A) should *never* be exposed to Web Developers. This makes the API harder to use, prevents future evolution (when the implementation will need to change), and requires developers to become telecom experts instead of focusing on business needs. There is no good reason for this. We can integrate with legacy systems without exposing SDP in the API. | We need an easy-to-use API for web developers. The current make up of the Working Group (made up of mostly Browser and Telecom members) has proven unable to deliver this. The majority of Web Developers on the mailing list have voiced concerns with the current API but the Working Group does not seem to be taking them into consideration. | I didn't mind SDP before I had to interact with it. The minute it became "the API surface" and I was forced to interact with it I developed a very strong dislike for it. | |||||||||||||
27 | Rob Manson | Open Source demo applications as part of the "Getting started with WebRTC" book for Packt Publishing (just finished). Several commercial applications including e-learning and team communication. Lots of Augmented Web demos as part of the W3C AR Community Group. | gUM for lots of uses (including image processing) and basic audio/video calls | General interop, especially if it drives you to mangle SDP. Explaining the convoluted O/A flows to other developers, especially as the spec example code munges all the flows in quite an opaque way. Knowing where to focus your attention to stay up-to-date (moving discussion primarily to public-webrtc has helped this). Plus all the usual problems with pre-release fast moving technologies. | It just logically seems like the wrong abstraction. I think a good solid argument against it is outlined in http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-01 and I would definitely be for specifying a JS Object API that could then use a shim on top to deliver the existing SDP & O/A model - plus lots of other options (e.g. using RTCDataChannels for signaling). But RTCDataChannels are a whole other discussion. | "Let W3C experts to define a good JS API for WebRTC (with no SDP), let MMUSIC WG to define a SDP format for WebRTC, and then let JavaScript SIP experts to build JS libraries on top of it to play the SDP game, and we all will be happy. And telcos will be much more happy than they think. Let's get rid of all the SDP O/A stuff in the browser. The browser is not a phone and "fixed logic + fixed code" does not work here." | Strong like for changing to a JS Object API that also enables a shim to deliver the current SDP & O/A model - plus lots more. | Yes. Initially I was willing to work with it but now I clearly see and agree with the limitations outlined in http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00 | ||||||||||||
28 | ||||||||||||||||||||
29 | ||||||||||||||||||||
30 | ||||||||||||||||||||
31 | ||||||||||||||||||||
32 | ||||||||||||||||||||
33 | ||||||||||||||||||||
34 | ||||||||||||||||||||
35 | ||||||||||||||||||||
36 | ||||||||||||||||||||
37 | ||||||||||||||||||||
38 | ||||||||||||||||||||
39 | ||||||||||||||||||||
40 | ||||||||||||||||||||
41 | ||||||||||||||||||||
42 | ||||||||||||||||||||
43 | ||||||||||||||||||||
44 | ||||||||||||||||||||
45 | ||||||||||||||||||||
46 | ||||||||||||||||||||
47 | ||||||||||||||||||||
48 | ||||||||||||||||||||
49 | ||||||||||||||||||||
50 | ||||||||||||||||||||
51 | ||||||||||||||||||||
52 | ||||||||||||||||||||
53 | ||||||||||||||||||||
54 | ||||||||||||||||||||
55 | ||||||||||||||||||||
56 | ||||||||||||||||||||
57 | ||||||||||||||||||||
58 | ||||||||||||||||||||
59 | ||||||||||||||||||||
60 | ||||||||||||||||||||
61 | ||||||||||||||||||||
62 | ||||||||||||||||||||
63 | ||||||||||||||||||||
64 | ||||||||||||||||||||
65 | ||||||||||||||||||||
66 | ||||||||||||||||||||
67 | ||||||||||||||||||||
68 | ||||||||||||||||||||
69 | ||||||||||||||||||||
70 | ||||||||||||||||||||
71 | ||||||||||||||||||||
72 | ||||||||||||||||||||
73 | ||||||||||||||||||||
74 | ||||||||||||||||||||
75 | ||||||||||||||||||||
76 | ||||||||||||||||||||
77 | ||||||||||||||||||||
78 | ||||||||||||||||||||
79 | ||||||||||||||||||||
80 | ||||||||||||||||||||
81 | ||||||||||||||||||||
82 | ||||||||||||||||||||
83 | ||||||||||||||||||||
84 | ||||||||||||||||||||
85 | ||||||||||||||||||||
86 | ||||||||||||||||||||
87 | ||||||||||||||||||||
88 | ||||||||||||||||||||
89 | ||||||||||||||||||||
90 | ||||||||||||||||||||
91 | ||||||||||||||||||||
92 | ||||||||||||||||||||
93 | ||||||||||||||||||||
94 | ||||||||||||||||||||
95 | ||||||||||||||||||||
96 | ||||||||||||||||||||
97 |