You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've run into an issue where calling addStream2 multiple times in a row synchronously causes problems, since it triggers multiple, parallel renegotiation operations. This results in not all the streams being added to the session.
I've solved it in my application by adding an async queue (specifically using d3-queue
I'm wondering if jingle-media-session should handle this, or if I'm missing something? As I understand it, any operations which trigger a renegotiation either all have to happen before renegotiation starts (and then only one renegotiation is required), or each operation needs to be queued until the previous renegotiation completes.
I've resolved this in another module we're using by keeping an array of "actions" (the queue) and adding the following to our library:
Session.prototype.act = function(action){
var self = this;
self.actions.push(action);
if(self.actions.length > 1){ // Other items in queue, don't run
return
}
self.actNext()
}
Session.prototype.actNext = function(){
var self = this;
var next = self.actions[0];
if(!next){
return
}
next(function(){
self.actions.shift();
self.actNext();
});
}
The other changes in the code become as simple as wrapping your existing logic in a function(done), making sure to call done(), and calling self.act(function) instead of directly invoking the pieces that need to be queued.
The implementation in jingle-media-session would look slightly different, but a similar pattern should be possible and avoid the SLD errors. It's a fairly easy change, and I'd be happy to open a PR here if that seems like an approach that could be included
We've started using a jingle client other than jingle-media-session for some applications and we're seeing the SLD failures very frequently now on our web side of things (which uses jingle-media-session via jingle.js / stanza.io).
I've opened a PR implementing the update I described in my previous comment at: #28
Feedback and testing (particularly in p2p sessions) would be greatly appreciated.
I've run into an issue where calling
addStream2
multiple times in a row synchronously causes problems, since it triggers multiple, parallel renegotiation operations. This results in not all the streams being added to the session.I've solved it in my application by adding an async queue (specifically using d3-queue
I'm wondering if jingle-media-session should handle this, or if I'm missing something? As I understand it, any operations which trigger a renegotiation either all have to happen before renegotiation starts (and then only one renegotiation is required), or each operation needs to be queued until the previous renegotiation completes.
Thoughts @xdumaine @legastero @fippo ?
The text was updated successfully, but these errors were encountered: