As you probably know SignalR supports multiple transports. The favor one and most powerful one is of course WEBSOCKET transport. 
Unfortunately this transport cannot be always used in any infrastructure. When your application is started the client side of SignalR will check what transports are supported. 
Interestingly there is a similar check at the server side. 

For example, if you see following request

POST /Daenet.MySpy/signalr/signalr/send?transport=foreverFrame&connectionId=cd17bb01-23de-4181-97da-6514b9bbb58e HTTP/1.1 

which is responded by following response, it means that web socket transport is not supported. If infrastructure does not support streaming SIgnalR will use fallback transport. In a case of Internet Explorer this will be foreverFrame as shown above. 
To be sure that the server is not the problem, try to find out the request like following one:

GET /Daenet.MySpy/signalr/signalr/connect?transport=webSockets&connectionId=cd17bb01-23de-4181-97da-6514b9bbb58e&connectionData=%5B%7B%22name%22%3A%22trackerhub%22%7D%5D&tid=6 HTTP/1.1 

If this request has failed with error 500 it means that the server does not support websockets. In this specific case server means the server (IIS) supports WebSockets, but ASP.NET version of your application which hosts SignalR does not support websockets. 
It sound wired, buiit is not. If the server does not support WebSockets (for example Windows Server 2008) you will never get error 500 back. The client will switch to fallback transport automatically. This error is related to ASP.NET. 
To fix it you need following in the web.config: 

<system.web>

    <compilation debug="true" targetFramework="4.5"/> 
   <httpRuntime targetFramework="4.5"/> 
   <pages controlRenderingCompatibilityVersion="4.0"/> 
</system.web>

http://localhost/MySpy/signalr/signalr/connect?transport=webSockets&connectionId=829cc336-a32c-457a-b539-fca7744fda09&connectionData=%5B%7B%22name%22%3A%22trackerhub%22%7D%5D&tid=7