Data channel support about bowser

[stefanalund]

Bowser will get DataChannel support as soon as it is supported the OpenWebRTC:

EricssonResearch/openwebrtc#3

[aamirkhan24]

any update regarding release of support for the WebRTC DataChannel ?

[superdump]

We're hoping to have data channel support added very soon. And we're hoping that very soon means weeks as opposed to months. 😄

[stefanalund]

DataChannel has now landed in OpenWebRTC and that means Bowser will also get as soon as you rebuild with latest OpenWebRTC master. I will also make a new release of Bowser on the App Store. Thanks for your patience!

EricssonResearch/openwebrtc#3

[szimek]

@stefanalund That's awesome! If I want to try to build Bowser with data channel support myself, is it enough to clone OpenWebRTC and Bowser and run the build script or does it require some changes in Bowser code as well?

[stefanalund]

@szimek Since I haven't confirmed it myself yet (building right now) I cannot make any promises, BUT it should not require any changes to Bowser. Give it a try and report back if you have problems. Note that you need to rebuild dependencies:

https://github.com/EricssonResearch/openwebrtc/wiki/Building-OpenWebRTC#update-openwebrtc

[szimek]

@stefanalund Have you managed to build it successfully? I've just tried compiling Bowser (after building OpenWebRTC for a loooong time), but I'm getting the following errors: https://gist.github.com/szimek/3ce3acf4d21765938cc3

[stefanalund]

Yeah it takes a while to build. I will resume my work in an hour or so. My guess would be that some addition library needs to be added to the Bowser Xcode project.

[superdump]

@szimek You need to add the new libraries to the project:

openwebrtc/openwebrtc-deps-armv7-ios/lib/gstreamer-1.0/libgstsctp.a
openwebrtc/openwebrtc-deps-armv7-ios/lib/libgstsctp-1.0.a
openwebrtc/openwebrtc-deps-armv7-ios/lib/libusrsctp.a

[stefanalund]

As @superdump says these new libs needs to be added. On top of that we found that most apps will feature probe for DataChannel support on the prototype and therefore we had to add this:

EricssonResearch/openwebrtc@529ddae

Unfortunately there still seems to be a minor bug in Bowser preventing everything from working correctly, we are looking in to it now. It does work on OS X Safari so it should not be far off. You can test this yourself:

http://www.openwebrtc.io/blog/2014/10/31/webrtc-in-safari-using-openwebrtc

Our demo app has also been updated to support DC:

http://demo.openwebrtc.io/

[szimek]

@stefanalund After adding these libraries I managed to built Bowser, but as you just pointed out it doesn't really work :)

I'm trying it out in Safari, but have another issue:

var config = {
  iceServers: [{ url: "stun:stun.l.google.com:19302"}],
  iceTransports: "all"
};
var pc = new RTCPeerConnection(config, {});
var dc = pc.createDataChannel("label", {});
dc.reliable // Bowser returns undefined, Chrome and FF return true

This code comes from peer.js library that I'm using, but I can't find anything about reliable property on RTCDataChannel in the latest WebRTC spec.

[stefanalund]

@szimek interesting, perhaps could have been removed. We typically try to be pretty close to the latest W3C spec and are therefore not always compatible with older libs and apps. Does this break your app? If so we may consider adding it, or prompt peer.js to make it conditional.

@adam-be @DanielLindstrm any thoughts?

[szimek]

@stefanalund This is actually a part of peer.js library that checks for SCTP support: https://github.com/peers/peerjs/blob/master/dist/peer.js#L1535-L1544, so the library unfortunately reports that Safari with OpenWebRTC extension does not support SCTP (or at least reliable data channels). I can't find anything about this property in previous versions of WebRTC spec as well, so I'm not really sure where it comes from, or how to check otherwise if browser supports reliable channels or not. Maybe it's not an issue anymore and this check could be simply removed from the library.

[stefhak]

The data channels can be set up with options, one of them is if transport
should be reliable (i.e. data transmitted until successful) or not
(coarsely - I think you can define pretty finely the intended behaviour,
like number of transmits). Default (if no option is given) is that the data
channel should be set up as "reliable". Can this be the problem (i.e. our
implementation does not default to reliable)?

On Wed, Mar 4, 2015 at 12:49 PM, Szymon Nowak [email protected]
wrote:

@stefanalund https://github.com/stefanalund This is actually a part of
peer.js library that checks for SCTP support:
https://github.com/peers/peerjs/blob/master/dist/peer.js#L1535-L1544, so
the library unfortunately reports that Safari with OpenWebRTC extension
does not support SCTP. I can't find anything about this property in
previous versions of WebRTC spec as well, so I'm not really sure where it
comes from, or how to check otherwise if browser supports reliable channels
or not. Maybe it's not an issue anymore and this check could be simply
removed from the library.

—
Reply to this email directly or view it on GitHub
#27 (comment)
.

[szimek]

Most likely :) I've disabled this check to make it pass and got another issue, this time with OpenWebRTC itself:

$ ./out/x86_64-apple-darwin/bin/openwebrtc-daemon
** Message: Loaded namespace: GLib
** Message: Loaded namespace: GObject
** Message: Loaded namespace: Gio
** Message: Loaded namespace: GIRepository
** Message: Loaded namespace: Owr

(<unknown>:31462): GStreamer-WARNING **: /Users/szimek/Projects/src/bowser/openwebrtc/scripts/dependencies/gstreamer/gst/gstpad.c:4029:GstFlowReturn gst_pad_push_data(GstPad *, GstPadProbeType, void *):<sctpenc_3:src> Got data flow before stream-start event

(<unknown>:31462): GStreamer-WARNING **: /Users/szimek/Projects/src/bowser/openwebrtc/scripts/dependencies/gstreamer/gst/gstpad.c:4034:GstFlowReturn gst_pad_push_data(GstPad *, GstPadProbeType, void *):<sctpenc_3:src> Got data flow before segment event

(<unknown>:31462): GStreamer-WARNING **: /Users/szimek/Projects/src/bowser/openwebrtc/scripts/dependencies/gstreamer/gst/gstpad.c:3795:GstFlowReturn gst_pad_chain_data_unchecked(GstPad *, GstPadProbeType, void *):<dtls_srtp_rtp_encoder_1:data_sink> Got data flow before stream-start event

(<unknown>:31462): GStreamer-WARNING **: /Users/szimek/Projects/src/bowser/openwebrtc/scripts/dependencies/gstreamer/gst/gstpad.c:3800:GstFlowReturn gst_pad_chain_data_unchecked(GstPad *, GstPadProbeType, void *):<dtls_srtp_rtp_encoder_1:data_sink> Got data flow before segment event

(<unknown>:31462): GStreamer-WARNING **: /Users/szimek/Projects/src/bowser/openwebrtc/scripts/dependencies/gstreamer/gst/gstpad.c:4029:GstFlowReturn gst_pad_push_data(GstPad *, GstPadProbeType, void *):<data_sink:proxypad14> Got data flow before stream-start event

(<unknown>:31462): GStreamer-WARNING **: /Users/szimek/Projects/src/bowser/openwebrtc/scripts/dependencies/gstreamer/gst/gstpad.c:4034:GstFlowReturn gst_pad_push_data(GstPad *, GstPadProbeType, void *):<data_sink:proxypad14> Got data flow before segment event

(<unknown>:31462): GStreamer-WARNING **: /Users/szimek/Projects/src/bowser/openwebrtc/scripts/dependencies/gstreamer/gst/gstpad.c:3795:GstFlowReturn gst_pad_chain_data_unchecked(GstPad *, GstPadProbeType, void *):<dtls-encoder:sink> Got data flow before stream-start event

(<unknown>:31462): GStreamer-WARNING **: /Users/szimek/Projects/src/bowser/openwebrtc/scripts/dependencies/gstreamer/gst/gstpad.c:3800:GstFlowReturn gst_pad_chain_data_unchecked(GstPad *, GstPadProbeType, void *):<dtls-encoder:sink> Got data flow before segment event
Segmentation fault: 11

The app (https://github.com/cowbell/sharedrop / https://www.sharedrop.io/) works fine in Chrome and Firefox.

[stefanalund]

To be clear, our implementation supports both these modes. Whether we expose an attribute to JavaScript is another question. I think @DanielLindstrm knows best.

[stefhak]

I was completely wrong in this comment - removing all I wrote!

On Wed, Mar 4, 2015 at 1:29 PM, stefan hakansson [email protected] wrote:

The data channels can be set up with options, one of them is if transport
should be reliable (i.e. data transmitted until successful) or not
(coarsely - I think you can define pretty finely the intended behaviour,
like number of transmits). Default (if no option is given) is that the data
channel should be set up as "reliable". Can this be the problem (i.e. our
implementation does not default to reliable)?

On Wed, Mar 4, 2015 at 12:49 PM, Szymon Nowak [email protected]
wrote:

@stefanalund https://github.com/stefanalund This is actually a part of
peer.js library that checks for SCTP support:
https://github.com/peers/peerjs/blob/master/dist/peer.js#L1535-L1544, so
the library unfortunately reports that Safari with OpenWebRTC extension
does not support SCTP. I can't find anything about this property in
previous versions of WebRTC spec as well, so I'm not really sure where it
comes from, or how to check otherwise if browser supports reliable channels
or not. Maybe it's not an issue anymore and this check could be simply
removed from the library.

—
Reply to this email directly or view it on GitHub
#27 (comment)
.

[szimek]

@stefhak I think they are using it only in this check, later on they are doing it like you suggested, e.g. https://github.com/peers/peerjs/blob/master/dist/peer.js#L565-L570. Anyway, I think now all browsers that support WebRTC data channels, support reliable channels as well, so I'll probably just remove this check completely.

[szimek]

@stefanalund One new small issue: according to the specs in both promise based and legacy versions of createOffer method, RTCOfferOptions parameter is optional, but I'm getting an error telling me that either first or third argument must be an object.

BTW. Should I report such things here or in OpenWebRTC repo?

[stefanalund]

Please report in the OpenWebRTC repo as this is not unique for Bowser. Thanks.

[stefanalund]

@szimek could you report the segfault as another issue? https://github.com/EricssonResearch/openwebrtc/issues

[szimek]

@stefanalund I will, but I need to figure out how to reproduce it more or less consistently - currently it seems completely random.

[unanimous1]

ETA on datachannel in Bowser in the App Store?

[stefanalund]

@unanimous1 we found a few issues when running DC on iOS and are currently investigating. Will report back when we have more information. Thanks for your patience!

[unanimous1]

Just checking in on Datchannel support. Any updates on Bowser support?

[stefanalund]

If you compile Bowser yourself it will get DC support. However we are still investigating issues with Bowser on 64-bit, which is now a requirement for the App Store.

[pearcetm]

Any update on this topic? It has been a few months since any discussion... the chat function of OpenWebRTC on the demo (http://demo.openwebrtc.io/) is working in other browsers, but I can't get it to enable on Bowser.

[stefanalund]

Sorry for not closing this issue earlier, Bowser actually has DataChannel support as of version 0.5: http://www.openwebrtc.org/blog/2015/3/4/now-with-100-more-data-channel-support

If you have problems getting it to work that should be treated as a new bug/issue. @pantaoran says he has been using it for a while.

[pantaoran]

Well that is true, it "works" but with big reservations. As we found in the other issue, enabling DC actually seems to break audio/video reception on owr/Bowser side, so I have to put "works" in double quotes for now.

[pearcetm]

The reason I asked is that the demo at http://demo.openwebrtc.io/ wasn't allowing the "chat" checkbox to be enabled (iPhone 6, current iOS [8]), which from the code was based on checking for datachannel support. There was another datachannel-based chat demo that also wasn't working. I'm in the process of testing a couple of libraries, if I can figure out what's going on I will post something.

[pantaoran]

That doesn't happen to me, when I try with Bowser 0.5 on iPad Air 2 with iOS 8 it has support and the chat checkbox can be clicked.

[stefhak]

Just to confirm: I get the same behavior as @pantaoran on iPhone 5s / iOS9 (i.e. the chat checkbox is there, but if selected audio and video reception goes away on Bowser side, and that is independent of whether "call" is pressed on Bowser or the other endpoint which is FF in my case).

[pearcetm]

Ok, I figured out the issue - when going to http://demo.openwebrtc.io:38080 WITHOUT a hash for the room id, the chat box was clickable. When entering a room via a url with the hash it was disabled for whatever reason. I can confirm that iPhone6 has datachannel support... thanks guys, you rock!

[superdump]

@pearcetm - with a hash does autojoin for the session with your previously selected options for convenience.