search

muaz-khan / WebRTC-Experiment

WebRTC, WebRTC and WebRTC. Everything here is all about WebRTC!!
https://www.webrtc-experiment.com/
MIT License
11.77k stars 3.95k forks source link

Reconnect after the initiator has left #245

Open iwuvjhdva opened 10 years ago

iwuvjhdva commented 10 years ago

Hi,

I work with RTCMultiConnection.

Is there any standard way to reconnect to the initiator after he has left?

There are two pages in our project, initiator.html and participant.html. After establishing the connection if the initiator's page is reloaded the participant connection's onleave() event is raised.

I have tried to set a timer interval and call connection.refresh() and connection.close() + connection.connect() in the callback without success.

The only solution that worked was closing the connection, deleting the object and creating RTCMultiConnection class instance again with doing all the same initialization that has been done on page load.

Is this a proper method or are there any alternatives to that?

Thank you!

muaz-khan commented 10 years ago

Simply download experimental file:

And use that experimental file within this experiment:

And everything will work. Initiator can leave and rejoin his own room. Participants can leave or join same room or any other room.

You simply need to call connection.leave method both for initiator and participants, if they wanted to leave the session.

Note: You don't need to manually call connection.refresh because it is auto called with connection.leave method.

If user-A leaves the session using connection.leave method; connection.refresh is auto called for him. Also, RTCMultiConnection will auto clear all "his" relevant ids/sockets/references from all other users sides; even from initiator's side. This allows same user to join same room again, and connect with same list of users.

iwuvjhdva commented 10 years ago

Hi Muaz,

So, with this approach I need to call both initiator.connection.connect() and initiator.connection.open() on the initiator's side and join the new session in the initiator.connection.onNewSession() event handler?

If that's correct, here are the problems I've met:

Please assist.

Thanks!

On Thu, Jul 10, 2014 at 6:04 PM, Muaz Khan notifications@github.com wrote:

Simply download experimental file:

And use that experimental file within this experiment:

- https://www.webrtc-experiment.com/RTCMultiConnection/session-reinitiation.html

And everything will work. Initiator can leave and rejoin his own room. Participants can leave or join same room or any other room.

You simply need to call connection.leave method both for initiator and participants, if they wanted to leave the session.

Note: You don't need to manually call connection.refresh because it is auto called with connection.leave method.

If user-A leaves the session using connection.leave method; connection.refresh is auto called for him. Also, RTCMultiConnection will auto clear all "his" relevant ids/sockets/references from all other users sides; even from initiator's side. This allows same user to join same room again, and connect with same list of users.

— Reply to this email directly or view it on GitHub https://github.com/muaz-khan/WebRTC-Experiment/issues/245#issuecomment-48625565 .

Kind regards, Konstantin Alexandrov

http://illuzia.net

iwuvjhdva commented 10 years ago

Another minor issue - my initiator doesn't send any streams, connection.sessions = {}. But when I use the reinitiation approach recommended by you, it asks for camera access which is a bit irritating.

On Sun, Jul 13, 2014 at 2:24 PM, Konstantin Aleksandrov <iwuvjhdva@gmail.com

wrote:

Hi Muaz,

So, with this approach I need to call both initiator.connection.connect() and initiator.connection.open() on the initiator's side and join the new session in the initiator.connection.onNewSession() event handler?

If that's correct, here are the problems I've met:

  • If I call connection.open() immediately after connection.connect() - nothing happens, the new session event is not raised.
  • If I try to call connection.open() on 3 seconds timeout after calling connection.connect() - then it works, new session and new stream arrives but then in my case I need to hold that stream but there's a problem with that - connection.peers doesn't contain the new peer for some reason so hold() doesn't work.

Please assist.

Thanks!

On Thu, Jul 10, 2014 at 6:04 PM, Muaz Khan notifications@github.com wrote:

Simply download experimental file:

And use that experimental file within this experiment:

- https://www.webrtc-experiment.com/RTCMultiConnection/session-reinitiation.html

And everything will work. Initiator can leave and rejoin his own room. Participants can leave or join same room or any other room.

You simply need to call connection.leave method both for initiator and participants, if they wanted to leave the session.

Note: You don't need to manually call connection.refresh because it is auto called with connection.leave method.

If user-A leaves the session using connection.leave method; connection.refresh is auto called for him. Also, RTCMultiConnection will auto clear all "his" relevant ids/sockets/references from all other users sides; even from initiator's side. This allows same user to join same room again, and connect with same list of users.

— Reply to this email directly or view it on GitHub https://github.com/muaz-khan/WebRTC-Experiment/issues/245#issuecomment-48625565 .

Kind regards, Konstantin Alexandrov

http://illuzia.net

Kind regards, Konstantin Alexandrov

http://illuzia.net

iwuvjhdva commented 10 years ago

Sorry for my previous comment, now it works. I've also got rid of connection.connect() on the initiator's side, it seems that connection.open() also opens the signaling channel, is my understanding correct?

On Sun, Jul 13, 2014 at 2:27 PM, Konstantin Aleksandrov <iwuvjhdva@gmail.com

wrote:

Another minor issue - my initiator doesn't send any streams, connection.sessions = {}. But when I use the reinitiation approach recommended by you, it asks for camera access which is a bit irritating.

On Sun, Jul 13, 2014 at 2:24 PM, Konstantin Aleksandrov < iwuvjhdva@gmail.com> wrote:

Hi Muaz,

So, with this approach I need to call both initiator.connection.connect() and initiator.connection.open() on the initiator's side and join the new session in the initiator.connection.onNewSession() event handler?

If that's correct, here are the problems I've met:

  • If I call connection.open() immediately after connection.connect()
  • nothing happens, the new session event is not raised.
  • If I try to call connection.open() on 3 seconds timeout after calling connection.connect() - then it works, new session and new stream arrives but then in my case I need to hold that stream but there's a problem with that - connection.peers doesn't contain the new peer for some reason so hold() doesn't work.

Please assist.

Thanks!

On Thu, Jul 10, 2014 at 6:04 PM, Muaz Khan notifications@github.com wrote:

Simply download experimental file:

And use that experimental file within this experiment:

- https://www.webrtc-experiment.com/RTCMultiConnection/session-reinitiation.html

And everything will work. Initiator can leave and rejoin his own room. Participants can leave or join same room or any other room.

You simply need to call connection.leave method both for initiator and participants, if they wanted to leave the session.

Note: You don't need to manually call connection.refresh because it is auto called with connection.leave method.

If user-A leaves the session using connection.leave method; connection.refresh is auto called for him. Also, RTCMultiConnection will auto clear all "his" relevant ids/sockets/references from all other users sides; even from initiator's side. This allows same user to join same room again, and connect with same list of users.

— Reply to this email directly or view it on GitHub https://github.com/muaz-khan/WebRTC-Experiment/issues/245#issuecomment-48625565 .

Kind regards, Konstantin Alexandrov

http://illuzia.net

Kind regards, Konstantin Alexandrov

http://illuzia.net

Kind regards, Konstantin Alexandrov

http://illuzia.net

muaz-khan commented 10 years ago

You can read about differences between connect/open/join methods here:

iwuvjhdva commented 10 years ago

Hi, Thanks for your feedback. After switching to the experimental library the re-initation works perfectly but there two other new issues appeared:

The both bugs disappear when I switch back to stable 1.8 but then the re-initiation stops working.

Also I've noticed that it seems like you're changing the same file https://www.webrtc-experiment.com/RTCMultiConnection-v1.8.js although it has a version number in it's name and thus logically is not supposed to be updated unless you create a new file with different version number after any change (like 1.8.1, 1.8.1.1). If so, that is really confusing.

On Sun, Jul 13, 2014 at 3:50 PM, Muaz Khan notifications@github.com wrote:

You can read about differences between connect/open/join methods here:

https://camo.githubusercontent.com/df105ba02c93d781fb62d90342832b22f2edd517/687474703a2f2f7777772e7274636d756c7469636f6e6e656374696f6e2e6f72672f696d672f446966666572656e63652d4265747765656e2d4f70656e2d416e642d436f6e6e6563742d4d6574686f64732e706e67

— Reply to this email directly or view it on GitHub https://github.com/muaz-khan/WebRTC-Experiment/issues/245#issuecomment-48841043 .

Kind regards, Konstantin Alexandrov

http://illuzia.net

iwuvjhdva commented 10 years ago

Sorry, not related to hold/unhold, just when a new participant is connected another one is receiving session from him even if the participant's initialization contains // Do not accept remote streams this.connection.sdpConstraints.mandatory = { OfferToReceiveAudio: false, OfferToReceiveVideo: false };

On Mon, Jul 14, 2014 at 9:36 AM, Konstantin Aleksandrov <iwuvjhdva@gmail.com

wrote:

Hi, Thanks for your feedback. After switching to the experimental library the re-initation works perfectly but there two other new issues appeared:

  • When I have multiple participants connected using a star scheme (many-to-one) and do hold/unhold a peer on participant's side, the participants started to receive remote streams from another participants on random basis, like in Chat Roulette! Setting this.connection.sdpConstraints.mandatory on participant's side didn't help.
  • Though I'm setting the 4:3 aspect ratio, width and height, all video streams are 16:9.

The both bugs disappear when I switch back to stable 1.8 but then the re-initiation stops working.

Also I've noticed that it seems like you're changing the same file https://www.webrtc-experiment.com/RTCMultiConnection-v1.8.js although it has a version number in it's name and thus logically is not supposed to be updated unless you create a new file with different version number after any change (like 1.8.1, 1.8.1.1). If so, that is really confusing.

On Sun, Jul 13, 2014 at 3:50 PM, Muaz Khan notifications@github.com wrote:

You can read about differences between connect/open/join methods here:

https://camo.githubusercontent.com/df105ba02c93d781fb62d90342832b22f2edd517/687474703a2f2f7777772e7274636d756c7469636f6e6e656374696f6e2e6f72672f696d672f446966666572656e63652d4265747765656e2d4f70656e2d416e642d436f6e6e6563742d4d6574686f64732e706e67

— Reply to this email directly or view it on GitHub https://github.com/muaz-khan/WebRTC-Experiment/issues/245#issuecomment-48841043 .

Kind regards, Konstantin Alexandrov

http://illuzia.net

Kind regards, Konstantin Alexandrov

http://illuzia.net

iwuvjhdva commented 10 years ago

Hi, So the problem with both https://www.webrtc-experiment.com/RTCMultiConnection-v1.8.js and the experimental version is that participants start to receive remote streams from other participants though only the initiator is supposed to do that. Setting the mandatory sdpConstraints to false doesn't affect anything. I also tried to compare the old and the new versions to figure out what's the problem with no success.

Rolling RTCMultiConnection back to the version I used before (the link https://raw.githubusercontent.com/bbfsdev/webrtc-multi-connection/9d0eb63f69e51db9b7f2feba187c6efb2a08c9a8/RTCMultiConnection-v1.8.js) solves the issue but then of course the session re-initiation doesn't work.

Here's the demo: https://webrtc.socio2.net/initiator.html (Initiator's page) https://webrtc.socio2.net/participant.html (Participant's page)

Please assist.

Thank you!

On Mon, Jul 14, 2014 at 10:03 AM, Konstantin Aleksandrov < iwuvjhdva@gmail.com> wrote:

Sorry, not related to hold/unhold, just when a new participant is connected another one is receiving session from him even if the participant's initialization contains // Do not accept remote streams this.connection.sdpConstraints.mandatory = { OfferToReceiveAudio: false, OfferToReceiveVideo: false };

On Mon, Jul 14, 2014 at 9:36 AM, Konstantin Aleksandrov < iwuvjhdva@gmail.com> wrote:

Hi, Thanks for your feedback. After switching to the experimental library the re-initation works perfectly but there two other new issues appeared:

  • When I have multiple participants connected using a star scheme (many-to-one) and do hold/unhold a peer on participant's side, the participants started to receive remote streams from another participants on random basis, like in Chat Roulette! Setting this.connection.sdpConstraints.mandatory on participant's side didn't help.
  • Though I'm setting the 4:3 aspect ratio, width and height, all video streams are 16:9.

The both bugs disappear when I switch back to stable 1.8 but then the re-initiation stops working.

Also I've noticed that it seems like you're changing the same file https://www.webrtc-experiment.com/RTCMultiConnection-v1.8.js although it has a version number in it's name and thus logically is not supposed to be updated unless you create a new file with different version number after any change (like 1.8.1, 1.8.1.1). If so, that is really confusing.

On Sun, Jul 13, 2014 at 3:50 PM, Muaz Khan notifications@github.com wrote:

You can read about differences between connect/open/join methods here:

https://camo.githubusercontent.com/df105ba02c93d781fb62d90342832b22f2edd517/687474703a2f2f7777772e7274636d756c7469636f6e6e656374696f6e2e6f72672f696d672f446966666572656e63652d4265747765656e2d4f70656e2d416e642d436f6e6e6563742d4d6574686f64732e706e67

— Reply to this email directly or view it on GitHub https://github.com/muaz-khan/WebRTC-Experiment/issues/245#issuecomment-48841043 .

Kind regards, Konstantin Alexandrov

http://illuzia.net

Kind regards, Konstantin Alexandrov

http://illuzia.net

Kind regards, Konstantin Alexandrov

http://illuzia.net

iwuvjhdva commented 10 years ago

Solved the issue by creating this patch to http://www.webrtc-experiment.com/RTCMultiConnection-v1.8.js Please take a look at the attached diff. Is there a better solution?

muaz-khan commented 10 years ago 
connection.sdpConstraints.mandatory = {
   OfferToReceiveAudio: false,
   OfferToReceiveVideo: false
};

"..problem with both latest.js and the experimental version is that participants start to receive remote streams from other participants though only the initiator is supposed to do that. Setting the mandatory sdpConstraints to false doesn't affect anything..."

You seems supposed something like this?

If OfferToReceiveAudio and OfferToReceiveVideo are set to false then the user will NEVER receive remote streams. However, he can send his stream to others....?

OfferToReceive Audio/Video == false

In this case, user is prompting end-user for sendonly stream. It doesn't means that current user will NEVER get remote stream. It simply means that current user is planning not to send his own stream.

Lets say I'm offerer and you're answerer. You set OfferToReceive Audio/Video = false. It means that you asked me to use word sendonly both for audio/video m-lines because you're not going to add your own stream.

Browser will use word recvonly in the answer descriptions, for OfferToReceive Audio/Video = false.

If you invoked peer.addStream along with OfferToReceive Audio/Video = false then browser "should" use inactive both for audio/video m-lines.

Remember, offerer can't use OfferToReceive Audio/Video = false because offerer MUST always add his media stream in his offer.

Solution for one-way streaming?

connection.session.oneway = true;

// or
connection.direction = 'one-way';

// or
connection.onNewSession = function (session) {
    session.join({
        oneway: true
    });
};

// or
connection.dontAttachStream = true;
iwuvjhdva commented 10 years ago

Hey Muaz, thank you for the reply.

Unfortunately noone of the solutions you've proposed is working (I tried them all before).

connection.session.oneway = true;

Doesn't change anything. Once a second participant is connected, the first one starts to receive his video instead of his own.

// orconnection.direction = 'one-way';

Exactly the same story here.

// orconnection.onNewSession = function (session) { session.join({ oneway: true });};

This makes the participant to not to send any stream at all.

// orconnection.dontAttachStream = true;

Same story with this solution - the participant page even doesn't ask for camera.

Please assist.

Kind regards, Konstantin Alexandrov

http://illuzia.net

muaz-khan commented 10 years ago 
<script src="//www.rtcmulticonnection.org/latest.js"></script>
<button id="openNewSessionButton">Open New Room</button>
<script>
var connection = new RTCMultiConnection();

connection.session = {
    audio: true,
    video: true,
    oneway: true
};

connection.connect();

document.querySelector('#openNewSessionButton').onclick = function() {
    connection.open();
};
</script>

Try here: http://htmledit.squarefree.com/#private-room

Many-to-one ?

Above code snippet is targeting one-to-many model, where initiator is sharing his stream with rest of the users.

Initiator always plays role of offerer, and it isn't possible that offerer sets recvonly.

In many-to-one case, offerer MUST always set recvonly?

muaz-khan commented 10 years ago

Following works in many-to-one style:

<script src="//www.rtcmulticonnection.org/latest.js"></script>
<script src="//www.rtcmulticonnection.org/firebase.js"></script>
<button id="openNewSessionButton">Open New Room</button>
<script>
var connection = new RTCMultiConnection();

connection.session = {
    broadcast: true
};

connection.onNewSession = function(session) {
    session.join({
        audio: true,
        video: true
    });
};

connection.connect();

document.querySelector('#openNewSessionButton').onclick = function() {
    this.disabled = true;

    connection.dontAttachStream = true;
    connection.open();
};
</script>
muaz-khan commented 10 years ago

connection.session={} is fixed. If session is set to empty object then initiator will be recvonly:

<!--Use experimental:
https://raw.githubusercontent.com/muaz-khan/RTCMultiConnection-experimental/master/RTCMultiConnection.js
-->
<script src="RTCMultiConnection-v1.8.js"></script>
<button id="openNewSessionButton">Open New Room</button>
<script>
var connection = new RTCMultiConnection();

connection.session = {};
connection.direction = 'one-way';

connection.onNewSession = function(session) {
    session.join({
        audio: true,
        video: true
    });
};

connection.connect();

document.querySelector('#openNewSessionButton').onclick = function() {
    this.disabled = true;
    connection.open();
};
</script>
iwuvjhdva commented 10 years ago

Didn't work with empty session ({}) on the initiator side, seems to work with initiator's connection.session = {oneway: true}.

On Mon, Jul 14, 2014 at 7:57 PM, Muaz Khan notifications@github.com wrote:

connection.session={} is fixed https://github.com/muaz-khan/RTCMultiConnection-experimental#recent-changes. If session http://www.rtcmulticonnection.org/docs/session/ is set to empty object then initiator will be recvonly:

``` — Reply to this email directly or view it on GitHub https://github.com/muaz-khan/WebRTC-Experiment/issues/245#issuecomment-48933900 .

Kind regards, Konstantin Alexandrov

http://illuzia.net

muaz-khan commented 10 years ago

Did you try experimental, RTCMultiConnection.js?

iwuvjhdva commented 10 years ago

Yes. It didn't work with session = {oneway: true} before but now it works.

On Tue, Jul 15, 2014 at 10:45 AM, Muaz Khan notifications@github.com wrote:

Did you try experimental, RTCMultiConnection.js?

- https://github.com/muaz-khan/RTCMultiConnection-experimental/blob/master/RTCMultiConnection.js

— Reply to this email directly or view it on GitHub https://github.com/muaz-khan/WebRTC-Experiment/issues/245#issuecomment-49005305 .

Kind regards, Konstantin Alexandrov

http://illuzia.net

iwuvjhdva commented 10 years ago

could you please check the lines 4413-4422, these min and max functions are updating mediaConstraints instead of mediaConstraints.mandatory so they don't affect the actual stream:

    // www.RTCMultiConnection.org/docs/media/
    connection.media = {
        min: function (width, height) {
            connection.mediaConstraints.minWidth = width;
            connection.mediaConstraints.minHeight = height;
        },
        max: function (width, height) {
            connection.mediaConstraints.maxWidth = width;
            connection.mediaConstraints.maxHeight = height;
        }
    };

it would be also nice to keep support for connection.media.minAspectRatio, now it has to be set in the mediaConstraints.mandatory object in the experimental code base.

On Tue, Jul 15, 2014 at 11:04 AM, Konstantin Aleksandrov < iwuvjhdva@gmail.com> wrote:

Yes. It didn't work with session = {oneway: true} before but now it works.

On Tue, Jul 15, 2014 at 10:45 AM, Muaz Khan notifications@github.com wrote:

Did you try experimental, RTCMultiConnection.js?

- https://github.com/muaz-khan/RTCMultiConnection-experimental/blob/master/RTCMultiConnection.js

— Reply to this email directly or view it on GitHub https://github.com/muaz-khan/WebRTC-Experiment/issues/245#issuecomment-49005305 .

Kind regards, Konstantin Alexandrov

http://illuzia.net

Kind regards, Konstantin Alexandrov

http://illuzia.net

iwuvjhdva commented 10 years ago

(just nice to have)

On Tue, Jul 15, 2014 at 11:07 AM, Konstantin Aleksandrov < iwuvjhdva@gmail.com> wrote:

could you please check the lines 4413-4422, these min and max functions are updating mediaConstraints instead of mediaConstraints.mandatory so they don't affect the actual stream:

    // www.RTCMultiConnection.org/docs/media/
    connection.media = {
        min: function (width, height) {
            connection.mediaConstraints.minWidth = width;
            connection.mediaConstraints.minHeight = height;
        },
        max: function (width, height) {
            connection.mediaConstraints.maxWidth = width;
            connection.mediaConstraints.maxHeight = height;
        }
    };

it would be also nice to keep support for connection.media.minAspectRatio, now it has to be set in the mediaConstraints.mandatory object in the experimental code base.

On Tue, Jul 15, 2014 at 11:04 AM, Konstantin Aleksandrov < iwuvjhdva@gmail.com> wrote:

Yes. It didn't work with session = {oneway: true} before but now it works.

On Tue, Jul 15, 2014 at 10:45 AM, Muaz Khan notifications@github.com wrote:

Did you try experimental, RTCMultiConnection.js?

- https://github.com/muaz-khan/RTCMultiConnection-experimental/blob/master/RTCMultiConnection.js

— Reply to this email directly or view it on GitHub https://github.com/muaz-khan/WebRTC-Experiment/issues/245#issuecomment-49005305 .

Kind regards, Konstantin Alexandrov

http://illuzia.net

Kind regards, Konstantin Alexandrov

http://illuzia.net

Kind regards, Konstantin Alexandrov

http://illuzia.net

iwuvjhdva commented 10 years ago

Did a bug report and some comments, please check the issue:

https://github.com/muaz-khan/RTCMultiConnection-experimental/issues/1

On Tue, Jul 15, 2014 at 11:07 AM, Konstantin Aleksandrov < iwuvjhdva@gmail.com> wrote:

(just nice to have)

On Tue, Jul 15, 2014 at 11:07 AM, Konstantin Aleksandrov < iwuvjhdva@gmail.com> wrote:

could you please check the lines 4413-4422, these min and max functions are updating mediaConstraints instead of mediaConstraints.mandatory so they don't affect the actual stream:

    // www.RTCMultiConnection.org/docs/media/
    connection.media = {
        min: function (width, height) {
            connection.mediaConstraints.minWidth = width;
            connection.mediaConstraints.minHeight = height;
        },
        max: function (width, height) {
            connection.mediaConstraints.maxWidth = width;
            connection.mediaConstraints.maxHeight = height;
        }
    };

it would be also nice to keep support for connection.media.minAspectRatio, now it has to be set in the mediaConstraints.mandatory object in the experimental code base.

On Tue, Jul 15, 2014 at 11:04 AM, Konstantin Aleksandrov < iwuvjhdva@gmail.com> wrote:

Yes. It didn't work with session = {oneway: true} before but now it works.

On Tue, Jul 15, 2014 at 10:45 AM, Muaz Khan notifications@github.com wrote:

Did you try experimental, RTCMultiConnection.js?

- https://github.com/muaz-khan/RTCMultiConnection-experimental/blob/master/RTCMultiConnection.js

— Reply to this email directly or view it on GitHub https://github.com/muaz-khan/WebRTC-Experiment/issues/245#issuecomment-49005305 .

Kind regards, Konstantin Alexandrov

http://illuzia.net

Kind regards, Konstantin Alexandrov

http://illuzia.net

Kind regards, Konstantin Alexandrov

http://illuzia.net

Kind regards, Konstantin Alexandrov

http://illuzia.net

GovindCS commented 2 years ago

When room owner close the tab or close the browser accidently, after that how will join (Open room already have users) again