- From: Tim Panton new <thp@westhawk.co.uk>
- Date: Fri, 5 Jul 2013 10:30:26 +0100
- To: Iņaki Baz Castillo <ibc@aliax.net>
- Cc: Philipp Hancke <fippo@goodadvice.pages.de>, "public-webrtc_w3.org" <public-webrtc@w3.org>
On 5 Jul 2013, at 10:07, Iņaki Baz Castillo wrote: > 2013/7/4 Philipp Hancke <fippo@goodadvice.pages.de>: >> I'd also note that jingle might even define a SDP <content/>. However, the >> xmpp standards foundation is dominated by XML lovers who would never let >> that happen! :-) We actually did that with the ROAP protocol (pretty much had no option) base64 encoded the ROAP object and added as a non-std tag in Jingle. I took some pleasure in deleting that from the source tree when ROAP died. > > XEP-0167 clearly defines a XML based SDP, and also defines a mapping > between XML-SDP and plain-SDP for compatibility purposes (I expect in > a gateway). > > XMPP is all XML, so fot them it is good to be able to parse stanzas > and SDP bodies with the same tool. > > In contrast, WebRTC is not a "protocol" (or should not be), but > mandating SDP O/A forces a media signaling protocol. And the worst, it > gives no chance to the developer to build a custom media signaling > protocol since that requires hyper-complex parsing of the SDP blob > generated by the browser. To see what that parsing looks like - see https://github.com/phono/PhonoSDK/blob/master/modules/phono-js/src/main/js/phono.sdp.js and https://github.com/phono/PhonoSDK/blob/master/modules/phono-js/src/main/js/phono.jsep-audio.js Ugly, but not impossible. > > > > >> In order to successfully deploy such a service that developer will need to >> learn quite alot about things like codecs, RTP, packet loss, bandwidth >> estimation, NAT, ICE, STUN, TURN, signalling protocols, conferencing >> topologies? Should I also mention that this web developer might be required >> to identify broken hardware in customer networks? >> >> The "RTC Web Developer" requires quite a unique skillset. SDP is just the >> tip of the iceberg. > > Nothing in this argument from you makes SDP a good choice. You (and > all the list) will see a new API proposal ver soon, much simpler and > more powerful than current "API". If we had developed the constraints API - with a suitable way of expressing the web developer's aspirations, the SDP blob would not have needed to be an API. But since we stopped at the single "do we need video" ? choice, everything else has to be done by manipulating the SDP. You'll notice that in phono, we parse the SDP into an object model, do whatever we need to with it, then re-emmit the relevant output, either as XML for signalling, or as SDP for setLocal() and friends. This is clumsy and brittle but it works ok for now. Tim.
Received on Friday, 5 July 2013 09:30:56 UTC