6

This is a follow-up to another question I asked, but with more precise information.

I have two fundamentally identical web pages that demo WebRTC, one using XSockets as the backend signaling layer, and one using SignalR as the backend signaling layer.

The two backends are fundamentally identical, differing only at the points where they (obviously) have different ways of sending data down to the client. Similarly, the TypeScript/JavaScript WebRTC code on the two clients is completely identical, as I've abstracted out the signaling layer.

The problem is that the XSockets site works consistently, while the SignalR site fails (mostly consistently, though not completely). Usually it fails while calling peerConnection.setLocalDescription(), but it can also fail silently; or it can (sometimes) even work.

You can see the two different pages in operation here:

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

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

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

So my question is: does anybody know of any reason why using one signal layer instead of another would make any difference to WebRTC? For instance, does one or the other send back Unicode strings instead of ANSI? Or have I misdiagnosed the problem, and the real difference is elsewhere?

Community
  • 1
  • 1
Ken Smith
  • 20,305
  • 15
  • 100
  • 147

1 Answers1

2

Figured it out. Turns out that SignalR 1.0 RC1 has a bug in it that changes any "+" in a string into a space. So lines in the SDP that looked like this:

a=ice-pwd:qZFVvgfnSso1b8UV1SUDd2+z

Were getting changed into this:

a=ice-pwd:qZFVvgfnSso1b8UV1SUDd2 z

But because not every SDP had a "+" in it on a critical line, sometimes it would work. Everything explained.

The bug has been reported to the good folks working on SignalR (see https://github.com/SignalR/SignalR/issues/1194), and in the meantime, a simple encodeURIComponent() and decodeURIComponent() around the strings in question fixed it.

Ken Smith
  • 20,305
  • 15
  • 100
  • 147
  • Ken, Did you use SignalR for signalling only or to transport video/audio data? – Elan Hasson Oct 07 '13 at 01:05
  • @ElanHasson - For signaling only. WebRTC is complex, and incompletely implemented (basically only Firefox and Chrome, with some interoperability issues), but remains the preferred transport for realtime video/audio data. I haven't tried using WebSockets for delivering audio/video, but from what I know of its design and typical implementations, I think you'd have some real problems. And I think long polling, Server Side Events and other similar approaches would be a non-starter. – Ken Smith Oct 07 '13 at 15:20
  • 1
    I agree. I just switched to Flex/Red5 for now. Red5 can transcode live streams that HTML5 video element can consume, with a fallback on flash viewer. I died a little inside while developing this solution. – Elan Hasson Oct 08 '13 at 19:19