W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: [rtcweb] Proposed message to send to the IETF rtcweb and W3C WebRTC working groups.

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Mon, 22 Jul 2013 19:46:23 +0200
Message-ID: <CALiegfkBL1jp=4Dw9K45CBkCLR1iFPh2-9mO18XkT+fSra=1xQ@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:35 UTC