Using SignalR as a Service Level for WebRTC

Question

This is the next question from another question that I asked, but with more accurate information.

I have two fundamentally identical web pages that show WebRTC, one of which uses XSockets as the base signaling level, and one uses SignalR as the signal level.

The two backends are fundamentally identical, differing only at those points where they (obviously) have different ways of transferring data to the client. Likewise, the TypeScript / JavaScript WebRTC code on the two clients is completely identical, since I abstracted the signaling level.

The problem is that the XSockets site is running sequentially and the SignalR site is failing (mostly sequentially, although not completely). It usually fails when calling peerConnection.setLocalDescription() , but it may also fail; or it can (sometimes) even work.

Here you can see two different pages:

XSockets Website: http://xsockets.demo.alanta.com/

SignalR Website: http://signalr.demo.alanta.com/

The source code for both is https://bitbucket.org/smithkl42/xsockets.webrtc , with the XSockets version in the xsockets branch, and the SignalR version on the signalr branch.

So my question is: does anyone know of any reason why using one signal level instead of another might have some value for WebRTC? For example, does one or the other send Unicode strings instead of ANSI? Or have I misidentified the problem, and the real difference elsewhere?

Answer 1

Figured it out. It turns out that SignalR 1.0 RC1 has an error in it that changes any "+" in a string to a space. So the lines in SDP looked like this:

a=ice-pwd:qZFVvgfnSso1b8UV1SUDd2+z

The following have changed:

a=ice-pwd:qZFVvgfnSso1b8UV1SUDd2 z

But since not every SDP has a “+” in it on the critical line, sometimes it will work. Everything is explained.

The bugs are reported by the good people working on SignalR (see https://github.com/SignalR/SignalR/issues/1194 ), and meanwhile the simple encodeURIComponent() and decodeURIComponent() around the lines in question has been fixed.