New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
This site will be read-only for 3-4 hours starting at Sunday, 08:00AM PDT
Starred by 36 users

Issue metadata

Status: Fixed
User never visited
Closed: Nov 2013
NextAction: ----
OS: ----
Pri: 1
Type: ----

Sign in to add a comment

Test SCTP data channel interop with Firefox

Project Member Reported by, Aug 21 2013 Back to list

Issue description

Verify that our implementation of data channels works with Firefox.
Project Member

Comment 1 by, Aug 29 2013

Some update, have added some test code locally in apprtc demo for testing SCTP between FF & chrome. In the code, i created a single bi-directional data channel between 2 peers. Facing an issue where the data connection state is writable but not readable for chrome. Will investigate further, console logs attached.

Tested between FF 24 & Chrome Version 31.0.1612.0 (219627).

6.1 KB View Download
Project Member

Comment 2 by, Sep 20 2013


Was able to get SCTP data channel working between  FF 26.0a1 (2013-09-15)  & chrome 31.0.1612.0. The Chrome build i had was a local build with following changes: 

a. sctp port hard coded to 5000. In future, we should parse SDP to use SCTP port. See crbug/295771.

b. Changed PPID to 51 in Chrome.

I think it would be worth testing Chrome 31 with FF 23, 24 & 25 releases once we have a fix for crbug/295771.


Comment 3 by, Sep 22 2013

just thought it was worth to add a link to crbug/295771:
Is your code perhaps somewhere available perhaps, Vikas? Here is only a log available.

I see that in the latest canary the SCTP channels work good. That's awesome. But I wonder how to get it work between FF and Chrome. Is this just about the Ice Candidates that are being sent in de SDP in Firefox?

Thanks, Fabian

I'm about to land FF bug 916429 which will have a sctpmap line as described in the standard like this:

a=sctpmap:5000 webrtc-datachannel 16

Hopefully this helps.

Project Member

Comment 6 by, Oct 2 2013

Thanks, ethanhugg! I opened to make the same change in Chrome.
Thanks for the feedback Ethan. So this would be in FF 27? I will test interop again once your fix lands. So Ethan are you doing this change only in FF 27 or older versions as well?

@Jiayang, do you know if we need to do any changes on our end? FF will use sctpmap line instead of fmtp line for data channels. 
Sorry Jiayang didnot see comment #6.
Project Member

Comment 9 by, Oct 2 2013

If I read the bugzilla thread correctly, FF does not require the remote SDP having a=sctpmap; Chrome doesn't check the line in the remote SDP either. So it should not affect interop. 

But I still opened a bug to make the same change in Chrome for correctness. See comment #6.
Project Member

Comment 10 by, Oct 2 2013

Thanks Jiayang for clarifying.

This patch landed on Mozilla-Central today so it will be in the Nightly build tomorrow and in Firefox 27.  I don't think we will uplift this patch to other versions.  This also gives me more time to fix it if it's not exactly right.

This does not require a=sctpmap or anything really from the other side.  It can't because it has to work with earlier versions of Firefox.  We reflect the value for streams if it is supplied but nothing else is negotiated.  Of course the streams value doesn't matter that much anyway because we will create more streams than that if they are requested.  It's not a hard limit.

Is data channel interop working currently?
Are there any firefox or google maintained apps that can be used to check this?

Looks like it is, but only in FF Nightly/Chrome Canary from what I can tell (tested using ). 

Also, chat will work but file transfer won't work (on for larger files) as the site defines different file chunk sizes to send over the datachannel for each browser. 
Per testing with Chrome 32.0.1671.3 against FF nightly from a little while ago, chat works, and file transfer from Chrome to FF works, but transfer from FF to chrome stops after 16K.  I would assume this is an issue of not implementing the PPID for non-final chunks, as FF chunks to 16K/message when sending.

With Chrome 33/Canary using rtccopy, it appears Chrome has to create the room first or they won't connect (note: chrome creating the 'room' first means that the offer comes from FF).  The same transfer issues appear.  I haven't managed to figure out yet why they're not connecting; but I didn't see a successful DTLS connection.
Project Member

Comment 15 by, Nov 21 2013

Labels: Area-PeerConnection
Lally/Jiayang - can you take a look at #14 and advise?

Comment 16 by, Nov 21 2013

I'll take a look.

Comment 17 by, Nov 22 2013

I just tested between FireFox Nightly and Chrome Canary 33.0.1715.0. 
The connection can be established with either FF creating the room or Chrome creating the room. 
Chat worked fine. File transfer had the issue Randell mentioned: if FF sends a file >16KB from to Chrome, Chrome will only receive the first 16KB, for the reason Randell stated. The reverse direction does not have the limit except Chrome's 64KB limit per send.

I think we didn't implement the PPID for non-final trunks for the same reason that we didn't remove the 64KB limit. Is that right, Justin/Lally?
Project Member

Comment 18 by, Nov 22 2013

OK, that makes sense. Since we don't plan to implement the non-final PPID stuff, app developers will need to use a max msg size of 16K when sending from Firefox.

Comment 19 by, Nov 22 2013

Comment 20 by, Nov 22 2013

I don't get why we don't receive the other chunks.  FF sends them, and we
should still be able to receive them.  Does the code only expect one
message? The PPIDs for the intermediate and _LAST of each kind
(text/binary) are mapped to the same on the way in, so they shouldn't be
treated any differently.
Project Member

Comment 21 by, Nov 22 2013

Right, but we would have to buffer the intermediates so that we emit a single large message upwards, instead of a bunch of different onmessage callbacks. Which I don't think we want to do.

Comment 22 by, Nov 22 2013

Oh, I meant that I don't get why the app seems unhappy with a bunch of
onmessage callbacks.  It should get one per FF chunk -- is it only waiting
for one message and then ignoring further onmessage callbacks?
You're supposed to get one onmessage callback per Send(), not one per chunk.  I'm going to discuss PPID-chunking support with Justin by email

Comment 24 by, Nov 22 2013

Could make sense to have a "onprogress" or "onchunk" event dispatched when
chunks of a big send() message are being received? Doesn't need to have any
actual data, just a notification about an incoming message...

Send from my Samsung Galaxy Note II
El 22/11/2013 19:02, <> escribi
Project Member

Comment 25 by, Nov 22 2013

The goal was to provide a websocket-compatible API, and WS doesn't provide any mechanism like this.

If the app does its own chunking, it can of course track progress trivially.

Comment 26 by, Nov 22 2013

I know, my proposition was more oriented for statistics and to notify to
the user, more of a "onprogress" than a "onchunk" in fact. Maybe this would
be useful for WebSockets, DataChannels would get someway this info via the
stats api thanks to WebRTC but websockets doesn't have any similar

Send from my Samsung Galaxy Note II
El 22/11/2013 19:36, <> escribi

Comment 27 by, Nov 25 2013

Jiayang to look into what build this was resolved in.
Project Member

Comment 28 by, Nov 26 2013

Labels: -Mstone-31 Mstone-32
Status: Fixed
Verified that Chrome 32 and higher versions work well with FireFox Nightly on for files < 16KB.

"Fixed"... 16K is a pretty small file... :-(

Seriously, we need a coordinated answer for application developers.  We don't even have an idea when ndata (and support for multi-message IOR) will land in SCTP, and then get into the field in both browsers.  The current status not only requires browser sniffing, but also version sniffing.

If there's no way Chrome will add the PPID chunking (I counted, it's ~<20ish lines in FF), then we should expose a property that eventually may be the "minimum maximum" transfer size once a proposal is made for that and it's implemented (though I have some concerns about that approach unless we slow down association startup).  This would allow apps to query instead of sniff/guess/fail.

The downside to this is that all applications transferring externally-generated objects MUST implement application chunking, which is what we were avoiding by implementing the WebSockets API.
Project Member

Comment 30 by, Nov 26 2013

Agree we should expose some property that indicates the maximum send() size. For right now, that value is implicitly 16K.

I'm not sure I understand the association startup comment though.

Regarding ndata etc, I was under the impression that this work was well underway and would be ready in the not-too-distant future. Is this not true?
Just wanted to let you know:

Between Canary-Canary I get an error (uncaught network error: could not send data) when I try to send something larger than 256KB. When I try to send something from Canary to FF Nightly the threshold is 127KB and it fails silently.

Feel free to try for yourself: 

To connect peers. And what I do next is in the console:
var KB = 256 // example size
var data = new ArrayBuffer(KB * 1024);

So, no 16KB here.

Comment 32 Deleted

I started chunking data URL's to send them to the other side. Sometimes it worked, sometimes I got the error "Uncaught NetworkError: Failed to execute 'send' on 'RTCDataChannel': Could not send data".

Then I added a for loop just to build in some delay between the sends. But apparently this error comes back depending on a combination of chunk size and loop delay. If the chunk size is too big or the loop delay too short I get a bigger change of this error. But it's not a constant thing Looks like a buffer thing.   
Project Member

Comment 34 by, Dec 18 2013

fabiangort: could you provide a standalone test page?
Hi, I have this page for you: (initializes the connection)

And a test image:

After the status is *connected* you can start sending the image, which will happen automatically right after you picked the file. You may need to play a bit with the loop and chunk size to get the error show up in the console.

Comment 36 by, Dec 18 2013

The default send buffer in usrsctp is (AFAIK) 256k.  So, you can get that if you call send() frequently enough -- each with a small (~16k) chunk -- such that the 256k fills up for transmit chunks.  That's what #33 looks like.  #31 looks like it's just too big to send at all, as the message would be bigger than the buffer as a whole.

As a first estimate, making that reliable would be to expose the buffer state and size, as part of a flow-control layer.  If the app has to do the chunking, flow control makes sense.

Comment 37 Deleted

Sign in to add a comment