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 29 users

Issue metadata

Status: WontFix
User never visited
Closed: Dec 2013
NextAction: ----
OS: ----
Pri: 1
Type: Bug

Sign in to add a comment

Sending 1169 byte message fails using Chrome with SCTP data channels enabled

Reported by, Aug 20 2013 Back to list

Issue description

What steps will reproduce the problem?
1. Enable SCTP data channels using Chrome 30+
2. Send a binary file using this demo page:

What is the expected result?
The receiving end gets an ArrayBuffer object that contains the file.

What do you see instead?
When sending a binary file it fails with the following message: "Uncaught SyntaxError: An invalid or illegal string was specified."
Text files on the other hand are working as expected.

What version of the product are you using? On what operating system?
Chromium 31.0.1602.0
Ubuntu 12.10 64bit

Please provide any additional information below.
I have also tried sending the file as a blob.
This issue was created because of the discussion in the following thread:!topic/discuss-webrtc/6XwPl5OOaWU
Project Member

Comment 1 by, Aug 20 2013

Thanks for filing the issue. We will investigate it.
Project Member

Comment 2 by, Aug 20 2013

Project Member

Comment 3 by, Aug 21 2013

FYI: an Syntax Error exception means that something went wrong in libjingle.
Project Member

Comment 4 by, Aug 21 2013

Labels: -Pri-2 Pri-1 SCTP Area-PeerConnection Mstone-31
Status: Assigned

Comment 5 by, Aug 28 2013

I have also tried to send binary data through data channel, after seeing this announcement!msg/discuss-webrtc/_zdJBwP4vNU/6Oy-GkbAi3UJ but i've got the same syntax error. That was M30 but this issue have been flagged with M31. So which Chrome version will really have this feature?

Comment 6 by, Sep 3 2013

Here's an example of how to transfer binary data (transfers a PNG file) over an SCTP datachannel. 

Note: there is a problem with large files at the moment. They result in an error "Uncaught SyntaxError: An invalid or illegal string was specified.".
5.9 KB View Download

Comment 7 by, Sep 3 2013

This is the libjingle logging message related to the large file failure:

[17:21:0903/] ERROR:SctpDataMediaChannel->SendData(...):  usrsctp_sendv: : [0x0000005a] Message too long

Comment 8 by, Sep 5 2013

When you go over 64k, you hit the SCTP protocol message-size limit.  Specifically, there are only 16 bits for a given 'chunk'.  We're looking into whether to document this as a limitation for a single send(), or put together some sort of fragmentation protocol.
Lally i tested this with your demo page dc-sctp-imageblob.html on Version 31.0.1650.2 canary & it didnot work for me. Did you try on latest canary?


Comment 10 Deleted

Comment 11 by, Sep 24 2013

I've been testing on checkouts that I build locally.   I'll see what the canary's doing -- wait, no canary for linux.  Is there a mapping between canary versions and checked-out versions.

Also, I've been using these two command-line flags:  --enable-data-channels --enable-sctp-data-channels

Perhaps some are unnecessary.
Project Member

Comment 12 by, Sep 24 2013

Thanks Lally, i don't think you need flags for sctp data channel in M31. You can check version  for your linux build by going to chrome://version. I tried on windows, will test on mac.

Comment 13 by, Sep 25 2013

I tested it on Canary a while ago and it was working, so we must have
broken something recently :(

I'll give it a test shortly with a smarter version of code for
data-channels shortly that actually creates the channel at the appropriate
time :)  (this code is not really right, it doesn't handle onnegotiation
Status: Fixed
Fixed in M31.

Comment 15 Deleted

This identical error comes up when I send standard ASCII text too quickly. I have an array of strings - if I push them too quickly the error raises.  They are all pretty short, around 80 bytes each, but too quickly calling send on the DataChannel raises this identical error.  Putting a 80ms sleep between each send and the problem stops.

OS X Version 32.0.1675.2 canary / updated to 32.0.1675.3 canary and same problem. 

Note that this can happen right on Localhost - sending from Chrome Canary over to Chrome on the same system (Version 30.0.1599.101).  But I'm having the same general problem with LibJingle self-compiled on Android 4.2.

My point is this; Try doing some sleeps on your data sending and see if the error clears up. It's likely that the identical error is raised by some kind of buffer overrun and not jus the use of binary data.

Comment 17 by, Nov 8 2013

I have the exact same problem.
Sending data in Version 30.0.1599.101 m results in "SyntaxError: An invalid or illegal string was specified.".
Sending data in Version 33.0.1702.2 canary results in "NetworkError: Could not send data".
In both cases the error appears while trying to send 1169 or more bytes.
I hope this error is being fixed soon. It makes sending large amounts of data a pain.
Project Member

Comment 18 by, Nov 8 2013

It seems the upper bound of one message is now 256K instead of 64K, so this is not fixed.

Comment 19 by, Nov 8 2013

The sctp xmit buffer's 256k (usrsctp_sysctl_set_sendspace's default value), but a single chunk is 64k -- it's only got a 16 bit length field.  We've chosen not to implement a fragmentation protocol -- it'd require more buffer memory for frag/defrag, and we quickly get into a place where the max-unfragmented-size is platform dependent.

With the belief that apps with large messages will have to buffer anyways -- they likely will have to handle some fragmentation no matter what we raise the limit to, as the limit would vary -- it's probably better to just create one stream per large transfer, instead of one message per.

As for problems for messages < 64k, please post some JS code that I can use to diagnose!
Project Member

Comment 20 by, Nov 8 2013

Status: WontFix
so, this is wontfix?
i don't think this is wontfix. 

Support for sending larger messages is waiting on SCTP protocol level changes. IOW, open, but low priority ATM.
However, #16/#17 indicate more general problems. 

Reporters, can you attach a sample page that exhibits the problem?
Project Member

Comment 22 by, Nov 8 2013

Status: Assigned
Summary: Sending 1169 byte message fails using Chrome with SCTP data channels enabled (was: Sending binary data fails using Chrome with SCTP data channels enabled)
I confirm #16 and #17 in my Chrome 31.0.1650.57 and the only way I found to avoid this issue is to wait for a ACK from the recipient after each chunk (64kB) sent.

It's true, if you send packet too quickly (I tested with an interval of 100ms, 200ms and sometimes it fails (not always at the same packet)

It works fine, perhaps it takes more time but I successfully sent big files (more than 1MB) using ArrayBuffer.

"the only way I found to avoid this issue is to wait for a ACK from the recipient after each chunk (64kB) sent." Sure, the file transfer over at has this solution.

More fundamental, but is there some reason the DataChannel is so nerfed? 

It kind of goes against the very name of "Real-Time...." in WebRTC

Comment 25 by, Nov 18 2013

There shouldn't be any need to wait for ACKs. Even if the lower layer is blocked, it should buffer in the upper layers and increase .bufferedAmount. 

Vikas, can you figure out what is going on here? Pull Jiayang and Peter in as needed.
Project Member

Comment 26 by, Nov 18 2013

Sure Justin, i will look into it tomorrow.


Comment 27 by, Nov 18 2013

Are we sure the data channel is properly set up before the first transmit?
If he's setting up a new DC before each xmit, it's possible he's getting
caught up there and it looks like a byte-rate limit.
Project Member

Comment 28 by, Nov 19 2013


I tried hard to recreate the problem today by trying to do multiple sends with more than 1169 bytes of data but it doesnot seem to fail for me. I also tried sending ASCII data quickly & that did not even fail.  

Stephen, can you share a simple test page that recreates it? 

I appreciate the follow-up.

Simple / readable / independent test pages are lacking in my view... what I have in my own code can't be shared at the moment. Part of the problem is that you have to leave a signaling server up and running. It's a complex topic too much for here I think ;)

I don't have that much time at the moment, but I did a fresh search for active / up to-date and came across this: - maybe we need to invite this guy to review this bug. I quote his page:

"This is done this way because, when multiple packets are sent over the WebRTC datachannel, the browsers seem to start rejecting packets blindly (based on # of packets, not size). Also, Chrome Canary will reject packets passed a certain size and Firefox will hang (for a few seconds) when a packet to large is specified, hence the limited chunk sizes."

I will follow-up when I have fresh/clean details to report. I don't want my previous experiences to taint my testing of current code. I'm doing fresh builds now.

Comment 30 Deleted

I want to clarify that the topic here is SCTP - specific. But I personally think the topic should be DataChannel specific.  How can it be that video is streaming at very high rates .. when DataChannel crumbles with many small sends... that's the general attitude that I am approaching this with.  Is there no aggregation/queue on the unreliable channel?

A simple/clean demo app (that avoids a lot of complex dependencies that you can't quickly assess if a factor) that lets you clearly see and control SCTP mode and packet size for large transfers would go a long way. Also Firefox/Chrome/Opera compatibility - with minimal legacy support so we are testing then newest builds and not some old workarounds. Any visitors or in-thread, please chime up ;)
Just quickly tested this using a connection between 2 chrome tabs attempting to send a 3MB file on (without JS modification, this works) :

1)Sending large packets:
Increasing line 47 ("return 100000;") by x10 to "return 1000000;" (specifies normal file chunk size for Chrome sessions)
This fails on my machine with "31.0.1650.57 m" & "33.0.1713.0 canary"
error "Uncaught SyntaxError: An invalid or illegal string was specified. "(31.0.1650.57 m) or "Uncaught NetworkError: Could not send data"(33.0.1714.0 canary) on "channel.send(message);"

2) Sending packets too fast (sending 5 per ack):
change ~line 321 to:
	if (data.chunk %5 == 0) {
		for (i=0;i<5;i++){
			send_chunk_if_queue_empty(, data.chunk+i, data.rand, data.hash);
This fails on my machine with "31.0.1650.57 m" & "33.0.1713.0 canary" (if this doesn't fail on yours try increasing that 5 to a larger #).
fails with "Uncaught SyntaxError: An invalid or illegal string was specified."(31.0.1650.57 m) or "Uncaught NetworkError: Could not send data "(33.0.1714.0 canary) on "channel.send(message);"
Also, I've never seen the datachannel's bufferedAmount in the function send_chunk_if_queue_empty return anything besides 0.

The line numbers I mention above are for the file /js/file-io.js 
Project Member

Comment 34 by, Nov 19 2013

Thanks Sam, i will give that a try.

Sending packets > 64 KB should result in an error in Chrome. We don't plan to support larger packets until the changes to do message splitting make it into the SCTP spec.

However, bufferedAmount should work properly. Vikas, any luck on a repro?
Project Member

Comment 36 by, Nov 21 2013

+Ronghua, who saw similar things at the SIPIt event this week.
Project Member

Comment 37 by, Nov 22 2013

 Justin, not yet i downloaded the code from github will modify & try recreation today.
Project Member

Comment 38 by, Nov 23 2013

Thanks for sharing recreation steps in comment #32. I can recreate the error "Uncaught NetworkError: Could not send data"(33.0.1716.0 canary) if i try send file size greater than of bigger size than 64KB. I think that's not the issue here as per Justin's comment above.

However i have not been able to see the second error when sending multiple time fast with the code changes, so far i tried sending 5 times, i will try to increase and then try send a file less than 64kb with your code on current canary.

Project Member

Comment 39 by, Nov 23 2013

@Samrerb, do you see the sending multiple data fast problem with your demo app, even if you send file of size less than 64kb?


Comment 40 by, Nov 25 2013

Sam, were you able to reproduce this after taking into account Vikas' suggestions in #39? If it is working as we describe (must wait for .onopen to start sending, must send < 64 KB per Send() call), we will close this bug.
I can confirm that sending 60kb chunks works fine here with large files in gigabytes range. I transferred multiple tera bytes while testing without error or data loss on chrome 32 Linux. 
Sending multiple chunks(<64k) quickly fails for me. 
A workaround for this bug is to catch the error while sending and try again after an interval of say 100ms. An implementation of this workaround can be found here:
Hi Vikas & Justin, 
Sorry for the slow reply this.

In response to #39 & #40 - I could not recreate that issue, as expected, with Chrome or Chrome Canary when sending files < 64KB (even when sending hundreds of packets per ack).

Project Member

Comment 44 by, Dec 17 2013

Thanks Sam, is it fine to close the issue then?


Comment 45 by, Dec 17 2013

Yes, please close. We can reopen if there is some new finding.
Project Member

Comment 46 by, Dec 17 2013

Status: Invalid
thanks Justin.
Project Member

Comment 47 by, Feb 24 2014

 Issue 2953  has been merged into this issue.

Comment 48 by, Apr 10 2014

I fight this problem already for months and I can give you an example:
Chrome Version 34.0.1847.116 m

Use this Website for the Test:
To create Strings of variable length use something link this website:

Sending 1168 'a' works, but send 1169 and it breaks.
Now I played around with binary data:
Use this text and test. It will work, but now add at least 4 'a'  and it breaks again, but this time with far less than 1169 bytes.
I assume the data is converted to utf-8 or something, which inflates the data (some bytes get expanded to 2 or more bytes).

I propose that this problem is solved in near future! It sucks to write data splitting and reassembling code.

Project Member

Comment 49 by, Apr 10 2014


The demo  is using rtp data channels, the test with 1169 'a' seems to work fine with the sctp data channel demo posted here :
Can you try with sctp and provide feedback?


Comment 50 by, Apr 10 2014

Ah, at last SCTP is working.
With SCTP there are no problems. I just tested my own implementation with it, too.
Thanks for the test link.

Problem solved... for now. ^^

Comment 51 by, Apr 10 2014

Where did it come from the limit of 1169 bytes?

Comment 52 by, Aug 23 2014

Even with SCTP we can still not handle really long strings (try converting a few megs into a base64 string and input it to 

Comment 53 by, Aug 25 2014

orhiltch: Messages longer than a few (*cough* 16 *cough*) kb are unlikely to work well.  SCTP doesn't have large buffers internally for storing these while transmitting/fragmenting/defragmenting/etc.  Please break them up into chunks when sending, and de-chunkify on the other side.  It'll be much nicer to the memory pressure in chrome tab, and the system as a whole.   It'll also scale quite well to much larger sizes.
Project Member

Comment 54 by, Oct 5 2016

Status: WontFix

Sign in to add a comment