I've set up a WebRTC application that works as follows: (Beginning at step 5, I stop using CALLER/CALLEE because either the CALLER or the CALLEE can initiate the stream)
CALLER creates peer connection with only a data channel, creates offer, sets local description, and sends offer to CALLEE.
CALLEE sets remote description, creates answer, sets local description, and sends answer to CALLER.
CALLER sets remote description.
CALLER and CALLEE can successfully communicate over the data channel.
PEERA adds an audio and/or video stream to peer connection.
PEERA's onnegotiationneeded event fires.
PEERA creates offer, sets local description, and sends offer to PEERB.
PEERB receives offer, sets remote description, creates answer, sets local description, and sends answer to PEERA.
If PEERA and PEERB are both using Chrome:
If PEERA is the CALLER, then everything behaves normally, and the stream is received successfully by PEERB.
If PEERA is the CALLEE, then PEERB blows up in step 8 when setting the LOCAL description. The stream is received by PEERB, but displays only as a black box when sent to a <video> element.
The error logged is:
Failed to set local answer sdp: Failed to push down transport description: Failed to set SSL role for the channel.
When both PEERA and PEERB are using FireFox:
PEERA can be either the CALLER or CALLEE, and everything behaves normally, and the stream is received successfully by PEERB.
When the CALLEE is using Firefox and the CALLER is using Chrome:
PEERA can be either the CALLER(Chrome) or CALLEE(Firefox), and everything behaves normally, and the stream is received successfully by PEERB.
When the CALLEE is using Chrome and the CALLER is using Firefox:
If PEERA is the CALLER(FireFox), then everything behaves normally, and the stream is received successfully by PEERB(Chrome).
If PEERA is the CALLEE(Chrome), then PEERB(FireFox) blows up in step 8, when setting the REMOTE description.
The error logged is:
DOMException [InvalidSessionDescriptionError: "ICE restart is unsupported at this time (new remote description changes either the ice-ufrag or ice-pwd)ice-ufrag (old): a59T34ixyZjsTUuJice-ufrag (new): rsCN1ugVKHJQzmMbice-pwd (old): KqOHtqdzFp6VwG+3hxbjcQFcice-pwd (new): uVvowvgsKIwuCq/bDmcGbSPA" code: 0 nsresult: 0x0]
Chrome<->Chrome renegotiation
The error you get when PEERA is the callee in the renegotiation is typically due to Chrome changing the DTLS role, however I am not able to reproduce your problem. I believe that this JSFiddle link illustrates the scenario you are describing, and I am able to successfully renegotiate the call using Chrome 47.
If you can still reproduce the problem, take a look at the a=setup: bits of the SDP that are generated in the offer/answer, and compare them to the initial offer/answer. If I'm right, you'll see that to begin with, CALLER will have a=setup:actpass in the offer, and CALLEE will have a=setup:active in the answer. This means that the CALLER is now playing the 'passive' DTLS role and the CALLEE is playing the 'active' DTLS role.
Then when you initiate a renegotiation, PEERA is more than likely sending a=setup:actpass. PEERB, which should send a=setup:passive, is sending a=setup:active instead, which essentially causes a DTLS role swap. The error is due to the fact that Chrome does not support DTLS role changing for peer connections.
There is an open ticket on the google chrome bug tracker related to this, where I have posted a reproduction of the issue you're describing using a different scenario: starting a video-only call and the callee renegotiating to add video+audio.
The only solution that I know of at this time is to "munge" (alter) the SDP prior to calling setLocalDescription, so that it has the values that you want. So, for example, if you are about to process an answer and you know you are the passive DTLS role, you can do like
answer.sdp = answer.sdp.replace('a=setup:active','a=setup:passive');
pc.setLocalDescription(answer).then(...);
Firefox<->Firefox renegotiation
Yep, everything works great! That's because Firefox "does the right thing" with the DTLS roles when renegotiating in all the tests I've run. Take a look at the difference between these SDPs and the Chrome SDPs.
Firefox<->Chrome renegotiation interop
I am able to reproduce the issue you are describing with InvalidSessionDescriptionError showing up in Firefox. I haven't been able to come up with a solution yet nor know the cause at this time.
I'm also having a myriad of other renegotiation interop issues. It's pretty discouraging at the moment.
Please post back if you learn more. Definitely still lots of struggling with renegotiation interop!
Related
I am trying a build a realtime monitoring system for high frequency data. To increase the performance, I used the extendData property of dcc.Graph() and websocket. So that, the brouser does not need to send request to get data.
I found that it still not increasing the performance as expected. The reason I found is, from the browser, I see (by inspecting network from browser) after some miliseconds browser is still sendng request and the initiator is the dash_renderer.
This picture is for a vanilla example just to show even for a textbox example the http request goes on and on. And for my real time websocket dashboard the frequency of requests get very high.
My question is:
What dash_renderer do?
why it is sending http request?
And how to stop that?
If you run Dash in Debug mode, it has a feature called Hot Reloading which regularly (every 3 seconds by default) checks for changes to your codebase and updates your running app if it finds any. That check for updated code is what you're seeing in the network inspection.
To turn it off, either don't run in debug mode or explicitly set dev_tools_hot_reload to False like so:
app.run_server(debug=True, dev_tools_hot_reload=False)
Although it is late, After some experience, my realization is dash is not designed to work with websocket. It uses call-backs which actually sends requests to server and in server, the callback function (which is python) send back some result.
These call-backs are designed to send HTTP request to server.
For high speed data, the websocket should be used with extendTrace method of plotly.js in client side.
I have a simple setup for Desktop Capturing using html5 libraries.
This includes a simple webpage and a chrome-extension. I am using
Extension to get the sourceId
Using the sourceId I call navigator.mediaDevices.getUserMedia to get the MediaStream
This MediaStream is then fed into an instance of MediaRecorder for recording.
This setup works most of the times, but a few times I see that requestData() on MediaRecorder instance returns blob with empty data consistently. I am clueless as to what can cause a running setup to start misbehaving sometimes.
Some weird behaviour that I noticed in the bad state:
When I try to close/refresh the window it doesn't respond.
The MediaStreamTrack object in Step 2) above is 'live' but as soon as I go to Step 3) it becomes 'muted'.
There's no pattern to it, sometimes it even happens when I request for the MediaStreams the very first time(which rules out the possibility that there could be some dangling resources eating up the contexts)
Is there anything that I am doing wrong and am unaware of? Any help/pointers would be highly appreciated!
I am trying to get a port's status in an application (not a content script). When I do :
this.port = chrome.runtime.connect("okcbadfdlhldjgkbafhnkcpofabckgde");
I get a valid port object but I can't find anyway to determine if the port can be used at all (I don't even get a disconnect event if the extension can't be reached).
The only way I figured out to have the connectivity state is to actually trap an exception when performing a this.port.postMessage.
Is there a better way ?
https://developer.chrome.com/extensions/runtime#method-connect
Update
Running Version 48.0.2564.97 (64-bit) on Linux Ubuntu
No cross-extension messaging, just application to/from extension
Extension source code but note I have since moved on to implement another strategy for the extension because of the issue raised in this question.
Your extension uses a background-script that provides listener function for the chrome.runtime.onMessageExternal event. This event is used to listen for incoming messages, send from external webpage-scripts (or other extensions) by calling the chrome.runtime.sendMessage method.
Since your extension does not provide a listener function for the chrome.runtime.onConnectExternal event, chrome.runtime.connect cannot work for your extension.
As far as knowing the connection status is concerned, in this case a simple try-catch block would do enough to know whether the extension supports port or not. If it does, you need to view the manifest corresponding to this extension - to see if a particular host is allowed to send messages or not.
I was able to send message to your extension (see the enclosed figure) by adding the following lines of code in the background-script. In addition to this, I also added the matches string for the host - www.example.org in the manifest.
chrome.runtime.onMessageExternal.addListener(
function(request, _sender, sendResponse) {
console.log(request);
...
}
);
I browsed through the other threads - there was no concrete answer.
I implemented a service worker for notifcations
http://docs.pushwoosh.com/docs/chrome-web-push
I checked everything - all scripts are in root, the keys are well implemented. However, I do not get prompted to allow notifs.
Console output reads:
GET https://mydomain/service-worker.js net::ERR_FILE_EXISTS
Note: I do have the correct URL (just changed it here).
What causes the service worker error? How do I fix this?
It isn't anything to worry about. See the internal bug report: https://code.google.com/p/chromium/issues/detail?id=541797 the TL'DR is that when Chrome tries to fetch a new SW if there is no change and thus nothing to install it throws this error message to indicate that state. There is nothing that you need to do.
Chrome is loading with long polling, and the loading indicator doesn't stop.
Why is Chrome not using WebSockets, and how can I prevent the loading indicator from spinning when it does use long polling?
I'm using the latest socket.io and nodejs v2.5
--
The first time I connect, it uses Websocket, but disconnects right away and reconnects with xhr-polling.
I had a similar problem and I found that there was a socketio cookie overriding the transport method to "xhr-polling". I don't know how the cookie got there, but deleting it did the trick.
Here's a reference to the line that looks for the cookie.
https://github.com/LearnBoost/Socket.IO/blob/master/socket.io.js#L1023
It appears that socket.io.js has options that control this.
tryTransportsOnConnectTimeout - default value is true
rememberTransport - default value is true
I believe that if 'tryTransportsOnConnectTimeout' is set to 'true' then socket.io will iterate through all transport mechanisms on connect and use the first one that succeeds.
If 'rememberTransport' is set to 'true' the transport that was successful is stored in a cookie.
In my application I implemented logic to re-connect when disconnected. I found that I had to set both of the above options to 'false' to prevent falling back to a undesired transport. The issue occurred because after disconnect, the server might become available at any point (while the client was attempting long-poll rather than websockets for example). If that occurred, the cookie was set and subsequent connections would continue to use the undesired transport.
I'm using Chrome 8 and WebSockets appear to work fine.
If you're using socket.io, it should fall back to FlashSockets or even xhr-multipart before long polling (or forever iframe). Check your transport options when initialising socket.io on both the server and the client.