Home/ Questions/Q 9038331
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-16T09:27:45+00:00

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

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0