Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Data channel support #27

Closed
szimek opened this issue Dec 22, 2014 · 34 comments
Closed

Data channel support #27

szimek opened this issue Dec 22, 2014 · 34 comments

Comments

@szimek
Copy link

szimek commented Dec 22, 2014

Any chances to get data channel support? It would be so awesome if sharedrop.io could work on iOS.

@stefanalund
Copy link
Contributor

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

EricssonResearch/openwebrtc#3

@aamirkhan24
Copy link

any update regarding release of support for the WebRTC DataChannel ?

@superdump
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Author

szimek commented Mar 3, 2015

@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
Copy link
Contributor

@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
Copy link
Author

szimek commented Mar 3, 2015

@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
Copy link
Contributor

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
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link
Author

szimek commented Mar 4, 2015

@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
Copy link
Contributor

@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
Copy link
Author

szimek commented Mar 4, 2015

@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
Copy link

stefhak commented Mar 4, 2015

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 notifications@github.com
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
Copy link
Author

szimek commented Mar 4, 2015

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
Copy link
Contributor

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
Copy link

stefhak commented Mar 4, 2015

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

On Wed, Mar 4, 2015 at 1:29 PM, stefan hakansson stefhak@gmail.com 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 notifications@github.com
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
Copy link
Author

szimek commented Mar 4, 2015

@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
Copy link
Author

szimek commented Mar 4, 2015

@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
Copy link
Contributor

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

@stefanalund
Copy link
Contributor

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

@szimek
Copy link
Author

szimek commented Mar 9, 2015

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

@unanimous1
Copy link

ETA on datachannel in Bowser in the App Store?

@stefanalund
Copy link
Contributor

@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
Copy link

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

@stefanalund
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

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
Copy link

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
Copy link

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
Copy link

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
Copy link

stefhak commented Sep 25, 2015

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
Copy link

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants