- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Mon, 22 Jul 2013 19:46:23 +0200
- To: Philipp Hancke <fippo@goodadvice.pages.de>
- Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>, XMPP Jingle <jingle@xmpp.org>
2013/7/22 Philipp Hancke <fippo@goodadvice.pages.de>: > Am 22.07.2013 17:14, schrieb Iñaki Baz Castillo: > >> Great. First thing you should complain about is the fact that current >> WebRTC specification makes unfeasible for a browser to use SDP-XML as >> defined by XEP-0167. > > > I said this before, but since you insist on repeating your argument i'll > repeat mine: I have running code doing exactly that. > > It's hard work and there are some points where this is PITA, I have > discovered numerous bugs in chrome (and the jingle spec) along the way, but > it's certainly not unfeasible. > > > So far, this mapping works using the elements already defined in XEPs 0167, > 0293, 0294 and 0320 even. > http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03#section-4.1 has a quite > concrete list of features of what functionality the mapping between SDP and > the xmlish SD has to define. Thanks for the information. Just wondering if you would feel more comfortable with a WebRTC API that provides you real JS Objects/Classes with all the media parameters and transport information (instead of a SDP blob string) so you don't need to parse a plain-SDP (which will be different in each vendor's browser and browser's release and others WebRTC compatible devices) but instead take the data from JS Object structures and use it to construct your own signaling protocol. Thanks a lot. -- Iñaki Baz Castillo <ibc@aliax.net>
Received on Monday, 22 July 2013 17:47:13 UTC